Android: uso previsto di frammenti con servizi, finestre di dialogo ecc.

Question

Ho creato app Android per alcuni mesi e sto riscontrando problemi con l'uso previsto di Fragments.

Fragments si suppone che siano componenti UI riutilizzabili, ma fino a che punto li fai stare da soli?

Uno degli Fragments che ho creato è un ListFragment di video scaricabili. Al momento ho implementato tutti i metodi all'interno dello Fragment con pochi o nessuno dei metodi che chiamano l'host Activity. Lo Fragment chiama lo Activity per alcune piccole cose, ma tutto come scaricare i file e trovarli su una memoria esterna viene effettuato dallo Fragment.

Il 90% delle volte trovo che sia il modo più semplice di implementarlo ma a volte non funziona.

Un esempio è una finestra di dialogo di conferma per l'eliminazione di un video nel mio ListFragment. La finestra di dialogo è una DialogFragment quindi è allegata allo Activity ma tutti i metodi di aggiornamento e cancellazione dell'interfaccia utente si trovano all'interno dello ListFragment. Così finisco con lo DialogFragment chiamando lo Activity solo per chiamare lo ListFragment.

Un altro esempio è vincolante per un Service. Legare lo Activity allo Service o solo allo Fragment? Lo Activity non ha alcuna utilità per lo Service ma è un Fragment che si suppone stia facendo tutto il lavoro di avvio e manutenzione di uno Service? In caso contrario, tutte le chiamate Fragments allo Service devono passare attraverso lo Activity in modo che lo Fragment non sia più autonomo.

Mi chiedo se sto prendendo l'idea stand alone troppo lontano, è un Fragment invece dovrebbe essere minimamente autonomo e in realtà fare affidamento sul Activity hosting per tutto il sollevamento di carichi pesanti?

Grazie per qualsiasi aiuto.

Answer 1

Una domanda molto interessante!

Di solito cerco di tenere i miei frammenti il ​​più isolati possibile. Ciò significa che di solito non gli faccio sapere nulla intorno a loro tranne che per la loro stessa attività. È quindi il ruolo dell'attività (se mi chiedi) di fornire ciò che è necessario al frammento.

In pratica ciò significa che i miei frammenti non possiedono mai i propri contenuti, come un provider di contenuti o un DAO personalizzato. L'attività (o - Dio non voglia - l'applicazione) lo possiede e quindi fornisce al frammento solo un sottoinsieme di dati, come un cursore, un oggetto dominio o un adattatore.

Ciò significa anche che quando un frammento modifica un elemento, deve chiedere all'attività di mantenere le modifiche. O se un elemento deve essere cancellato, il frammento deve chiedere all'attività di mostrare l'interfaccia utente corrispondente per quell'operazione (sì, è tecnicamente possibile lasciare che un frammento mostri un altro frammento, ma di solito cerco di evitarlo il più lontano possibile) .

Quando si tratta di servizi e vincolanti per loro, non so davvero cosa suggerire in quanto dipende in realtà dal servizio e da ciò che sta facendo. Se stai scaricando nuovi contenuti da Internet nel tuo servizio, sembra rettificato per consentire all'attività di gestire l'associazione (in quanto è l'attività che deve salvare i dati, in base alla discussione precedente).Se, d'altra parte, stai calcolando qualcosa di specifico, in base ai tuoi dati isolati (ad esempio decrittando un file o giù di lì), allora potrebbe fare in modo che il frammento gestisca quella parte.

In una prospettiva ancora più grande, ci si rende presto conto che un setup, come descritto sopra, darà vita a una serie di interfacce di callback in quanto ogni frammento deve stabilire un contratto per la sua attività. Quindi, per progetti più piccoli, a volte capita di scavalcare il mio stesso frammento di pardigmi.

Inoltre, non posso fare a meno di notare che quando utilizzo i frammenti, le mie applicazioni tendono ad essere molto orientate all'MVC nella loro architettura. Lascio a voi e tutti i futuri lettori a decidere wether è una buona o cattiva cosa ;-)

Acclamazioni