Dilemna: empêche StackOverflowException ou améliore l'expérience utilisateur?

Question

Dans mon application, j'ai 2 activités de liste qui peuvent démarrer l'une ou l'autre en cliquant sur leurs articles.

|--Activity1--|   |--Activity2--|   |--Activity1--| 
| item11 | ->click-> | item21 |   | item21 | ->click-> ... 
| item12 |   | item22 | ->click-> | item12 | 
| item13 |   | item23 |   | item13 | 
|-------------|   |-------------|   |-------------| 

Donc, si l'utilisateur clique trop, il peut remplir toute la pile et le système lancera une StackOverFlowException non?

La solution que j'ai choisie était de marquer ces 2 activités avec noHistory="true", mais maintenant je regrette que l'utilisateur ne puisse pas naviguer entre ces 2 activités avec le bouton de retour.

Quelqu'un peut-il m'aider à trouver une meilleure alternative?

Merci à l'avance

EDIT: pour être plus complet, nous allons expliquer ce qui est de cette activité objectif de workflow:

J'ai une base de données qui stocke une liste de noms liés à une liste des jours dans une année. Un nom peut être lié à plusieurs jours, et la même chose un jour peut être lié à plusieurs noms.

the database schema 

| names |---< n, m >---| days | 

Donc, ce flux d'activité est une sorte de navigateur de base de données:

• Activity1 est le NameListActivity, il affiche une liste de noms liés à un jour précis.
• Activity2 est le DateListActivity, il affiche une liste de jours liés à un nom spécifique.

Lorsque l'utilisateur clique sur un élément (un nom ) du NameListActivity, le DateListActivity est démarré avec la liste des jours liés au nom cliqué.
Et même chose, lorsque l'utilisateur clique sur un élément (un jour) du DateListActivity, le NameListActivity est démarré avec la liste des noms associés au jour cliqué.

Answer 1

Donc, si l'utilisateur clique trop, il peut remplir toute la pile et le système jeter un StackOverflowException n'est pas il?

Non, ce ne sera pas le cas.

Answer 2

Je ne vois pas pourquoi la suppression de la possibilité de passer à l'activité 1 de l'activité 2 détériorerait l'expérience de l'utilisateur. Je crois que vous créez mentalement une liste hiérarchique dans votre tête lorsque vous naviguez dans ce type de menus, donc en cliquant sur item22, je serais confus si on me renvoyait à Activity1.

J'ai besoin de plus de détails sur le contenu des menus pour suggérer un autre design, mais il vaut mieux repenser le système de menus.

Answer 3

Ce que vous devez faire est de stocker l'historique dans une structure, plutôt que de compter sur la pile pour le conserver pour vous. Ensuite, vous pouvez maintenir votre bonne expérience utilisateur et ne pas souffler la pile.

Answer 4

Essayez de supprimer ce Nohistory = "true" et plutôt mettre android: launchMode = "singleTask" http://developer.android.com/guide/topics/manifest/activity-element.html#lmode Mais Mark @commonsware vous serez bien comme il est.

Answer 5

J'ai des problèmes similaires avec mon application. Il semble que le problème réside dans le nombre de vues imbriquées pour chaque activité. Donc, si vous avez, par exemple:

tab-> 
    linear layout-> 
     text, 
     linear layout-> 
      text, 
      scroll-> 
        text, 
        linear layout-> 
         image, 
         text 

et peut-être plusieurs autres imbrications, les chances que vous obtiendrez un débordement de pile après avoir obtenu de ce point de vue d'un semblable et à plusieurs reprises (dans mon expérience) sont haute. Vérifiez l'imbrication avec hierarchyviewer (android-sdk/tools). Dites-moi aussi si vous résolvez le problème, parce que je ne sais toujours pas comment le résoudre ...

Answer 6

Si je comprends bien, la «pile» d'activités d'Android n'est pas une «pile» dans le sens traditionnel, et la mémoire est gérée de manière plus intelligente. La pile des activités va en fait sur le tas, et le système d'exploitation va tuer les activités plus bas sur la pile s'il le faut.

Je dirais que le pire, c'est que vous perdez un peu d'histoire ancienne. Si vous voulez le tester, allouez une grande quantité de mémoire dans chaque activité pour que 5 ou 6 remplisse la mémoire disponible, puis essayez-le.

Answer 7

commonsware est correct. Vous n'aurez pas à vous inquiéter d'un débordement de pile. :) Cependant, vous pouvez concevoir l'application pour effacer la pile pour éviter la situation que vous avez décrite. Regardez dans Clearing the Stack, en particulier l'utilisation de clear top.