Share
Når vi utvikler en kompleks applikasjon, kommer vi generelt overfor utfordringer som trolig ble taklet før, og som allerede har noen ganske gode løsninger. Slike løsninger kalles ofte mønstre. Vi snakker generelt om designmønstre og arkitektoniske mønstre. De forenkler utviklingen, og vi bør bruke dem når det er hensiktsmessig å bruke dem.
Denne opplæringen skal hjelpe deg å forstå betydningen av et godt designet prosjekt og hvorfor Androids standardarkitektur ikke alltid er tilstrekkelig. Vi diskuterer noen få potensielle problemer som du kan støte på når du utvikler Android-programmer, og jeg viser deg hvordan du løser disse problemene ved å forbedre appens testbarhet og pålitelighet gjennom Modellvisningsprogram (MVP) mønster.
I denne opplæringen undersøker vi:
I den første delen av denne opplæringen fokuserer vi på teorien om MVP-mønsteret. Den andre delen av denne opplæringen er mer praktisk.
Utformingen av et prosjekt burde være en bekymring fra begynnelsen. En av de første tingene vi bør vurdere er arkitekturen som vi planlegger å vedta som den vil definere hvordan ulike elementer i søknaden vår er knyttet til hverandre. Det vil også etablere noen grunnregler for å veilede oss under utviklingen.
Generelt, et rammeverk eller SDK forventer at ting skal gjøres på en bestemt måte, men det er ikke alltid det rette for et prosjekt. Noen ganger er det ingen forhåndsdefinert eller riktig måte å gjøre ting på, slik at designbeslutninger går til utvikleren. Android SDK forventer at ting skal gjøres på en bestemt måte, men det er ikke alltid tilstrekkelig eller det beste valget.
Selv om Android har en utmerket SDK, er dens arkitektoniske mønstre ganske uvanlige og kan lett komme seg under utvikling, spesielt når du bygger komplekse applikasjoner som må testes og vedlikeholdes i lang tid. Heldigvis kan vi velge mellom flere arkitektoniske løsninger for å løse dette problemet.
Dette er et vanskelig spørsmål. Noen kan si at det ikke er noen problemer med arkitekturen som tilbys av Android. Sikkert, det blir jobben gjort. Men kan vi gjøre det bedre? Jeg tror sterkt på at vi kan.
Verktøyene som tilbys av Android, med layouter, Aktiviteter og datastrukturer, ser ut til å styre oss i retning av modellvisningskontrollmønsteret (MVC). MVC er et solid, etablert mønster som tar sikte på å isolere ulike roller i et program. Dette er kjent som separasjon av bekymringer.
Denne arkitekturen skaper tre lag:
Hvert lag er ansvarlig for et aspekt av appen. Modell reagerer på forretningslogikk, Utsikt er brukergrensesnittet, og Controller medierer Utsikt tilgang til Modell.
Men hvis vi analyserer nøye Android-arkitekturen, spesielt forholdet mellom Utsikt (Aktiviteter, Fragmenter etc.) og Modell (datastrukturer), kan vi konkludere med at det ikke kan betraktes som MVC. Det er ganske forskjellig fra MVC og følger sine egne regler. Det kan sikkert komme i veien når målet ditt er å skape det beste programmet mulig.
Å være mer spesifikk, hvis vi tenker på den symbiotiske forbindelsen mellom lastere og aktiviteter eller fragmenter, kan du forstå hvorfor vi bør være oppmerksom på Android-arkitekturen. En aktivitet eller fragment er ansvarlig for å ringe Loader, hvem skal hente data og returnere den til sin overordnede. Dens eksistens er helt knyttet til sin overordnede, og det er ingen separasjon mellom View-rollen (Aktivitet / Fragment) og forretningslogikken utført av Loader.
Hvordan kan vi bruke enhetstesting, i en applikasjon der data (Loader) er så tett kombinert med View (Activity eller Fragment) hvis selve essensen av enhetstesting er å teste det minste mulige koden? Hvis du jobber i et lag og du må endre noe i andres kode, hvordan kan du finne problemet hvis prosjektet ikke holder seg til et kjent arkitektonisk mønster, og alt kan være bokstavelig talt hvor som helst?
Vi kan løse dette ved å implementere et annet arkitektonisk mønster, og heldigvis tillater Android SDK oss å velge mellom flere løsninger. Vi kan begrense våre alternativer til løsninger som passer best for Android. Model View Controller (MVC) mønster er et godt valg, men en enda bedre er det nært beslektede Model View Presenter (MVP) mønster. MVP ble utviklet ved hjelp av samme lokaler som MVC, men med et mer moderne paradigme som skaper en enda bedre separasjon av bekymringer og maksimerer applikasjonens testbarhet.
Med Android's arkitektur i tankene (eller mangelen på en), kan vi konkludere med at:
Som nevnt tidligere er adskillelse av bekymringer ikke Androidans sterkeste punkt. Heldigvis forbedrer modellvisning Presenter-mønstret dette betydelig. MVP skiller applikasjonen i tre lag:
Hver har sitt ansvar og kommunikasjon mellom disse lagene blir forvaltet av presentatøren. Presentatøren fungerer som mellommann mellom de ulike delene.
Model View Presenter-mønsteret er basert på modellvisningskontrollmønsteret. Siden de deler flere konsepter, kan det være vanskelig å skille dem fra. Presentatøren og kontrolløren har en lignende rolle. De er ansvarlige for kommunikasjonen mellom modell og visning. Når det er sagt, administrerer kontrolleren ikke modell og visning så strengt som presentatøren gjør.
I MVC-mønsteret er View-laget noe intelligent og kan hente data direkte fra modellen. I MVP-mønsteret er visningen helt passiv og data leveres alltid til visning av presentatøren. Kontrollører i MVC kan også deles mellom flere visninger. I MVP har View og Presenter et ett-til-ett-forhold, derfor er presentatøren knyttet til en visning.
Disse konseptuelle forskjellene gjør at MVP-mønsteret sikrer en bedre separasjon av bekymringer, og det øker også søknadens testbarhet betydelig ved å fremme en større separasjon av de tre kjernelagene.
Det er flere tolkninger av hvordan MVP kan implementeres på Android. Generelt er Aktiviteter og Fragmenter tildelt rollen som View og er ansvarlig for å skape presentatøren og modellen. Visningen er også ansvarlig for å opprettholde modellen og presentatøren mellom konfigurasjonsendringer, informere dem om eventuell ødeleggelse av visningen.
Andre visning av objekter, for eksempel RecyclerView, kan også betraktes som en del av View-laget i MVP. Det er en en-til-en-relasjon mellom View og Presenter og noen ganger komplekse situasjoner kan be om flere presentere.
I den neste opplæringen implementerer vi Model View Presenter-mønsteret på Android. Vi legger til for å teste konseptene vi lærte i denne opplæringen, og undersøke mønsterets kompleksiteter og hva det betyr for Android.
På slutten av denne serien kan du implementere MVP i dine egne prosjekter, lage ditt eget rammeverk eller vedta andre kjente løsninger. Jeg håper å se deg i neste opplæring.
Accentsconagua