Tout d'abord, Android ne vous force pas à utiliser n'importe quelle architecture. Non seulement cela, mais il fait aussi un peu de mal à essayer de suivre à tout. Cela va vous obliger à être un smart développeur afin d'éviter de créer une base de code spaghetti :)
Vous pouvez essayer de s'adapter à n'importe quel motif vous connaissez et que vous aimez. Je trouve que la meilleure approche consiste en quelque sorte entrer dans vos tripes que vous développez des applications de plus en plus (désolé à ce sujet mais comme toujours, vous aurez à faire beaucoup d'erreurs jusqu'à ce que vous commencer à le faire à droite).
Sur les modèles vous le savez, permettez-moi de faire quelque chose de mal: je mélange des trois modèles différents de sorte que vous obtenez le sentiment de qu'est-ce qui, dans android. Je crois que le Présentateur/ModelView doit être quelque part dans le Fragment ou d'une Activité. Les adaptateurs peuvent parfois faire ce travail comme ils prennent soin d'entrées dans les listes. Probablement les Activités doivent travailler comme des Contrôleurs de trop. Les modèles doivent être régulières, fichiers java alors que la Vue doit jeter dans la mise en page des ressources et des composants personnalisés, vous pourriez avoir à mettre en œuvre.
Je peux vous donner quelques conseils. C'est un wiki de la communauté de réponses donc j'espère que d'autres personnes pourraient inclure d'autres suggestions.
L'Organisation Des Fichiers
Je pense qu'il y a principalement deux sensée possibilités:
- tout organiser par type - créer un dossier pour toutes les activités, un autre dossier pour toutes les cartes, un autre dossier pour tous les fragments, etc
- tout organiser par domaine (peut-être pas le meilleur mot). Cela signifierait que tout ce qui concerne "ViewPost" serait à l'intérieur du même dossier - de l'activité, le fragment, les cartes, etc. Tout ce qui a trait à "ViewPost" serait dans un autre dossier. De même pour les "EditPost", etc. Je suppose que les activités de obligerait les dossiers que vous devez créer et alors il y aurait un peu plus de génériques pour les classes de base par exemple.
Personnellement, j'ai été impliqué dans des projets à l'aide de la première approche, mais je voudrais vraiment essayer le plus tard, comme je le crois, il pourrait faire des choses plus organisées. Je ne vois aucun avantage à avoir un dossier avec 30 fichiers non liés mais qu'est ce que j'obtiens avec la première approche.
De nommage
- Lors de la création de mises en page et les styles, toujours de nom (ou de les identifier) à l'aide d'un préfixe pour l'activité (/fragment) où ils sont utilisés.
Donc, toutes les chaînes de caractères, les styles, les identifiants utilisés dans le cadre de "ViewPost" devrait commencer à être "@id/view_post_heading" (pour un textview par exemple), "@style/view_post_heading_style", "@string/view_post_greeting".
Cela permettra d'optimiser la saisie semi-automatique, d'organisation, d'éviter le nom de colision, etc.
Les Classes De Base
Je pense que vous aurez envie d'utiliser les classes de base pour à peu près tout ce que vous faites: Adaptateurs, des Activités, des Fragments, des Services, etc. Ces pourrait être utile au moins à des fins de débogage si vous connaissez les événements qui se sont produits dans votre activité.
Général
- Je n'ai jamais anonymes classes - ces sont moches et sera le moteur de votre attention lorsque vous essayez de lire le code
- Parfois, je préfère utiliser les classes internes (comparé à créer une classe dédiée) - si un cours n'est pas destiné à être utilisé n'importe où ailleurs (et c'est petit) je pense que c'est très pratique.
- Pensez à votre système d'enregistrement depuis le début, vous pouvez utiliser la version d'android de journalisation du système, mais faire un bon usage!
