Dilemma: prevenire StackOverflowException o migliorare l'esperienza degli utenti?

Question

Nella mia applicazione, ho 2 attività della lista che può avviare una o l'altra cliccando sui loro oggetti.

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

Quindi, se l'utente fa clic troppo, può riempire tutto lo stack e il sistema genererà un StackOverFlowException non sarà vero?

La soluzione che ho scelto era quello di etichettare questi 2 attività con noHistory="true", ma ora mi dispiace che l'utente non può navigare tra queste 2 attività con il tasto back.

Qualcuno mi può aiutare per trovare un'alternativa migliore?

Grazie in anticipo

  

EDIT: per essere più completo, cerchiamo di spiegare che cosa è questo obiettivo flusso di lavoro di attività:

Ho un database che memorizza un elenco di nomi legati a un elenco di giorni in un anno. Un nome può essere collegato a più giorni, e la stessa cosa che un giorno può essere collegato a più nomi.

the database schema 

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

Quindi questo flusso di lavoro attività è una sorta di navigatore database:

• Activity1 è il NameListActivity, viene visualizzato un elenco di nomi legati a un giorno specifico.
• Activity2 è il DateListActivity, viene visualizzato un elenco dei giorni legati a un nome specifico.

Quando l'utente fa clic su un oggetto (una nome ) del NameListActivity, il DateListActivity viene avviato con l'elenco dei giorni legati al nome cliccato.
E stessa cosa, quando l'utente clicca su un elemento (un il giorno ) del DateListActivity, il NameListActivity è iniziato con i nomi AF Lista legati al giorno cliccato.

Answer 1

  

Quindi, se l'utente fa clic troppo, che può   riempire tutto lo stack e il sistema   gettare uno StackOverflowException non è   vero?

No, non lo farà.

Answer 2

Non vedo il motivo per cui la rimozione della possibilità di andare alla Activity1 da Activity2 deteriorerebbe l'esperienza dell'utente. Credo che si crea mentalmente una lista hierarical nella tua testa quando si naviga questo tipo di menù, così quando si clicca su item22 avrei confondersi se mi è stato inviato di nuovo a Activity1.

ho bisogno di ulteriori dettagli sul contenuto dei menu per suggets un altro disegno, ma si potrebbe essere meglio di ripensare il sistema di menu.

Answer 3

A quanto ho capito, "stack" di Android di attività non è un "stack" nel senso tradizionale, e la memoria è gestita in modo più intelligente. Le attività impilano in realtà va sul mucchio, e il sistema operativo uccideranno le attività più basso nello stack, se è necessario.

Direi che la cosa peggiore che accadrà è che si perde un po 'di storia antica.

Se volete provarlo, allocare una grande quantità di memoria in ogni attività in modo che 5 o 6 riempirà la memoria disponibile, quindi provare.

Answer 4

commonsware è corretta. Non dovrete preoccuparvi di un overflow dello stack. :) Tuttavia, è possibile progettare l'applicazione per cancellare lo stack per evitare la situazione che hai descritto. Se vuoi in Cancellazione della pila , specificamente l'uso di chiaro superiore .

Answer 5

Quello che dovete fare è quello di memorizzare la storia in qualche struttura, piuttosto che fare affidamento sulla pila di mantenerla per voi. Poi si può mantenere la vostra esperienza utente buona e non soffiare lo stack.

Answer 6

Prova a rimuovere questo noHistory = "true" e invece mettere Android: launchMode = "singleTask" http://developer.android.com/guide/topics/ manifesti / activity-element.html # lMode Ma Mark @commonsware andrà tutto bene così com'è.

Answer 7

Sto avendo problemi simili con la mia domanda. Sembra che il problema sta nel numero di visualizzazioni nidificate per ogni attività. Quindi, se avete, per esempio:

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

e forse molti di più i raggruppamenti, le probabilità che ci si ottiene overflow dello stack dopo aver ottenuto da questo punto di vista a una simile e indietro più volte (nella mia esperienza) sono elevati. Controllare la nidificazione con hierarchyviewer (Android-sdk / tools). dimmi anche se si risolve il problema, perché io ancora non so come risolvere il problema ...