mvp, mvvm, mvi updated

Author: maciej-nowak

_drafts/2019-08-26-mvi.md

@@ -22,9 +22,9 @@ Podobnie jak w przypadku innych wzorców architektonicznych zastosowanie `MVI` m
 ## Implementacja
 Realizacja wzorca `MVI` może przypominać tą znaną z `MVP`, różnica polega jednak na implementacji i interakcji komponentów. Na podstawie klasy `Model` będącej kontenerem danych opisujących stan, definiowane są finalne klasy stanów o wspólnym rodzicu `PartialState`. Warstwa widoku `ViewImpl` implementuje interfejs `View` dostarczając zachowania obsługi otrzymanych stanów w metodzie `render` oraz emisji intencji w odpowiedzi na akcje użytkownika. Klasa `Presenter` odpowiada za odbieranie i przetwarzanie intencji z widoku oraz delegowanie ich do logiki biznesowej. W odpowiedzi na otrzymany stan tworzy nowy niezmienny obiekt modelu w metodzie `reduce`, który trafia do widoku.
 
-![MVI diagram](/assets/img/diagrams/patterns/mvvi.svg){: .center-image }
+![MVI diagram](/assets/img/diagrams/patterns/mvi.svg){: .center-image }
 
-Poniższy listing przedstawia realizację wzorca `MVI` z pominięciem zależności `Androidowych` oraz zastosowaniem `RxJava` w celu realizacji programowania reaktywnego.
+Poniższy listing przedstawia realizację wzorca `MVI` z pominięciem zależności `Android` oraz zastosowaniem `RxJava` w celu realizacji programowania reaktywnego.
 
 {% highlight kotlin %}
 //define Model where fields values describe the states of the screen
@@ -57,14 +57,14 @@ interface View {
 class ViewImpl : View {
 
     private val presenter = Presenter(Interactor())
-	
-	public ViewImpl() {
+    
+    public ViewImpl() {
         presenter.bindIntents(this)
-		
+        
         //init views
 
         emitActionIntent() //emit action on start
-	}
+    }
 
     override fun emitActionIntent() : Observable<Boolean> {
         return Observable.just(true)

_posts/design_patterns/2018-10-29-mvp.md

@@ -180,6 +180,17 @@ public class ViewActivity extends AppCompatActivity implements View {
         presenter.initView();
     }
 
+    @Override
+    public void setLastLogin(String login) {
+        loginEdit.setText(login);
+    }
+
+    @Override
+    public void navigateToHome() {
+        //go to another activity (like home screen)
+        //instead of doing logic operations it can be delegate to Router helper class
+    }
+
     @Override
     public void showError() {
         Toast.makeText(this, "Incorrect login or password", Toast.LENGTH_LONG).show();
@@ -205,12 +216,6 @@ public class ViewActivity extends AppCompatActivity implements View {
         }
     }
 
-    @Override
-    public void navigateToHome() {
-        //go to another activity (like home screen)
-        //instead of doing logic operations it can be delegate to Router helper class
-    }
-
     private void loginAction() {
         //controller get inputs from view
         String login = loginEdit.getText().toString();
@@ -251,6 +256,21 @@ public class PresenterImpl implements Presenter, OnResult {
         interactor.getSavedLogin();
     }
 
+    @Override
+    public void onLoginSuccess() {
+        view.navigateToHome();
+    }
+    
+    @Override
+    public void onLoginFail() {
+        view.showError();
+    }
+        
+    @Override
+    public void onSavedLoginExists(String savedLogin) {
+        view.setLastLogin(savedLogin);
+    }
+
     private boolean isLoginValid(String login) {
         //check rules e.g. no special characters
         return true; //mock
@@ -277,6 +297,7 @@ public class InteractorImpl implements Interactor {
         sharedPref = context.getPreferences(Context.MODE_PRIVATE);
     }
 
+    @Override
     public void login(String login, String password) {
         //use some network library to login
         int code = Response.OK; //mock code response from network
@@ -290,6 +311,7 @@ public class InteractorImpl implements Interactor {
         }
     }
 
+    @Override
     public void getSavedLogin() {
         String savedLogin = sharedPref.getString("login", "");
         if(!savedLogin.equals(""))
@@ -307,6 +329,7 @@ interface Contract {
 
     interface View {
 
+        void setLastLogin(String login);
         void navigateToHome();
         void showError();
         void showInvalidLogin(boolean valid);

_posts/design_patterns/2018-11-05-mvvm.md

@@ -11,7 +11,7 @@ keywords: "mvvm, model, view, viewmodel, wzorzec, wzorce projektowe, wzorzec arc
 ---
 
 ## Zastosowanie
-`MVVM` (ang. `Model-View-ViewModel`) (wzorzec architektoniczny) ma za zadanie ułatwić tworzenie ekranów aplikacji poprzez zastosowanie podziału odpowiedzialności na trzy różne warstwy: `widoku` (View), `widoku modelu` (ViewModel) oraz `modelu` (Model). `Warstwa widoku` odpowiedzialna jest za prezentacje danych, stanu systemu i bieżących operacji w interfejsie graficznym, a także za inicjalizację i wiązanie `ViewModel` z elementami widoku. `Warstwa widoku modelu` zajmuje się dostarczaniem danych modelu dla warstwy widoku oraz podejmowaniem akcji na rzecz wywołanego zdarzenia z widoku. Natomiast `warstwa modelu` odpowiada za logikę biznesową, czyli przetwarzanie, przechowywanie, modyfikacje oraz dostarczanie oczekiwanych danych do widoku modelu. Dzięki zastosowaniu strategii `wiązania danych` (data binding) w warstwie widoku minimalizowana jest jego logika, kod staje się bardziej uporządkowany i otwarty na modyfikacje, a przeprowadzenie testów łatwiejsze. Idea wzorca `MVVM` opiera się przede wszystkim na obserwowaniu przez warstwę widoku (`wzorzec Obserwator`) zmieniających się danych w warstwie widoku modelu i reagowanie na zmiany poprzez mechanizm wiązania danych. Ze względu na różnorodność środowisk i technologii realizacja wzorca `MVVM` może zostać uzyskana na wiele sposobów. 
+`MVVM` (ang. `Model-View-ViewModel`) (wzorzec architektoniczny) ma za zadanie ułatwić tworzenie ekranów aplikacji poprzez zastosowanie podziału odpowiedzialności na trzy różne warstwy: widoku (`View`), widoku modelu (`ViewModel`) oraz modelu (`Model`). `Warstwa widoku` odpowiedzialna jest za prezentacje danych, stanu systemu i bieżących operacji w interfejsie graficznym, a także za inicjalizację i wiązanie `ViewModel` z elementami widoku. `Warstwa widoku modelu` zajmuje się dostarczaniem danych modelu dla warstwy widoku oraz podejmowaniem akcji na rzecz wywołanego zdarzenia z widoku. Natomiast `warstwa modelu` odpowiada za logikę biznesową, czyli przetwarzanie, przechowywanie, modyfikacje oraz dostarczanie oczekiwanych danych do widoku modelu. Dzięki zastosowaniu strategii wiązania danych (`data binding`) w warstwie widoku minimalizowana jest jego logika, kod staje się bardziej uporządkowany i otwarty na modyfikacje, a przeprowadzenie testów łatwiejsze. Idea wzorca `MVVM` opiera się przede wszystkim na obserwowaniu przez warstwę widoku (`wzorzec Obserwator`) zmieniających się danych w warstwie widoku modelu i reagowanie na zmiany poprzez mechanizm wiązania danych. Ze względu na różnorodność środowisk i technologii realizacja wzorca `MVVM` może zostać uzyskana na wiele sposobów. 
 
 ## Ograniczenia
 Każdy ekran widoku posiada dedykowany widok modelu co przekłada się na większą ilość klas (w porównaniu do wzorca `MVP` nadal jest ich mniej). Ponadto warstwa widoku musi zadbać o właściwe wiązanie zmiennych i metod dla każdego wymaganego elementu widoku, a także o obserwowanie stanu widoku modelu. Ze względu na wybór dostępnych technik, bibliotek i komponentów służących realizacji wiązania danych oraz obserwowania ich stanu implementacja wzorca `MVVM` nie należy do łatwych. Co więcej mnogość strategii implementacji `MVVM` sprawia, że dane rozwiązanie może być niezrozumiałe dla innych programistów. Stworzenie poprawnego i kompletnego widoku modelu wymaga przeprowadzenia analizy warstwy widoku pod kątem wymaganych danych i możliwych stanów. Zawarty kod logiki kontrolek widoku w plikach `layout` może być nieczytelny i trudny do testowania, dlatego warto rozważyc umieszczanie pewnych fragmentów logiki w klasie widoku. 
@@ -24,7 +24,7 @@ Warstwa widoku `View` tworzy instancje widoku modelu `ViewModel` oraz wiąże go
 
 ![MVVM diagram](/assets/img/diagrams/patterns/mvvm.svg){: .center-image }
 
-Poniższy listing przedstawia realizację wzorca `MVVM` z pominięciem zależności `Androidowych` oraz implementacji wzorca `Obserwator`.
+Poniższy listing przedstawia realizację wzorca `MVVM` z pominięciem zależności `Android` oraz implementacji wzorca `Obserwator`.
 
 {% highlight java %}
 public class View {
@@ -127,7 +127,7 @@ public class Model {
 }
 {% endhighlight %}
 
-Implementacja wzorca `MVVM` może zostać zrealizowana na wiele różnych sposobów i wariantów. Warstwa widoku `View` może wykorzystywać mechanizm `data binding` w plikach `layout` lub w kodzie klasy widoku. Jest również możliwe uzyskanie implementacji wzorca bez użycia wiązania danych, a wszelkie zmiany odnotowane są poprzez śledzenie zmian w `ViewModel` z wykorzystaniem wzorca `Obserwator`. Istnieje także wiele podejść do informowania warstwy widoku o wystąpieniu błędu lub postępu operacji. Jedną ze strategii jest traktowanie takich zdarzeń jako pola w klasie widoku modelu i nasłuchiwanie przez widok zmiany stanu i podejmowaniu właściwej akcji. Komunikacja między warstwą modelu `Model`, a widoku modelu `ViewModel` może przebiegać przy wykorzystaniu natywnych rozwiązań, funkcji zwrotu (`callback`), mechanizmu `Interactor` (znanego z `MVP`), szyny zdarzeń (`event bus`), wzorca `Obserwator` czy też użycia biblioteki do programowania reaktywnego jak np. `RxJava`. Niezależnie od wyboru strategii implementacji należy przede wszystkim pamiętać, aby widok modelu nie posiadał `zależności Androidowych` oraz `referencji do Aktywności`, a warstwa widoku obserwowała stan `ViewModel`.
+Implementacja wzorca `MVVM` może zostać zrealizowana na wiele różnych sposobów i wariantów. Warstwa widoku `View` może wykorzystywać mechanizm `data binding` w plikach `layout` lub w kodzie klasy widoku. Jest również możliwe uzyskanie implementacji wzorca bez użycia wiązania danych, a wszelkie zmiany odnotowane są poprzez śledzenie zmian w `ViewModel` z wykorzystaniem wzorca `Obserwator`. Istnieje także wiele podejść do informowania warstwy widoku o wystąpieniu błędu lub postępu operacji. Jedną ze strategii jest traktowanie takich zdarzeń jako pola w klasie widoku modelu i nasłuchiwanie przez widok zmiany stanu i podejmowaniu właściwej akcji. Komunikacja między warstwą modelu `Model`, a widoku modelu `ViewModel` może przebiegać przy wykorzystaniu natywnych rozwiązań, funkcji zwrotu (`callback`), mechanizmu `Interactor` (znanego z `MVP`), szyny zdarzeń (`event bus`), wzorca `Obserwator` czy też użycia biblioteki do programowania reaktywnego jak np. `RxJava`. Niezależnie od wyboru strategii implementacji należy przede wszystkim pamiętać, aby widok modelu nie posiadał zależności `Android` oraz referencji do `Aktywności`, a warstwa widoku obserwowała stan `ViewModel`.
 
 ## Przykład
 Aplikacja Scorer ułatwia rejestrowanie i śledzenie zdarzeń z rozgrywek meczu piłkarskiego (zdobyte bramki, żółte i czerwone kartki, kontuzje itp). Obsługujący ją sędzia techniczny wybiera typ wydarzenia oraz wskazuje zawodnika. Dodane wydarzenie automatycznie pojawia się w interfejsie graficznym. Do realizacji tego zadania wykorzystano wzorzec `MVVM` w wariancie z użyciem komponentów architektury `Android`.