Update README.md

Author: Daniel Novak

README.md

@@ -4,15 +4,66 @@ AndroidViewModel
 Separating data and state handling from Fragments or Activities without lots of boilerplate-code. Reducing them to simple <i>dumb views</i>.
 
 <b>Basic idea behind this library</b>.
-An instance of a Model class is assigned to your Fragment or Activity during the first creation and is kept during it's life cycle, even between display orientation changes. The Model instance is removed after the Fragment or Activity is completely gone (finished, popped from backstack, replaced without keeping it in backstack).
+An instance of a ViewModel class is assigned to your Fragment or Activity during the first creation and is kept during it's life cycle, even between display orientation changes. The ViewModel instance is removed after the Fragment or Activity is completely gone (finished, popped from backstack, replaced without keeping it in backstack).
 
-You can execute asynchronous tasks in this Model instance and this class is not destroyed during orientation change. All data handling and state logic should be placed inside this class. The Fragment or Activity is just a "dumb" view.
+You can execute asynchronous tasks in this ViewModel instance and this class is not destroyed during orientation change. All data handling and state logic should be placed inside this class. The Fragment or Activity is just a "dumb" view.
+
+![](website/static/viewmodel_architecture.png)
+
+<b>How to implement</b>:
+
+1. Create an interface for your <b>View</b> by extending [IView](library/src/main/java/eu/inloop/viewmodel/IView.java). We will call it IUserListView for this example.
+
+   ```java
+   
+  public interface IUserListView extends IView {
+      public void showUsers(List<User> users);
+  }
+   ```
+2. Create your <b>ViewModel</b> class by extending [AbstractViewModel](library/src/main/java/eu/inloop/viewmodel/AbstractViewModel.java). For example: <br/>
+
+   ```java
+   public class UserListViewModel extends AbstractViewModel<IUserListView> {
+      ....
+   }
+   ```
+3. Each <b>Fragment</b> or <b>Activity</b> that you would like to associate with a ViewModel will need either to extend [ViewModelActivityBase](library/src/main/java/eu/inloop/viewmodel/base/ViewModelBaseActivity.java)/[ViewModelActivityBase](library/src/main/java/eu/inloop/viewmodel/base/ViewModelBaseFragment.java) or copy the implementation from these classes to your base activity/fragment class (in case you can't inherit directly). Override ```getViewModelClass()``` to return the corresponding ViewModel class. For example: <br/>
+  
+  ```java
+  public class UserListFragment extends ViewModelBaseFragment<IUserListView, UserListViewModel> 
+      implements IUserListView {
+      
+     @Override
+      public Class<UserListViewModel> getViewModelClass() {
+          return UserListViewModel.class;
+      }
+      
+  }
+  ```
+  
+<b>How to use</b>:
+
+You can forward user interaction from the View into the ViewModel simply by calling:
+
+  ```java
+  getViewModel().onDeleteUserClicked(userId);
+  ```
+  
+The same goes for the opposite direction, when your asynchronous operation in the ViewModel finished and you would like to forward data to the View to show a list for example:
+
+  ```java
+  if (getView() != null) {
+    getView().showUsers(userList);
+  }
+  ```
 
 <b>How does it work?</b>
+
 A unique global ID is generated for the first time your Fragment or Activity is shown. This ID is passed on during orientation changes. Opening another instance of the same Fragment or Activity will result in a different ID. The ID is unique screen identifier. A ViewModel class is created and bound to this ID. The corresponding ViewModel instance is attached to your Fragment or Activity after an orientation change or if you return to the fragment in the back stack.
 The ViewModel is discarded once the Fragment/Activity is not reachable anymore (activity is finished or fragment permanently removed).
 
 <b>Why no controller layer?</b>
+
 This is not a strict MVC/MVP architecture - simply because we felt that having another layer between the "model" and the view does not bring enough advantages. So to further reduce the code this was simplified, where the Model is talking to the View over an interface. In mobile application most of the code is about interaction with the UI (getting data from API/DB, showing the data, manipulating, saving) so a more direct connection between the layers felt appropriate. 
 
 <b>Sample Workflow</b>:
@@ -26,6 +77,9 @@ This is not a strict MVC/MVP architecture - simply because we felt that having a
 7. ViewModel finishes the async task and tells the Fragment to show the data.
 8. User leaves the Activity, the Fragment is destroyed and the ViewModel is removed.
 
+[![](website/static/lifecycle_thumb.png)](website/static/lifecycle.png)
+
+
 Download
 --------