Quante attività contro frammenti?

Intro:

Il model "Fragments Tutorial" di base va in questo modo:

  1. Su una tavoletta, hai un elenco a sinistra, dettagli sulla destra.
  2. Entrambi sono Fragments e entrambi risiedono nella stessa Activity .
  3. Su un telefono, hai un elenco di Fragment in un'attività.
  4. Lanciare una nuova Activity con i dettagli Fragment .

(ad es. API di Fragmenti Android 3.0 di Dianne Hackborn e la Guida agli API di Fragments )

  • Come avviare un'applicazione android con valgrind
  • Vista di elenco di Android con l'applicazione di crash dell'adattatore di simplecursor (nessun ANR mostrato)
  • Perché l'applicazione è in attesa del debugger quando non è connesso al computer?
  • come caricare più di 1 MB di dati da sqlite db a cursore android?
  • Impostare la width e l'altezza di ImageView in modo programmato?
  • Realm con dati preimpostati in beni?
  • Su entrambi i dispositivi, la funzionalità è nei Fragments . (semplice)

    Sul Tablet , l'intera applicazione è 1 Activity , sul telefono cellulare , ci sono molte Activities .


    Le domande:

    • C'è un motivo per dividere l'applicazione del telefono in molte Activities ?

    Un problema con questo metodo è che duplicate gran parte della logica nell'attività principale del tablet e nelle Activities telefoniche separate.

    • Non sarebbe più facile mantenere il model di attività 1 in entrambi i casi, utilizzando la stessa logica di commutazione di Fragments in Fragments e in output (solo utilizzando un layout diverso)?

    In questo modo la maggior parte della logica risiede nei Fragments stessi, e c'è solo una singola Activity – less duplicazione di codice.

    Anche quello che ho letto su ActionBarSherlock è che sembra funzionare meglio con Fragments invece di Activities (ma non ho ancora lavorato con esso).

    I tutorial sono troppo semplici, o ho perso qualcosa di importnte in questo approccio?


    Abbiamo provato entrambi gli approcci con successo in ufficio – ma sto per iniziare un progetto più grande e voglio rendere le cose più facili per me ansible.

    Alcuni collegamenti alle domande correlate:

    • Dilemma: quando utilizzare frammenti vs attività:
    • Modelli quando utilizzare Transizione attività vs frammenti dinamici
    • Android – Ho bisogno di alcuni chiarimenti di frammenti vs attività e opinioni
    • Attività o frammenti in Android?
    • Progettazione di interazioni di frammenti e attività multiple
    • Quindi quali sono i vantaggi esatti di Frames in Android 3.0?

    aggiornamenti

    Inizia la bontà in questione – ancora non convinto di perché devo duplicare la mia logica app nella mia attività di tablet e in each attività telefonica.

    Ha trovato anche un interessante articolo dai ragazzi di Square, che vale la pena di leggere:

    • Advocating contro i frammenti di Android

  • ArrayAdapter in grado di aggiornare i contenuti
  • Concetti di meccanismi IPC
  • Schermo nero Android VideoView
  • Come leggere il file di image memorizzato nella memory interna?
  • Android Async, gestore o timer?
  • Come posso implementare una tastiera soft speciale
  • 5 Solutions collect form web for “Quante attività contro frammenti?”

    Sono d'accordo che i tutorial sono molto semplificati. Esse introducono solo Fragments ma non sono d'accordo con il model come suggerito.

    Accetto inoltre che non è una buona idea duplicare la logica della tua applicazione in molte attività (vedere il principio DRY su wikipedia ).


    Preferisco il model utilizzato dall'applicazione ActionBarSherlock Fragments Demo ( qui scaricare qui e il codice sorgente ). La demo che più corrisponde esattamente al tutorial citato nella domanda è quella chiamata "Layout" nell'applicazione; o FragmentLayoutSupport nel codice sorgente.

    In questa demo, la logica è stata spostata Activity e nel Fragment . Il TitlesFragment contiene in realtà la logica per il cambiamento di frammenti. In questo modo, each attività è molto semplice. Per duplicare molte attività molto semplici, where nessuna delle logiche è all'interno delle Attività, lo rende molto semplice.

    Mettendo la logica nei frammenti, non è necessario scrivere il codice più di una volta ; è disponibile a prescindere dall'attività in cui viene inserito il frammento. Questo lo rende un model più potente di quello suggerito dal tutorial di base.

      /** * Helper function to show the details of a selected item, either by * displaying a fragment in-place in the current UI, or starting a * whole new activity in which it is displayed. */ void showDetails(int index) { mCurCheckPosition = index; if (mDualPane) { // We can display everything in-place with fragments, so update // the list to highlight the selected item and show the data. getListView().setItemChecked(index, true); // Check what fragment is currently shown, replace if needed. DetailsFragment details = (DetailsFragment) getFragmentManager() .findFragmentById(R.id.details); if (details == null || details.getShownIndex() != index) { // Make new fragment to show this selection. details = DetailsFragment.newInstance(index); // Execute a transaction, replacing any existing fragment // with this one inside the frame. FragmentTransaction ft = getFragmentManager() .beginTransaction(); ft.replace(R.id.details, details); ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE); ft.commit(); } } else { // Otherwise we need to launch a new activity to display // the dialog fragment with selected text. Intent intent = new Intent(); intent.setClass(getActivity(), DetailsActivity.class); intent.putExtra("index", index); startActivity(intent); } } 

    Un altro vantaggio del model ABS è che non si finisce con un'attività di compressione contenente un sacco di logica, il che significa che si salva la memory. Il model di tutorial può portre ad una grande attività principale in un'applicazione più complessa; poiché deve gestire la logica di tutti i frammenti che vengono inseriti in qualsiasi momento.

    Nel complesso, non pensare che sia costretto ad utilizzare molte attività. Pensa di avere l'opportunità di dividere il tuo codice in molti frammenti e di risparmiare memory quando li usa.

    Penso che tu sia sulla buona strada. (E sì, i tutorial sono troppo semplificati).

    In un layout di tavoletta, è ansible utilizzare una singola attività e sostituire frammenti (in più "riframeworks"). Mentre in un layout telefono è ansible utilizzare una nuova attività per each frammento.

    Così:

    immettere qui la descrizione dell'immagine

    Può sembrare molto lavoro aggiuntivo, ma utilizzando molteplici attività per i telefoni, abiliti il ​​ciclo di vita di attività di base e il passaggio di intenti. Ciò consente inoltre al framework di gestire tutte le animazioni e la back-stack.

    Per ridurre il codice è ansible utilizzare una BaseActivity e estendersi da questo.

    Quindi, se l'utente dispone di una tavoletta si utilizza MyMultiPaneFragActivity o qualcosa di simile. Questa attività è responsabile della gestione delle richieste dei frammenti e degli intenti di routing al frammento corretto (ad esempio un intento di ricerca)

    Se l'utente dispone di un telefono cellulare, è ansible utilizzare un'attività regolare con un codice molto piccolo e estenderlo a MyBaseSingleFragActivity o qualcosa di simile. Queste attività potrebbero essere molto semplici, 5-10 righe di codice (forse anche less).

    La parte difficile è la routing di intenti e cosa non. * (Modifica: vedere di seguito).

    Penso che il motivo per cui questo sia il modo consigliato è salvare la memory e ridurre la complessità e l'accoppiamento. Se si scambia frammenti, il FragmentManager mantiene un riferimento a quel frammento per la back-stack. Inoltre semplifica ciò che dovrebbe essere "in esecuzione" per l'utente. Questa configuration scollegge inoltre le viste e il layout e la logica nel frammento dal ciclo di vita dell'attività. In questo modo un frammento può esistere in un'unica attività, accanto a un altro frammento (due riframeworks) o in un'attività a tre riframeworks ecc.

    * Uno dei vantaggi di avere routing regolari di intenti è che puoi lanciare un'attività in modo esplicito da qualsiasi punto del back-stack. Un esempio potrebbe essere nel caso dei risultati di ricerca. (MySearchResults.class).

    Leggere qui per ulteriori informazioni:

    http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html

    Potrebbe essere un lavoro più avanzato, perché each frammento deve funzionare bene attraverso attività separate, ma in genere paga. Ciò significa che è ansible utilizzare file di layout alternativi che definiscono combinazioni di frammenti diversi, mantengono il codice di frammento modulare, semplificano la gestione delle barre di azione e consentono al sistema di gestire tutto il lavoro di back stack.

    Ecco la risposta di Reto Meier riguardo allo stesso, tratto da questo video del corso Android Fundamentals di Udacity .

    Ci sono un certo numero di motivi per cui saresti meglio rompere l'applicazione in diverse attività.

    • Avere un'unica attività monolitica aumenta la complessità del codice, rendendo difficile leggere, testare e mantenere.
    • Fa creare e gestire i filtri di intenti molto più duri.
    • Aumenta il rischio di accoppiamenti stretti di componenti indipendenti.
    • Rende molto più probabile l'introduzione di rischi per la sicurezza se la singola attività comprende informazioni sensibili e informazioni che sono sicure da condividere.

    Una buona norma è creare una nuova attività each volta che il context cambia. Ad esempio, visualizzare un diverso tipo di dati e passare dalla visualizzazione all'inserimento dei dati.

    Un problema con questo metodo è che duplicate gran parte della logica nell'attività principale del tablet e nelle attività telefoniche separate.

    Nel model master-detail, ci sono due attività. Uno mostra entrambi i frammenti su schermi più grandi e solo il frammento "master" su schermi più piccoli. L'altra mostra il frammento "dettaglio" su schermi più piccoli.

    La tua logica di dettaglio dovrebbe essere legata nel frammento di dettaglio. Quindi non esiste duplicazione di codice legata alla logica di dettaglio tra le attività – l'attività di dettaglio mostra solo il frammento di dettaglio, forse passando ai dati da un Intent extra.

    Anche quello che ho letto su ActionBarSherlock è che sembra funzionare meglio con frammenti invece di attività (ma non ho ancora lavorato con esso).

    ActionBarSherlock non ha più a che fare con i frammenti che la barra di azione nativa, in quanto ActionBarSherlock è puramente un backport della barra di azione nativa.

    Facendo riferimento alla prima domanda di "C'è una ragione per dividere l'applicazione del telefono in molte attività?" – Sì. semplicemente arriva allo spazio disponibile, un tablet offre maggiore spazio agli sviluppatori, consentendo così agli sviluppatori di mettere più su uno schermo. Android ci dice che le attività possono fornire uno schermo . Così quello che puoi fare con un grande schermo su una tavoletta è qualcosa che potrebbe essere necessario diffondere su più schermate di un telefono cellulare, perché non c'è abbastanza spazio per tutti i frammenti.

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.