Difficoltà nell'implementazione di Model-View-Presenter in Android

Question

Model-View-Presenter (MVP) è un modello di progettazione ben noto per le applicazioni GUI. Per Android, l'implementazione della logica di business in un semplice modulo Java facilita il test senza richiedere un emulatore Android.

Tuttavia, sto avendo difficoltà di attuazione del modello su Android a causa dei requisiti speciali per l'interfaccia grafica delle applicazioni Android:

• per attivitá può essere distrutto in qualsiasi punto (chiamata in arrivo, l'utente preme il tasto di casa, ...), e quando ricreato dovrebbe essere nello stesso identico stato di quando è stato lasciato. Questo è diverso dalla maggior parte delle altre applicazioni GUI.

• Un'attività può attraversare molti stati del ciclo di vita. Potrebbe essere sospeso, nel qual caso l'interfaccia utente dell'attività non dovrebbe essere modificata. Se per esempio alcuni dati vengono caricati in background, non possono essere consegnati alla parte View di MVP (Activity) se si trova in uno stato di pausa. Ancora una volta, questo è un requisito insolito.

Ho letto il post sul blog MVP for Android e guardò il example source code. L'obiettivo finale che sto cercando di ottenere utilizzando il pattern MVP è di essere in grado di tradurre tutte le logiche di business in Objective-C utilizzando il transpiler j2objc, in modo che la logica di business possa essere riutilizzata mentre si implementa la stessa app su iOS.

C'è qualcuno che ha implementato correttamente il pattern MVP per Android e, in tal caso, cosa mi manca?

Answer 1

Suggerisco di implementare la componente MVP senza coinvolgere Activity, forse pensando concettualmente a cosa sarebbe utile su Android e GWT. Crea il componente utilizzando lo sviluppo basato su test con un'interfaccia di visualizzazione fittizia, aggiungendo test fino a quando la logica di business non sarà completamente implementata e verificata. TDD aiuta a mantenere snelle le API del componente (perché scrivere test per cose che non ti servono?), Il che rende più semplice il porting del componente.

I requisiti di attività che si descrivono possono essere generalizzati per essere indipendenti dalla piattaforma: il componente deve essere serializzabile (piccola 's', non in particolare la serializzazione Java) e deve accettare eventi dello stato del ciclo di vita. Anche quelli possono essere completamente testati utilizzando i mock per le funzionalità di sistema. Man mano che procedi con questo passaggio, probabilmente noterai che alcuni dei requisiti di attività sono necessariamente specifici di Android e potrebbero essere utili su altre piattaforme. Evitare di creare enormi API di servizi; per supportare la serializzazione, ad esempio, tutto ciò che è necessario sono metodi di archiviazione/caricamento, non qualcosa come lo Parcel API. Ho trovato che descrivere tali API di servizio a un altro sviluppatore su una lavagna è un ottimo modo per trovare inutili fluff.

Successivamente, porta il componente su Android, creando eventualmente un'attività che delega al componente e fornisce classi di implementazione specifiche per Android per le interfacce fittate. Dovrebbe tutto "funzionare solo" la prima volta, ma in realtà, alcuni requisiti potrebbero essere stati persi, quindi aggiungerli alla parte indipendente dalla piattaforma e ripetere.

Quando sei pronto per eseguire il porting su iOS, reimplementare quelle interfacce precedentemente derise. Se queste interfacce sono snelle, sarà probabilmente più facile crearle direttamente in Objective-C, importando le intestazioni di protocollo generate da j2objc. Ad esempio, la classe NSDictionaryMap di j2objc implementa java.util.Map con un'implementazione NSDictionary - non è necessario scrivere e tradurre una versione Java poiché utilizza solo le API iOS.

Answer 2

Trovo che la variante MVP Android sia costruita attorno è un passo nella giusta direzione per isolare la logica di business in un'app.Tuttavia, se si desidera ottenere una migliore separazione delle preoccupazioni e, di conseguenza, una logica di dominio/business più riutilizzabile, si consiglia di utilizzare lo Presenter First pattern (che nel commento si menziona brevemente). Oltre a diminuire l'accoppiamento, si presta bene a TDD e consente di testare tutte le logiche aziendali.

Recentemente ho avviato un repository GitHub con Presenter First per Android. A causa della complessità dell'architettura Android, non è semplice implementare il modello. Le visualizzazioni tendono ad essere "più grasse" di quelle che sembrano accettabili in una normale app di Presenter First, principalmente a causa del ciclo di vita delle attività e di altre stranezze. Ho fatto del mio meglio per disaccoppiare la logica di business dalla piattaforma, ma c'è sicuramente spazio per miglioramenti. È possibile trovare gli esempi in:

http://github.com/olerass/presenter-first-android

Forse è possibile utilizzare alcune idee da lì? O ancora meglio contribuire con qualcuno di tuo.