typo

_posts/2017-01-09-mosby3-mvi-1.md

@@ -190,7 +190,7 @@ Guess what? **Model reflects the State**. Once I have understood this, a lot of
 Understanding what a "Model" is and how to model it properly is important because at the end a Model can solve the "State Problem"
 
 ## 2. Screen orientation changes
-In android screen orientation changes is a challenging problem. The simplest way to deal with that is to ignore it. Just reload everything on each screen orientation change. This is a completely valid solution. Most of the time your app works offline too so that data comes from database or another local cache. Therefore that loading data is super fast after screen orientation changes. However, I personally, dislike to see a loading indicator even if it's just for a few milliseconds because in my opinion this is not a seamless user experience. So people (including myself) started to use MVP with "retaining presenter" so that a View can be detached (and destroyed) during screen orientation changes whereas the Presenter survives in memory and then the View gets reattached.
+In android screen orientation changes are a challenging problem. The simplest way to deal with that is to ignore it. Just reload everything on each screen orientation change. This is a completely valid solution. Most of the time your app works offline too so that data comes from database or another local cache. Therefore that loading data is super fast after screen orientation changes. However, I personally, dislike to see a loading indicator even if it's just for a few milliseconds because in my opinion this is not a seamless user experience. So people (including myself) started to use MVP with "retaining presenter" so that a View can be detached (and destroyed) during screen orientation changes whereas the Presenter survives in memory and then the View gets reattached.
 The same concept is possible with MVVM with RxJava but you have to keep in mind that once a View gets unsubscribed from his ViewModel the observable stream is destroyed. You could work around this with Subjects for example. In MVVM with data binding your ViewModel is directly bound to the View by the data binding engine himself. To avoid memory leaks, you have to destroy the ViewModel on screen orientation changes.
 
 But the problem with retaining Presenter (or ViewModel) is: how do we bring the View's state back to the same state as it was before the screen orientation change so that both, View and Presenter, are in the same state again? I have written a MVP library called [Mosby](https://github.com/sockeqwe/mosby) with a feature called ViewState which basically synchronizes the state of your business logic with the View. [Moxy](https://github.com/Arello-Mobile/Moxy), another MVP library, implemented a quite interesting solution by using "commands" to reproduce the View's state after a screen orientation change: