Die Flexibilität von Android ermöglicht es Ihnen, Anwendungen nach Ihrem Wohlbefinden zu gestalten. Dies gibt Entwicklern sowohl erhebliche Macht zur Erstellung großartiger Apps als auch Probleme durch unterschiedliche Ansätze. Daher ist der Bedarf an einem Architekturmuster offensichtlich. Das MVP (Model View Presenter)-Muster ist eine Ableitung des bekannten MVC (Model View Controller), das an Bedeutung in der Entwicklung von Android-Anwendungen gewinnt. Wir haben die Hauptgründe ermittelt, warum wir dieses Architekturmuster verwenden können und sollten.
Zunächst müssen wir den Unterschied zum MVC-Muster definieren und schematisch darstellen:
Die Hauptunterschiede von MVP zu MVC sind:
- Die View ist vom Model getrennt, der Presenter fungiert als Vermittler zwischen View und Model;
- Einfache Erstellung von Unit-Tests;
- Es können mehrere Presenter für komplexe Views verwendet werden.
Schauen wir uns jeden Punkt im Detail an und heben seine Hauptvorteile hervor:
Folgendes einer der Hauptkonzepte der Clean Architecture, „Teile und herrsche“, ermöglicht das MVP-Muster die Trennung der Präsentationsschicht von der Logik. In diesem Fall sind die Hauptfunktionen jedes Elements:
- Die View. Aktivität oder Fragment wird von der Datenverarbeitung befreit und zeigt nur an. Beispielsweise implementiert ein Fragment hier eine bestimmte Schnittstelle mit Funktionen:
123456public interfece ListInterface {void showError();void showItems(List<object width="300" height="150"> someItems </object>);} - Der Presenter übernimmt die gesamte Verantwortung für die Geschäftslogik. Hier werden Anfragen zum Abrufen von Daten von einem Server oder einer Datenbank (Kommunikation mit dem Modell) implementiert. Nach dem Empfang der Daten erfolgt auch die gesamte Datenverarbeitung durch den Presenter. Nach der Verarbeitung werden die Informationen über dieselbe Schnittstelle an die Ansicht übergeben:
1234//If the result is a mistakegetView.showError();//If the result is successful - we pass the datagetView.showItems(someitems);
Dieser Vorgang ist in dem unten stehenden Schema dargestellt:
- Unit-Test-Abdeckung. Der Hauptvorteil besteht darin, jede Komponente separat testen zu können. Wir können auch die Unit-Test-Technologie und den Ansatz auswählen.
- Für die View ist es praktisch, Mockito und Robolectric mit den Annotationen @Before, @Test und @After zu verwenden.
12345678910111213@Beforepublic void setUp() {TestHelper.getTestClassInjector() .inject(this);Assert.assertTrue(TestHelper.getBaseComponent().getLocalDataCache() instanceof MockLocalDataCache);Assert.assertTrue(TestHelper.getBaseComponent().getRetrofit() instanceof MockRetrofit);Assert.assertTrue(TestHelper.getBaseComponent().getOkHTTP() instanceof MockOkHTTP);}@Testpublic void testWebPage() {viewModel.loadWebPage(SOME_URL).toBlocking().forEach(s -> {Assert.assertTrue(s.contains(MockRetrofit.MOCKED_STRING)& & s.contains(SOME_URL));});} - Wir werden den Presenter auf die gleiche Weise testen, wie wir das Model getestet haben, mit einem einfachen JUnit-Test. Dieses Mal stellen wir jedoch sicher, dass der Presenter korrekt mit der View verknüpft ist, indem wir eine modifizierte View bereitstellen. Unser Presenter erhält die View und Daten vom Model, um sie in der View anzuzeigen.
123456789101112131415@Beforepublic void setUp() throws Exception {MockitoAnnotations.initMocks(this);when(interactor.getUserProfile()).thenReturn(Observable.just(newUserProfile()));presenter = new ProfilePresenter(interactor);presenter.attachView(view);}@Testpublic void testDisplayCalled() {verify(interactor).getUserProfile();verify(view).display(any());}public void fetchAndDisplay() {interactor.getUserProfile().subscribe(userProfile ->view.display(userProfile));} - Unabhängigkeit vom Lebenszyklus der Anwendung. Ein Beispiel ist, wenn wir eine Anfrage stellen und ein Benutzer die App minimiert oder die Bildschirmausrichtung ändert. Unsere Abfrage ist nicht mit der Aktivität verbunden und schlägt nicht fehl. Die Daten können abgerufen und angezeigt werden, wenn die View ihren Zustand zu inResume() ändert. Eine Null-Aktivitätsüberprüfung ist notwendig:
123456if (getActivity != null) {// working with ui…getView.showResult(result);} - Fähigkeit, einen Presenter von mehreren Views zu verwenden. Wenn wir die gleiche Logik für mehrere Bildschirme verwenden, z. B. das Empfangen und Aktualisieren einer Nachrichtenliste, können wir nur einen Presenter verwenden, der die gesamte Logik für diese beiden Views enthält. Zum Beispiel gibt es einen Presenter und zwei Fragmente zum Empfangen von Nachrichten:
- MessageUpdatePresenter;
- SentMessagesFragment implementiert MessageUpdatePresenter;
- DraftsMessagesFragment implementiert MessageUpdatePresenter.
-
In jedem Fragment implementieren wir die Schnittstelle MessageUpdatePresenter, z. B. die Methode showMessages(List
messages).
Während der Entwicklung einer Android-Anwendung für ein großes deutsches Marketingunternehmen standen wir vor der Herausforderung, die Architektur einer multifunktionalen komplexen App zu erstellen. Nach Absprache mit dem Team entschieden wir uns für die Verwendung von MVP, und es ermöglichte uns:- die Trennung der Geschäftslogik von der Präsentation, alles zu strukturieren und die Last zu verteilen;
- die Qualität des Produkts mit Hilfe einer praktischen Testabdeckung erheblich zu steigern, die viel einfacher und schneller zu schreiben ist;
- die Anzahl der Wiederholungen im Code zu verringern, da der Presenter wiederverwendet werden kann.
Über Redwerk
Redwerk ist seit 2005 im Bereich der mobilen Anwendungsentwicklung tätig. In den letzten dreizehn Jahren haben wir erfolgreich viele iOS- und Android-Apps entwickelt, die Hunderttausende von Nutzern auf der ganzen Welt gesammelt haben. Wir bieten die vollständige Entwicklung von mobilen Apps von der Idee bis zur Markteinführung und garantieren unseren Kunden hochwertige Lösungen.
