Android: cosa c'è di meglio: più attività o cambio di visualizzazione manualmente?

Ho sviluppato alcune app per Android e questa domanda rimane sempre:

Come devo strutturare la mia interfaccia utente? Devo avviare attività dopo attività e lasciare che il telefono faccia il pulsante "indietro", o dovrei scegliere più ottimizzato, ma più complesso da implementare, cambiando manualmente le viste e poi facendo manualmente la funzionalità del pulsante "Indietro"?

Quale pensi (o sai) sia la pratica migliore?

Direi che più attività hanno quasi sempre più senso. Non penso che Android sia progettato per cambiare costantemente le proprie visualizzazioni: ti perdi così tanto. Devi implementare Back da solo, non si ottengono transizioni tra le attività, devi implementare molta logica interna per riprendere un'applicazione nello stato corretto. Se non dividi la tua app in Attività, diventa molto più difficile in seguito cambiare il flusso della tua applicazione. Si traduce anche in una mega-attività che può essere molto più difficile da gestire rispetto a molti piccoli pezzi di codice.

Ho difficoltà a immaginare che la velocità sia davvero un problema; se lo è, allora c'è qualcosa di sbagliato nel modo in cui stai inizializzando ciascuna attività. Ad esempio, provavo a passare oggetti serializzabili tra le attività e ciò si è rivelato incredibilmente lento; quando sono passato a un metodo più veloce per far passare gli oggetti, la velocità di lancio delle attività è aumentata immensamente.

Inoltre, penso che sia significativo che le linee guida di Android per Activity e Task Design non menzionino affatto il cambio di visualizzazione; è incentrato su un progetto Activity-as-View.

Vorrei sottolineare alcuni casi in cui una singola attività potrebbe essere migliore per un'applicazione Android che ha più di una vista a schermo intero:

• Se le schermate dell'applicazione sono strettamente collegate e condividono un oggetto comune su cui stanno tutte operando. In questo caso, il passaggio dell'Oggetto potrebbe richiedere un Bundle e può essere soggetto a errori poiché ci saranno copie di esso. Un buon esempio potrebbe essere un mago . Sì, potresti usare static per accedere all'oggetto comune, ma static può essere pericoloso in Android (pensa alle modifiche alla configurazione!)

• Se vuoi delle animazioni davvero fantastiche tra gli schermi. Forse vuoi che un uccello decolli in uno schermo e atterri in un altro schermo. Prova a farlo quando ogni schermata è un'attività!

D'altra parte, se uno dei tuoi schermi è progettato per essere mostrato da un numero qualsiasi di altre applicazioni, allora quello schermo dovrebbe essere la propria attività.

AGGIORNAMENTO marzo 2014:

A questo punto la domanda dovrebbe ora includere la scelta dei frammenti. Penso che le viste siano probabilmente la scelta meno probabile delle 3: attività, frammento, vista. Se si desidera implementare schermate che utilizzano il pulsante Indietro, dovrebbe essere Activties o Fragments perché entrambi gestiscono il pulsante Indietro in modo nativo. I frammenti dovranno essere aggiunti allo stack posteriore FragmentManager affinché il pulsante Indietro funzioni. Tuttavia, gestire frammenti, dialoghi e back stack può essere un po 'fastidioso!

AGGIORNAMENTO Settembre 2018:

Alcuni sviluppatori di Google consigliano app ad attività singola utilizzando il nuovo componente dell'architettura di navigazione .

Tieni inoltre presente che l'implementazione della tua app con più elementi Activitiesoffrirà all'utente un'esperienza più coerente con la piattaforma nel suo insieme. Parte dell'esperienza sarà plasmata utilizzando le app Google integrate, quindi gli utenti avranno probabilmente un tempo più facile utilizzando la tua applicazione se si comporta in modo simile a quelle già installate sul telefono.

Diverso dagli altri, uso una combinazione di entrambi, ad esempio,
1. C'è un menu principale all'avvio dell'applicazione
2. Fai clic su Cerca, ti porta all'attività di ricerca
3. Poi c'è un pulsante di filtro, che cambia solo visualizzazione e mostra puoi filtrare le opzioni
4. Ci sono due pulsanti alla fine della visualizzazione del filtro, premi "Cerca" o "Annulla" e torni di nuovo alla visualizzazione della ricerca (senza cambiare attività)
5. Ora se l'utente preme il telefono viene riportato al menu principale invece che alle opzioni del filtro di ricerca. Che credo sia il comportamento corretto.

Usalo nel modo in cui l'utente si sentirà naturale. E tenere tutto in un'unica attività lo renderà complesso.

Tutto dipende dall'applicazione, da cosa stai cercando di ottenere prestazioni migliori, interfaccia utente più fluida. IMHO preferisco il secondo approccio del controllo manuale delle attività anche se è più complesso come hai affermato. Questo è un approccio che ho usato nel mio progetto di schede Android, inoltre potresti voler dare un'occhiata a una classe chiamata ActivityGroup (non sono sicuro del pacchetto) ti consente di avere più attività tra cui puoi passare, cosa buona di questa classe è che le tue attività non vengono scaricate quando cambi, ma una cosa negativa è che ci vuole più tempo per caricare la tua app principale.

Solo la mia opinione.

Il problema con il cambio di visualizzazione, in cui mi sono imbattuto, è causato anche dal garbage collector. Sembra che GC venga attivato quando esci dall'attività e non dalla visualizzazione. Quindi, cambiare le schede con una visualizzazione dei figli abbastanza complessa, ad esempio, porterà quasi inevitabilmente a un'eccezione di overflow dello stack.

Ho riscontrato così tanti problemi con il layout di attività multiple che lo sconsiglio vivamente, a meno che non ci siano buone ragioni per sceglierlo.

Svantaggio di molteplici attività

Utilizzando più attività è molto difficile effettuare il refactoring del codice per restituire i dati dall'attività.

Se chiami un'attività "secondaria", l'attività principale potrebbe essere interrotta. Ma non lo si verifica mai durante il debug su un dispositivo decente, quindi è necessario gestire sempre lo stato di salvataggio e il ripristino corretto dello stato. Questo è un dolore. Immagina di chiamare un metodo su una libreria (es. Un'altra attività) e dovresti assicurarti che quando quel metodo restituisce la tua app deve essere in grado di ricreare completamente il suo stato con tutti i campi su tutti gli oggetti nella VM (es. Attività. restoreIntance). È da pazzi.

Anche viceversa, quando apri una sottoattività, la VM potrebbe essere stata interrotta da quando la sottoattività è stata generata per la prima volta, ad esempio quando l'app è ridotta a icona mentre viene visualizzata la sottoattività.

È molto più pulito avere un solo posto in cui memorizzare lo stato dell'app pertinente e, nel mio caso, il più delle volte se la VM viene uccisa, voglio riportare l'utente alla schermata principale e lasciargli fare di nuovo le sue cose, perché non lo faccio non spendere 30-50 ore a codificare funzionalità di salvataggio / ripristino che lo 0,1% degli utenti sperimenterà mai.

Alternativa

Frammenti o gestisci tu stesso le visualizzazioni delle tue attività. La gestione manuale delle viste richiede la codifica di un'alternativa di cambio di visualizzazione alle attività / frammenti con transizioni se lo si desidera.

E no, non significa una mega-attività, come suggerito nella risposta accettata, in nessun altro modo rispetto alla sua unica mega-app. Richiede solo un po 'più di progettazione della base di codice in parti adatte, perché c'è un po' più di lavoro nella gestione delle visualizzazioni, sebbene molto meno lavoro nella gestione dello stato delle attività e altre stranezze.

Possibilmente rilevante: Reddit: È ufficiale: Google raccomanda ufficialmente l'architettura delle app per attività singola