Un'attività e tutti gli altri frammenti [chiuso]

Sto pensando di implementare una schermata con Activitye tutte le altre schermate con Fragmentse managing all the fragments thru the activity.

È una buona idea? e la mia risposta è NO, ma voglio ancora sapere più chiaramente di questo pensiero.

Quali sono i pro e i contro dell'idea?

Nota:

Per favore, non darmi il link per frammento e attività.

MODIFICARE:

Ecco qualcosa sui frammenti e l'attività:

Professionisti:

1. I frammenti sono pensati per essere utilizzati con attività come attività secondaria.
2. I frammenti non sostituiscono le attività.
3. I frammenti sono pensati per la riusabilità (è necessario sapere in che modo è possibile ottenere la riusabilità).
4. I frammenti sono il modo migliore per scrivere codice per supportare sia tablet che telefoni.

Contro:

1. Dobbiamo implementare l'interfaccia per ottenere i dati dai frammenti.
2. Per il dialogo dobbiamo fare molto per dimostrarlo.

Perché dovremmo usare i frammenti se non stiamo prendendo in considerazione le compresse? Qual è la differenza di orario iniziale tra attività e frammento?

Dipende dall'app che stai creando. Ho creato diverse app usando entrambi gli approcci e non posso dire che un modo sia sempre migliore dell'altro. L'ultima app che ho creato ho usato il singolo Activityapproccio e una navigazione in stile Facebook. Quando seleziono elementi dall'elenco di navigazione, aggiorno un singolo Fragmentcontenitore per visualizzare quella sezione.

Detto questo, avere un singolo Activityintroduce anche molte complessità. Supponiamo che tu abbia un modulo di modifica e che per alcuni degli elementi che l'utente deve selezionare o creare, richieda l'accesso a una nuova schermata. Con le attività che chiameremmo semplicemente con la nuova schermata, startActivityForResultma che Fragmentsnon esiste nulla del genere, si finisce per archiviare il valore su Activitye fare controllare il frammento di modifica principale Activityper vedere se i dati sono stati selezionati e devono essere visualizzati all'utente.

Ciò che Aravind dice di essere bloccato su un singolo Activitytipo è anche vero, ma non è poi così limitante. La tua attività sarebbe un frammento di attività e fintanto che non ne avrai bisogno, non MapViewci saranno limiti reali. Se vuoi visualizzare le mappe però, puoi farlo, ma dovrai modificare la libreria di compatibilità Android per FragmentActivityestenderla MapActivityo utilizzare le android-support-v4-googlemaps pubblicamente disponibili .

Alla fine, la maggior parte degli sviluppatori che conosco e che Activitysono passati all'unica rotta sono tornati a più attività per semplificare il loro codice. Per quanto riguarda l'interfaccia utente, su un tablet, a volte sei bloccato usando un singolo Activitysolo per ottenere l'interazione sempre folle che i tuoi progettisti escogitano :)

-- MODIFICARE --

Google ha finalmente rilasciato MapFragmentla libreria di compatibilità, quindi non è più necessario utilizzare l'hack android-support-v4-googlemaps. Leggi qui l'aggiornamento: API di Google Maps per Android v2

- MODIFICA 2 -

Ho appena letto questo fantastico post sul moderno stato dei frammenti (2017) e mi sono ricordato di questa vecchia risposta. Ho pensato di condividere: Frammenti: la soluzione a tutti i problemi di Android

Sto per finire un progetto (5 mesi di sviluppo), che ha 1 attività e 17 frammenti, tutti a schermo intero. Questo è il mio secondo progetto basato su frammenti (il precedente era di 4 mesi).

Professionisti

• L'attività principale è di 700 righe di codice, gestendo semplicemente l'ordine di navigazione dei frammenti.
• Ogni frammento è ben separato nella sua classe ed è relativamente piccolo (~ duecento righe di roba dell'interfaccia utente).
• Il management può dire "ehi, che ne dici di cambiare l'ordine di quegli schermi", e posso farlo molto facilmente, dato che quei frammenti non dipendono l'uno dall'altro, comunicano tutti attraverso l'attività. Non devo scavare tra le singole attività, per trovare dove si chiamano.
• la mia app è molto grafica e non funzionerebbe mai come attività 1 schermo 1. Tutte quelle attività secondarie in memoria, farebbero in modo che l'app esaurisse sempre la memoria, quindi avrei dovuto finish()tutte le attività non visibili e farei la stessa logica di controllo per la navigazione, come farei con i frammenti. Potrebbe anche farlo con frammenti solo per questo.
• se mai realizzassimo un'app per tablet, avremo un tempo più semplice per riprogrammare le cose, perché tutto è già ben separato.

Contro

• devi imparare come usare i frammenti

Innanzitutto, qualunque cosa tu faccia, assicurati di avere un design modulare usando modello, vista, presentatore che non dipendono fortemente da un'attività o da un frammento.

Cosa offrono realmente le attività e i frammenti?

1. Eventi del ciclo di vita e backstack
2. Contesto e risorse

Pertanto, usali per questo, SOLO . Hanno abbastanza responsabilità, non complicarli troppo. Direi che persino intuire un TextView in un'attività o in un frammento è una cattiva pratica. Esiste una ragione per cui metodi come public view findViewById (int id) sono PUBBLICI .

Ora la domanda diventa più semplice: sono necessari più eventi e backstacks del ciclo di vita indipendenti? Se pensi di sì forse, usa i frammenti. Se non pensi mai, non usare frammenti.

Alla fine, potresti creare il tuo zaino e i tuoi cicli di vita. Ma perché ricreare la ruota?

EDIT: Perché votare questo? Classi monouso persone! Ogni attività o frammento dovrebbe essere in grado di creare un'istanza di un presentatore che crea un'istanza di una vista. Il presentatore e la vista sono un modulo che può essere scambiato. Perché un'attività o un frammento dovrebbe avere la responsabilità di un presentatore ??

Professionisti

Puoi controllare i tuoi frammenti da una singola attività, perché tutti i frammenti sono indipendenti l'uno dall'altro. I frammenti hanno un ciclo di vita ( onPause, onCreate, onStart...) della propria. Avendo un ciclo di vita, i frammenti possono rispondere in modo indipendente agli eventi, salvare il loro stato onSaveInstanceStateed essere riportati (ad esempio quando riprendono dopo una chiamata in arrivo o quando l'utente fa clic sul pulsante Indietro).

Contro

1. Crea complessità nel tuo codice di attività.
2. Devi gestire l'ordine dei frammenti.

Tuttavia, è una buona idea, come se fosse necessario creare un'app, in cui si desidera mostrare più visualizzazioni. Con questa idea, sarai in grado di visualizzare diversi frammenti in un'unica vista.

Dipende dal layout del design della tua app. Supponiamo che se si utilizzano le schede in ActionBar nel layout di progettazione, nell'Attività singola dell'app è possibile modificare i frammenti facendo clic su Tab. Quindi ora hai un'attività e supponi di supporre tre schede nella barra delle azioni e la vista per le schede fornite dai frammenti, il che semplifica la gestione del plus è anche possibile. Quindi, tutto dipende dallo schema di progettazione della tua app e da come prendi la decisione di costruirla.

Professionisti:

• Può essere utilizzato per creare un'unica interfaccia utilizzabile da più dimensioni e orientamenti dello schermo tramite layout XML.

Contro:

• Richiede un codice più complesso nella tua attività.

Credo che sia una buona idea, perché l'utilizzo di diversi layout XML basati sulle dimensioni e l'orientamento dello schermo correnti può rendere l'app più utilizzabile e ridurre la necessità di rilasciare più versioni dell'app se si prevede di rilasciare l'app sia per telefoni che per tablet. Se la tua app non verrà mai utilizzata da tablet e telefoni, probabilmente non ne vale la pena.

Sono un sostenitore del differimento dell'inflazione di tutti i punti di vista in frammenti per fornire una maggiore flessibilità. Ad esempio avere un'unica attività di atterraggio per un tablet che aggrega più frammenti e riutilizza gli stessi frammenti su un telefono per mostrare uno schermo per frammento. Tuttavia nell'implementazione del telefono avrei un'attività separata per ogni schermo. Le attività non avrebbero troppi codici poiché rimanderebbero immediatamente alla loro controparte frammentaria per visualizzare l'inflazione.

Penso che sia una cattiva idea che l'implementazione del telefono debba passare a una singola attività di atterraggio quando vengono introdotte le schede o un menu scorrevole poiché la navigazione della scheda o del menu si traduce in una schermata completamente nuova.

Il motivo più importante che darei per non utilizzare l'approccio a singola attività è che il ciclo di vita dell'attività può essere sfruttato. Le attività contengono comportamenti contestuali di una determinata porzione dell'applicazione e frammenti completano tale comportamento. Avere la capacità di trarre vantaggio dai passaggi scavalcabili nel ciclo di vita delle attività aiuta a separare il comportamento di un'attività da un altro con metodi come onPausee onResume. Questo ciclo di vita consente anche di tornare al contesto precedente. Con l'approccio a singola attività, una volta che lasci un frammento devi creare un meccanismo per tornare ad esso.