typo

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

@@ -204,7 +204,7 @@ I'm pretty sure that there are also other solutions for View's state problem out
 So, again, having one "Model" which reflects the current "State" and exactly one method to "render" the "Model" solves this problem as easy as calling _getView().render(PersonsModel)_ (with the latest Model when reattaching the View to Presenter).
 
 ## 3. Navigation on the back stack
-Does a Presenter (or ViewModel) need to be kept when the View is not in use anymore? For instance if the Fragment (View) has been replaced with another Fragment because the user has navigated to another screen, then there is no View attached to the Presenter. If no View is attached obviously a Presenter can't update the View with the latest data from business logic. What if the user comes back (i.e. pressing the back button to pop the back stack)? Reload the data? This is more a philosophical question.
+Does a Presenter (or ViewModel) need to be kept when the View is not in use anymore? For instance if the Fragment (View) has been replaced with another Fragment because the user has navigated to another screen, then there is no View attached to the Presenter. If no View is attached obviously a Presenter can't update the View with the latest data from business logic. What if the user comes back (i.e. pressing the back button to pop the back stack)? Reload the data or reuse the existing Presenter? This is more a philosophical question.
 Usually once the user comes back to a previous screen on the backstack he would expect to continue where he left off. This is basically the "restore View's state problem" as discussed in 2. So the solution is straight forward: With a "Model" representing the state we just call _getView().render(PersonsModel)_ to render the View when coming back from back stack.
 
 ## 4. Process death