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


158

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?


Puoi spiegare perché pensi che la risposta sia no? Mi capita di non essere d'accordo, ma è più facile rispondere alle preoccupazioni che potresti avere riguardo a questo approccio se sappiamo quali sono queste preoccupazioni.
Alexander Lucas,

1
@AlexanderLucas La risposta che ho dato no perché farlo rende il tuo codice meno modulare, aumenta la complessità.
Vineet Shukla,

@Ski Ti stai concentrando maggiormente sull'accettazione della tua risposta, per favore ti concentri su ciò che ti viene chiesto e su quale dovrebbe essere la migliore risposta che puoi fornire.
Vineet Shukla,

3
Per chiunque lo trovi, ho fermato il refactor perché le cose si sono complicate molto velocemente.
theblang,

18
Questa è una buona domanda e non avrebbe dovuto essere chiusa.
Jim In Texas,

Risposte:


94

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


6
C'è settargetfragmente potresti gestire l'attività come una startforresultprocedura.
Lalith B,

1
Secondo me le attività esistono solo perché è il vecchio sistema. Il frammento non esisteva prima. Non c'è davvero nulla che le attività possano fare e i frammenti no, oltre alle formalità. Potrei persino immaginare che ad un certo punto le attività vengano rimosse e tutto sia un frammento.
Ixx il

1
Riassumendo i contro dei frammenti: solo tu dai, non ce ne sono davvero. startActivityForResult come dice Lalith B ha una controparte e anche le mappe non sono un problema. Inoltre, tutto (stato salvifico, ecc.) Può essere gestito con i metodi del ciclo di vita del frammento.
Ixx il

85

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

1
non ero sicuro di avere troppi frammenti e solo ora l'attività ... qualsiasi problema di produzione, e la colpa è tua !! :)
Shahar,

1
@Dinash non consente al sistema operativo di riavviare la tua attività. gestisci tu stesso l'orientamento. leggi di più qui: stackoverflow.com/questions/5913130/…
Tamas,

1
@Tamas Avevi schermi multi-frammento (es. Master-detail) e in tal caso come hai gestito?
theblang

7
@Tamas Questo approccio è fortemente anti android. Finisci con la classe DIO. Il sistema Android è progettato per funzionare con le attività, ad esempio non hai un buon modo di gestire le barre degli strumenti all'interno di più frammenti. Non hai il frammento iniziale per il risultato e molti altri non hanno. Ciò significa che devi riscrivere l'intera logica che è già lì. Che dire di ricevitori di trasmissione locale, servizi e altri componenti Android. Per avviare un servizio devi fare quanto segue: getActivity ()! = Null ... questo è davvero brutto. Anche la comunicazione tra i frammenti è molto strana se hai molti fr.
Teodor,

9
700 linee !!!! "bene" ???? Le lezioni sono gratuite.
Beplaya,

16

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 ??


Hm ... la connessione tra l'istanza di una vista è una cattiva pratica e findViewById () public non è chiara. Mentre sono d'accordo sull'istanza delle viste, considero anche la chiamata di findViewById da un'altra classe (ad esempio l'attività che ospita un frammento lo chiama sul frammento) una cattiva pratica. Non so davvero perché sia ​​pubblico, dal momento che, almeno nei casi a cui riesco a pensare, questo si traduce in codice disordinato e non in un design modulare.
Ixx il

IMHO: Se passi un'attività nella tua vista e presentatore (chiamando i 2 combinati un "modulo"), puoi riutilizzare quel modulo con altre attività. Se aiuta, potrebbe essere meglio passare l'attività come un'intrusione che espone solo necsary thngs. Se odiate trovare viste al di fuori dell'attività, allora potete iniettare tutte le viste, attraverso quella interfaccia, nella vista pres /. il punto principale è che credo che la codifica Android dovrebbe essere fatta al di fuori del concetto di Actvities and Frags, tanto che agitarsi tra il 2 è facile. Quindi, diventa chiaro che è bst e non sei bloccato con l'uno o l'altro all'interno di una rete di codice.
Beplaya,

3
Lascia andare l'MVP, starai meglio senza Android. Puoi passare molto tempo a cercare di inserire un determinato blocco di forma in un foro di forma diversa, sicuramente è una sfida, ma probabilmente ci sono requisiti funzionali su cui saresti più saggio.
straya,

12

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.


2

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.


1

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.


Per l'orientamento non è necessario utilizzare diversi layout basati su XML.
Vineet Shukla,

@VineetShukla vero, ma è un'opzione, proprio come usare diversi layout XML basati sulla dimensione dello schermo. Ad esempio, la schermata iniziale del mio telefono Android ha un layout diverso quando lo visualizzo in orientamento orizzontale rispetto a verticale.
Sci,

0

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.


"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." -> Non è comprensibile cosa intendi esattamente, ma né le schede né il menu laterale sono un problema in un'app a singola attività (tablet / telefono).
Ixx il

-1

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.


4
Non credo sia vero. Dalla documentazione del ciclo di vita del frammento ( developer.android.com/guide/components/fragments.html#Lifecycle ): "Il ciclo di vita dell'attività in cui vive il frammento influenza direttamente il ciclo di vita del frammento, in modo tale che ogni callback del ciclo di vita per l'attività provoca un callback simile per ogni frammento. Ad esempio, quando l'attività riceve onPause (), ogni frammento nell'attività riceve onPause (). "
Sci,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.