Share
Wanneer we een complexe toepassing ontwikkelen, komen we over het algemeen uitdagingen tegen die waarschijnlijk eerder zijn aangepakt en die al behoorlijk mooie oplossingen bieden. Dergelijke oplossingen worden vaak patronen genoemd. We praten over het algemeen over ontwerppatronen en architecturale patronen. Ze vereenvoudigen de ontwikkeling en we moeten ze gebruiken wanneer het passend is om ze te gebruiken.
Deze tutorial zou je moeten helpen het belang van een goed ontworpen project te begrijpen en waarom de standaardarchitectuur van Android niet altijd voldoende is. We bespreken enkele potentiële problemen die u kunt tegenkomen bij het ontwikkelen van Android-applicaties en ik laat u zien hoe u deze problemen kunt verhelpen door de testbaarheid en betrouwbaarheid van de app te verbeteren via de Presentatie modelweergave (MVP) patroon.
In deze zelfstudie verkennen we:
In het eerste deel van deze tutorial richten we ons op de theorie van het MVP-patroon. Het tweede deel van deze tutorial is meer praktijkgericht.
Het ontwerp van een project zou vanaf het allereerste begin een punt van zorg moeten zijn. Een van de eerste dingen die we moeten overwegen, is de architectuur die we van plan zijn te gebruiken, omdat deze bepaalt hoe verschillende elementen van onze toepassing op elkaar betrekking hebben. Het zal ook enkele basisregels vaststellen om ons tijdens de ontwikkeling te begeleiden.
Over het algemeen verwacht een framework of SDK dat dingen op een bepaalde manier worden gedaan, maar dat is niet altijd de juiste keuze voor een project. Soms is er geen vooraf gedefinieerde of correcte manier om dingen te doen, waardoor ontwerpbeslissingen overgelaten worden aan de ontwikkelaar. De Android SDK verwacht dat dingen op een bepaalde manier worden gedaan, maar dat is niet altijd voldoende of de beste keuze.
Hoewel Android een uitstekende SDK biedt, zijn de architecturale patronen vrij ongebruikelijk en kunnen ze u tijdens de ontwikkeling gemakkelijk in de weg zitten, vooral bij het bouwen van complexe toepassingen die nog lange tijd moeten worden getest en onderhouden. Gelukkig kunnen we kiezen uit meerdere architecturale oplossingen om dit probleem op te lossen.
Dit is een lastige vraag. Sommigen zouden kunnen zeggen dat er geen problemen zijn met de architectuur die wordt aangeboden door Android. Zeker, het klaart de klus. Maar kunnen we beter doen? Ik ben ervan overtuigd dat we dat kunnen.
De tools die Android biedt, met lay-outs, activiteiten en datastructuren, lijken ons te sturen in de richting van het Model View Controller (MVC) -patroon. MVC is een solide, gevestigd patroon dat de verschillende rollen van een toepassing wil isoleren. Dit staat bekend als scheiding van zorgen.
Deze architectuur maakt drie lagen:
Elke laag is verantwoordelijk voor een aspect van de app. Model reageert op bedrijfslogica, Uitzicht is de gebruikersinterface, en controleur bemiddelt Uitzicht toegang tot Model.
Maar als we de architectuur van Android nauwgezet analyseren, vooral de relatie tussen Uitzicht (Activiteiten, Fragmenten, etc.) en Model (datastructuren), we kunnen concluderen dat het niet als MVC kan worden beschouwd. Het is heel anders dan MVC en volgt zijn eigen regels. Het kan je zeker in de weg zitten als het je doel is om de best mogelijke applicatie te maken.
Als we specifieker zijn, als we nadenken over de symbiotische verbinding tussen laders en activiteiten of fragmenten, kun je begrijpen waarom we de architectuur van Android aandachtig moeten volgen. Een activiteit of fragment is verantwoordelijk voor het aanroepen van de Loader, die gegevens moet ophalen en naar het bovenliggende item moet retourneren. Het bestaan is volledig gekoppeld aan het bovenliggende element en er is geen scheiding tussen de weergavefunctie (activiteit / fragment) en bedrijfslogica die door de lader wordt uitgevoerd.
Hoe kunnen we eenheidstests gebruiken in een toepassing waarin data (Loader) zo nauw is gekoppeld aan de weergave (activiteit of fragment) als het testen van het kleinst mogelijke stuk code de essentie van unit testing is? Als u in een team werkt en iets in de code van iemand anders moet wijzigen, hoe kunt u het probleem dan vinden als het project zich niet aan een bekend architecturaal patroon houdt en alles letterlijk overal kan zijn?
We kunnen dit oplossen door een ander architectuurpatroon te implementeren en gelukkig kunnen we met de Android SDK kiezen tussen meerdere oplossingen. We kunnen onze opties verfijnen tot oplossingen die het meest geschikt zijn voor Android. Het Model View Controller (MVC) -patroon is een goede keuze, maar een nog beter patroon is het nauw verwante Model View Presenter (MVP) -patroon. MVP is ontwikkeld met behulp van dezelfde locaties als MVC, maar met een moderner paradigma dat zorgt voor een nog betere scheiding van zorgen en de testbaarheid van de applicatie maximaliseert.
Met de architectuur van Android in het achterhoofd (of het gebrek daaraan) kunnen we concluderen dat:
Zoals ik eerder al zei, is het scheiden van zorgen niet het sterkste punt van Android. Gelukkig verbetert het Model View Presenter-patroon dit aanzienlijk. MVP scheidt de applicatie in drie lagen:
Elk heeft zijn verantwoordelijkheden en de communicatie tussen deze lagen wordt beheerd door de presentator. De presentator werkt als een bemiddelaar tussen de verschillende delen.
Het Model View Presenter-patroon is gebaseerd op het Model View Controller-patroon. Omdat ze verschillende concepten delen, kan het moeilijk zijn om ze te onderscheiden. De presentator en de controller hebben een vergelijkbare rol. Zij zijn verantwoordelijk voor de communicatie tussen Model en View. Dat gezegd hebbende, beheerst de controller het model en de weergave niet zo strikt als de presentator doet.
In het MVC-patroon is de View-laag enigszins intelligent en kan deze gegevens rechtstreeks uit het model ophalen. In het MVP-patroon is de weergave volledig passief en worden de gegevens altijd door Viewer in de weergave weergegeven. Controllers in MVC kunnen ook worden gedeeld tussen meerdere weergaven. In MVP hebben de weergave en de presentator een één-op-één-relatie, daarom is de presentator aan één weergave gekoppeld.
Deze conceptuele verschillen maken dat het MVP-patroon een betere scheiding van zorgen garandeert en het verhoogt ook de testbaarheid van de toepassing aanzienlijk door een grotere scheiding van de drie kernlagen te bevorderen.
Er zijn verschillende interpretaties van hoe MVP op Android kan worden geïmplementeerd. Over het algemeen krijgen Activiteiten en Fragmenten echter de rol View en zijn ze verantwoordelijk voor het maken van de Presenter en het Model. De weergave is ook verantwoordelijk voor het onderhoud tussen het model en de presentator tussen configuratiewijzigingen, en informeert hen over de uiteindelijke vernietiging van de weergave.
Andere View-objecten, zoals RecyclerView, kunnen ook worden beschouwd als onderdeel van de View-laag in MVP. Er is een één-op-één relatie tussen de weergave en de presentator en soms kunnen complexe situaties vragen om meerdere presentatoren.
In de volgende zelfstudie implementeren we het Model View Presenter-patroon op Android. We hebben de concepten die we in deze tutorial hebben geleerd getest om de complexiteiten van het patroon en wat dat voor Android betekent verder te onderzoeken.
Aan het einde van deze serie kunt u MVP implementeren in uw eigen projecten, uw eigen framework maken of andere bekende oplossingen adopteren. Ik hoop je te zien in de volgende tutorial.
Accentsconagua