Android: quoi de mieux - plusieurs activités ou changer de vue manuellement?

J'ai développé des applications pour Android, et cette question reste toujours:

Comment dois-je structurer mon interface utilisateur? Dois-je lancer une activité après une activité et quitter le téléphone pour faire le bouton «retour», ou devrais-je choisir une manière plus optimisée, mais plus complexe à mettre en œuvre, de basculer manuellement entre les vues, puis de faire manuellement la fonctionnalité du bouton «Retour»?

Quelle est selon vous (ou savez) la meilleure pratique?

Je dirais que plusieurs activités ont presque toujours plus de sens. Je ne pense tout simplement pas qu'Android soit conçu pour changer constamment ses propres vues - vous en manquez tellement. Vous devez implémenter Back vous-même, vous n'obtenez pas de transitions inter-activités, vous devez implémenter beaucoup de logique interne pour reprendre une application dans le bon état. Si vous ne partitionnez pas votre application en activités, il sera beaucoup plus difficile par la suite de modifier le flux de votre application. Il en résulte également une méga-activité qui peut être beaucoup plus difficile à gérer que beaucoup de petits morceaux de code.

J'ai du mal à imaginer que la vitesse est vraiment un problème; si c'est le cas, il y a un problème avec la façon dont vous initialisez chaque activité. Par exemple, j'ai utilisé essayer de passer des objets sérialisables entre les activités, et cela s'est avéré incroyablement lent; lorsque je suis passé à une méthode plus rapide pour faire passer des objets, la vitesse de lancement des activités a énormément augmenté.

De plus, je pense qu'il est révélateur que les directives Android pour la conception des activités et des tâches ne mentionnent pas du tout le changement de vue; il est centré sur une conception Activity-as-View.

Je voudrais souligner certains cas où une seule activité pourrait être une meilleure conception pour une application Android qui a plus d'une vue plein écran:

• Si les écrans d'application sont étroitement couplés et partagent un objet commun sur lequel ils fonctionnent tous. Dans ce cas, le passage de l'objet peut nécessiter un bundle et peut être sujet aux erreurs car il y en aura des copies. Un bon exemple pourrait être un assistant . Oui, vous pouvez utiliser des statiques pour accéder à l'objet commun, mais les statiques peuvent être dangereuses dans Android (pensez aux changements de configuration!)

• Si vous voulez des animations vraiment cool entre les écrans. Peut-être voulez-vous qu'un oiseau décolle sur un écran et atterrisse sur un autre écran. Essayez de faire cela lorsque chaque écran est une activité!

D'un autre côté, si l'un de vos écrans est conçu pour être affiché par un nombre quelconque d'autres applications, cet écran doit être sa propre activité.

MISE À JOUR Mars 2014:

À ce stade, la question devrait maintenant inclure le choix des fragments. Je pense que les vues sont probablement le choix le moins probable des 3: activité, fragment, vue. Si vous souhaitez implémenter des écrans qui utilisent le bouton de retour, il doit s'agir d'activités ou de fragments car les deux gèrent le bouton de retour de manière native. Des fragments devront être ajoutés à la pile arrière de FragmentManager pour que le bouton de retour fonctionne. La gestion des fragments, des dialogues et de la pile arrière peut cependant être un peu ennuyeuse!

MISE À JOUR septembre 2018:

Certains développeurs de Google recommandent des applications à activité unique utilisant le nouveau composant d'architecture de navigation .

Gardez également à l'esprit que la mise en œuvre de votre application avec plusieurs Activitiesoffrira à l'utilisateur une expérience plus cohérente avec la plate-forme dans son ensemble. Une partie de l'expérience sera façonnée en utilisant les applications Google intégrées, de sorte que les utilisateurs auront probablement plus de facilité à utiliser votre application si elle se comporte de la même manière que celles déjà installées sur le téléphone.

Différent des autres, j'utilise un mélange des deux, par exemple
1. Il y a un menu principal lorsque l'application démarre
2. Vous cliquez sur Rechercher, vous amène à l'activité de recherche
3. Ensuite, il y a un bouton de filtre, qui change simplement de vue et affiche vous filtrez les options
4. Il y a deux boutons à la fin de la vue de filtre, vous appuyez sur "Rechercher" ou "Annuler" et vous êtes de retour à la vue de recherche (sans changer d'activité)
5. Maintenant, si l'utilisateur frappe le téléphone en arrière bouton, il est ramené au menu principal au lieu des options de filtre de recherche. Ce qui, je suppose, est le comportement correct.

Utilisez-le comme l'utilisateur se sentira naturel. Et garder tout dans une seule activité le rendra complexe.

Tout dépend de l'application, de ce que vous essayez d'obtenir de meilleures performances, d'une interface utilisateur plus fluide. À mon humble avis, je préfère la deuxième approche consistant à contrôler manuellement les activités, même si elle est plus complexe comme vous l'avez déclaré. C'est une approche que j'ai utilisée dans mon projet d'onglets Android.Vous voudrez peut-être également jeter un coup d'œil à une classe appelée ActivityGroup (pas sûr du package), cela vous permet d'avoir plusieurs activités entre lesquelles vous pouvez basculer, bonne chose à propos de cette classe est que vos activités ne sont pas déchargées lorsque vous changez, mais une mauvaise chose est que le chargement de votre application principale prend plus de temps.

Juste mon avis.

Le problème de changement de vue, sur lequel je suis tombé par hasard, est également causé par le garbage collector. Semble que GC est déclenché lorsque vous quittez l'activité et non la vue. Ainsi, changer d'onglets avec des vues enfants assez complexes, par exemple, entraînera presque inévitablement une exception de débordement de pile.

J'ai rencontré tellement de problèmes avec la disposition de plusieurs activités que je le déconseille fortement, à moins qu'il n'y ait une bonne raison de le choisir.

Inconvénient de plusieurs activités

En utilisant plusieurs activités, il est très difficile de refactoriser le code pour renvoyer des données d'activité.

Si vous appelez une «sous-activité», l'activité principale peut être supprimée. Mais vous ne rencontrez jamais cela lors du débogage sur un appareil décent, vous devez donc gérer toujours l'enregistrement de l'état et la récupération correcte de l'état. C'est une douleur. Imaginez appeler une méthode sur une bibliothèque (c.-à-d. Une autre activité), et vous devriez vous assurer que lorsque cette méthode retourne, votre application doit être capable de recréer complètement son état avec tous les champs de tous les objets de la VM (c.-à-d. Activité. restoreIntance). C'est fou.

De même, à l'inverse, lorsque vous ouvrez une sous-activité, la machine virtuelle peut avoir été tuée depuis que la sous-activité a été créée pour la première fois, par exemple lorsque l'application est minimisée alors que la sous-activité est affichée.

C'est tellement plus propre de n'avoir qu'un seul endroit pour stocker l'état d'application pertinent, et dans mon cas, le plus souvent, si la VM est tuée, je veux ramener l'utilisateur à l'écran principal et les laisser faire leurs affaires à nouveau, car je ne le fais pas. ne passez pas 30 à 50 heures à coder la fonctionnalité de sauvegarde / reprise que 0,1% des utilisateurs connaîtront.

Alternative

Fragments ou gérez simplement vos vues d'activité vous-même. La gestion manuelle des vues nécessite de coder une alternative de changement de vue aux activités / fragments avec des transitions si vous le souhaitez.

Et non, cela ne signifie pas une méga-activité, comme suggéré dans la réponse acceptée, d'une autre manière que sa seule méga-application. Cela nécessite juste un peu plus de conception de la base de code en éléments appropriés, car il y a un peu plus de travail de gestion des vues, bien que beaucoup moins de travail de gestion de l'état d'activité et d'autres bizarreries.

Peut-être pertinent: Reddit: C'est officiel: Google recommande officiellement une architecture d'application à activité unique