Share
Quando sviluppiamo un'applicazione complessa, generalmente ci imbattiamo in sfide che sono state probabilmente affrontate prima e che hanno già alcune soluzioni piuttosto grandiose. Tali soluzioni sono spesso definite modelli. Generalmente parliamo di modelli di progettazione e modelli architettonici. Semplificano lo sviluppo e dovremmo usarli ogni volta che è opportuno utilizzarli.
Questo tutorial dovrebbe aiutarti a capire l'importanza di un progetto ben progettato e perché l'architettura standard di Android non è sempre sufficiente. Discutiamo alcuni potenziali problemi che potresti incontrare quando sviluppi applicazioni Android e ti mostro come affrontare questi problemi migliorando la testabilità e l'affidabilità dell'app attraverso il Modello Visualizza Presenter Modello (MVP).
In questo tutorial, esploriamo:
Nella prima parte di questo tutorial, ci concentriamo sulla teoria del pattern MVP. La seconda parte di questo tutorial è più pratica.
Il progetto di un progetto dovrebbe essere una preoccupazione fin dall'inizio. Una delle prime cose che dovremmo considerare è l'architettura che intendiamo adottare in quanto definirà in che modo i diversi elementi della nostra applicazione si relazionano tra loro. Stabilirà anche alcune regole di base per guidarci durante lo sviluppo.
In generale, un framework o SDK si aspetta che le cose vengano fatte in un certo modo, ma non è sempre quella giusta per un progetto. A volte, non esiste un modo predefinito o corretto di fare le cose, lasciando le decisioni di progettazione allo sviluppatore. Android SDK si aspetta che le cose vengano fatte in un certo modo, ma non è sempre sufficiente o la scelta migliore.
Sebbene Android offra un eccellente SDK, i suoi modelli architettonici sono piuttosto insoliti e possono facilmente intralciare lo sviluppo durante lo sviluppo, soprattutto quando si creano applicazioni complesse che devono essere testate e mantenute per lungo tempo. Fortunatamente, possiamo scegliere tra più soluzioni architettoniche per risolvere questo problema.
Questa è una domanda complicata. Alcuni potrebbero dire che non ci sono problemi con l'architettura offerta da Android. Certamente, ha fatto il lavoro. Ma possiamo fare di meglio? Credo fermamente che possiamo.
Gli strumenti offerti da Android, con layout, attività e strutture dati, sembrano guidarci nella direzione del pattern Model View Controller (MVC). MVC è un modello solido e consolidato che mira a isolare i diversi ruoli di un'applicazione. Questo è noto come separazione delle preoccupazioni.
Questa architettura crea tre livelli:
Ogni livello è responsabile di un aspetto dell'app. Modello risponde alla logica aziendale, vista è l'interfaccia utente e controllore media la vista accesso a Modello.
Ma se analizziamo da vicino l'architettura di Android, in particolare la relazione tra vista (Attività, Frammenti, ecc.) E Modello (strutture dati), possiamo concludere che non può essere considerato MVC. È molto diverso da MVC e segue le sue regole. Può certamente mettersi sulla tua strada quando il tuo obiettivo è creare la migliore applicazione possibile.
Essendo più specifici, se pensiamo alla connessione simbiotica tra caricatori e attività o frammenti, puoi capire perché dovremmo prestare molta attenzione all'architettura di Android. Un'attività o un frammento è responsabile della chiamata al programma di caricamento, che deve recuperare i dati e restituirli al relativo genitore. La sua esistenza è completamente legata al suo genitore e non vi è alcuna separazione tra il ruolo Visualizza (Attività / Frammento) e la logica aziendale eseguita dal Caricatore.
Come possiamo utilizzare il test delle unità, in un'applicazione in cui i dati (Loader) sono così strettamente accoppiati con View (Activity o Fragment) se l'essenza stessa del testing delle unità è di testare il più piccolo pezzo di codice possibile? Se lavori in una squadra e hai bisogno di cambiare qualcosa nel codice di qualcun altro, come puoi trovare il problema se il progetto non si attacca a un modello architettonico conosciuto e qualsiasi cosa potrebbe essere letteralmente ovunque?
Possiamo risolvere questo problema implementando un diverso modello architettonico e, fortunatamente, l'SDK di Android ci consente di scegliere tra più soluzioni. Possiamo restringere le nostre opzioni alle soluzioni più adatte per Android. Il pattern Model View Controller (MVC) è una buona scelta, ma uno ancora migliore è il pattern Model View Presenter (MVP) strettamente correlato. MVP è stato sviluppato utilizzando le stesse premesse di MVC, ma con un paradigma più moderno che crea una separazione ancora migliore delle preoccupazioni e massimizza la testabilità dell'applicazione.
Con l'architettura di Android in mente (o la mancanza di uno), possiamo concludere che:
Come ho detto prima, la separazione delle preoccupazioni non è il punto più forte di Android. Fortunatamente, il modello Model View Presenter lo migliora in modo significativo. MVP separa l'applicazione in tre livelli:
Ognuno ha le sue responsabilità e la comunicazione tra questi livelli è gestita dal Presenter. Il presentatore lavora come mediatore tra le diverse parti.
Il pattern Model View Presenter si basa sul pattern Model View Controller. Dal momento che condividono diversi concetti, può essere difficile differenziarli. Il presentatore e il controller hanno un ruolo simile. Sono responsabili per la comunicazione tra modello e vista. Detto questo, il Controller non gestisce il Modello e la Vista esattamente come fa il Presentatore.
Nel pattern MVC, il livello View è alquanto intelligente e può recuperare i dati direttamente dal modello. Nel modello MVP, la vista è completamente passiva e i dati vengono sempre consegnati alla vista dal relatore. I controller in MVC possono anche essere condivisi tra più viste. In MVP, la vista e il relatore hanno una relazione uno-a-uno, pertanto, il relatore è legato a una vista.
Queste differenze concettuali fanno sì che il modello MVP garantisca una migliore separazione delle preoccupazioni e aumenti anche notevolmente la testabilità dell'applicazione promuovendo una maggiore separazione dei tre strati principali.
Esistono diverse interpretazioni su come MVP può essere implementato su Android. In generale, tuttavia, a Attività e Frammenti viene assegnato il ruolo di Visualizza e sono responsabili della creazione di Presenter e Modello. La vista è anche responsabile della manutenzione del modello e del presentatore tra le modifiche alla configurazione, informandole sull'eventuale distruzione della vista.
Altri oggetti View, come RecyclerView, possono anche essere considerati parte del livello View in MVP. Esiste una relazione uno-a-uno tra View e Presenter e, a volte, situazioni complesse possono richiedere più Presenter.
Nel prossimo tutorial implementeremo il pattern Model View Presenter su Android. Mettiamo alla prova i concetti che abbiamo imparato in questo tutorial e esploriamo ulteriormente le complessità del pattern e cosa significa per Android.
Alla fine di questa serie, è possibile implementare MVP nei propri progetti, creare il proprio framework o adottare altre soluzioni note. Spero di vederti nel prossimo tutorial.
Accentsconagua