Skip to content

Commit

Permalink
typo
Browse files Browse the repository at this point in the history
  • Loading branch information
sockeqwe committed Jan 11, 2017
1 parent 774e042 commit e307ce3
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion _posts/2017-01-09-mosby3-mvi-1.md
Expand Up @@ -187,7 +187,7 @@ class PersonsModel {

Guess what? **Model reflects the State**. Once I have understood this, a lot of state related issues are solved (and prevented from the very beginning) and suddenly my Presenter has exactly one output: _getView().render(PersonsModel)_. This reflects a simple mathematical function like _f(x) = y_ (also possible with multiple inputs i.e. f(a,b,c), exactly one output). Math might not be everyone's cup of tea but a mathematician doesn't know what a bug is. Software Engineers do.

Understanding what a "Model" is and how to model it properly at the end solves the "State Problem"
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.
Expand Down

0 comments on commit e307ce3

Please sign in to comment.