8

In primo luogo, so che con Model View Presenter ci sono diverse implementazioni, e nella mia mente finché hai i livelli di astrazione chiaramente definiti e facendo i loro ruoli nominati allora come implementare questo modello è aperto all'interpretazione. Ho implementato questo modello in alcune app dove c'era solo uno Activity. Ora ho avviato un nuovo progetto con più attività e allegato Fragments, compresi i frammenti annidati (ViewPager).Molteplici attività/frammenti e il modello View Presenter pattern

Ora sto provando a tradurre l'MVP in questo progetto e ho raggiunto un concept wall e vorrei ricevere alcune indicazioni e approfondimenti.

Finora ho creato la struttura di cui sopra e ho iniziato a fare una relazione 1: 1 con View & Presenter (indipendentemente da Activity o Fragment). Sento che questo è OK, tuttavia se per esempio ho inviato una richiesta per fare qualcosa da una vista Activity al Presentatore, che restituisce un risultato allo Activity Visualizza come andrei sulla propagazione del risultato, ovvero aggiorna tutte le altre Attività/Frammenti che al momento non si trova nello stato Paused() o Stop(). Mi sento come se in questo caso dovesse esserci un Presenter centrale che aggiorna tutte le visualizzazioni di attività e frammenti necessarie, ma non sono sicuro di come procedere.

Attualmente, quando si crea ogni Activity e Fragment crea una nuova istanza di una classe presentatore, passando in se stesso come riferimento (le Attività e Frammenti implementare le proprie interfacce), che i negozi presentatore come un WeakReference e può invocare il metodi di interfaccia rilevanti quando si restituisce un risultato.

Secondo i documenti ogni volta che Fragments desidera comunicare tra loro e l'allegato Activity è necessario utilizzare un'interfaccia di richiamata. Con questo in mente dovrei avere un'interfaccia di callback implementata da Activity e il callback Fragments ogni volta che richiedono qualcosa, quindi in sostanza solo l'Activity avrebbe un livello Presenter e Model a cui i Fragments devono fare callback per fare varie richieste ?

Scusate se questo suona un po 'confuso, si spera che questo sia abbastanza chiaro per capire cosa voglio raggiungere, e se sto pensando lungo le linee giuste ... o totalmente fuori dal marchio!

risposta

1

Penso che sia giusto avere un presentatore all'interno dell'attività. Fondamentalmente l'attività è come un controller, dovrebbe sapere del presentatore.

Sarebbe sbagliato inserire un presentatore in un frammento se anche l'attività o altri frammenti lo richiedono. È possibile inserire un presentatore in un frammento solo se questo presentatore è progettato specificamente per il frammento.

che i negozi presentatore come un WeakReference e in grado di richiamare i metodi di interfaccia rilevanti per la restituzione di un risultato

Perché avete bisogno di un WeakReference qui? Se hai una relazione 1: 1, suppongo che il tuo relatore non abbia il proprio ciclo di vita, il che significa che il suo ciclo di vita dipende dall'attività o dal frammento. Non c'è il rischio di avere perdite di memoria perché non è un singleton, giusto? Dovrebbe essere sicuro di avere un riferimento forte.

Non sono sicuro di aver risposto alla tua domanda perché mi sembra un po 'ampia. Il mio punto è che i frammenti sono solo "parti" di attività separate e dovresti trattarli come parti. Se il presentatore appartiene solo a questa parte, allora dovrebbe essere all'interno. Altrimenti dovrebbe essere in attività.Hai ragione sull'utilizzo di un interface per accedere all'attività, questo è un approccio progettuale ben noto che Google utilizza nei loro esempi.

+0

Grazie per i vostri commenti e pensieri. Penso che userò semplicemente Presenter con l'attività e lascerò che maneggi l'aggiornamento dei frammenti. Perdita di memoria con un Singleton? Ciò accadrebbe solo se Singleton avesse un riferimento a un'attività o un frammento (fondamentalmente qualcosa con un ciclo di vita che potrebbe andare e venire)? Se è così, io uso un singleton per qualcos'altro, ma non contiene riferimenti. Uso 'WeakReferences' con Attività e Frammenti (qualsiasi cosa con callback del ciclo di vita) poiché non devo' nullo' Riferimenti forti sulle modifiche di configurazione, e 'WeakReference' consente GC –

+0

Se il tuo presentatore non è un singleton allora non dovresti Ho problemi con le modifiche alla configurazione perché anche il relatore stesso verrà ricreato. Potrebbe essere necessario un 'WeakReference' se si utilizza un frammento mantenuto. Ad ogni modo, sembra che tu capisca chiaramente come funzionano i riferimenti deboli, quindi non ho bisogno di spiegarlo ... Grazie. –

+0

No il presentatore non è un singleton, Dopo che il presentatore è stato creato, ne memorizzo un riferimento in un 'HashMap ' all'interno di un frammento mantenuto senza testa e recupera il suo riferimento sulle modifiche di configurazione con l'Activity. ... Proprio quando penso di capire qualcosa in Java sembra che mi passi sempre una palla curva! Grazie per il tuo consiglio. –

1

No, nessuna interfaccia più. È possibile utilizzare RxJava Observables per aggiornare tutte le visualizzazioni come descritto in here o una sorta di Bus (Otto -deprecated o EventBus). E ti piacerà perché rendono l'interazione troppo facile.

+1

Grazie per i vostri commenti, ho dato un'occhiata a questi in breve - e sembrano abbastanza fattibili e interessanti. Stavo cercando una soluzione o un concetto di modello piuttosto che "questa libreria toglie la complessità". Non sono contro l'utilizzo di questo, o di altre librerie che risolvono problemi, lontano da esso, ma penso che sia importante per me comprendere una buona comprensione prima di utilizzare subito queste altre librerie che gestiscono molte delle complessità per voi. –

+0

İ lo chiamerei approccio di programmazione reattiva, non libreria. E non vedo altro modo di sfuggire a Rx nel prossimo futuro. –

+0

Cercherò di sicuro la programmazione Reattiva/RxJava, per ora, per me e questo progetto che comunica attraverso l'attività di hosting non è un problema. Non sono sicuro di condividere la tua convinzione che non esiste un modo per "sfuggire" alla programmazione reattiva, tuttavia rispetto la tua opinione. –