Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Android MVP & MVVM - GDG West Chicago October 2015

Jorge Coca
October 07, 2015

Android MVP & MVVM - GDG West Chicago October 2015

This is my presentation about MVP and MVVM patterns applied to Android apps. It was shared with the GDG West Chicago group on October 7th, 2015.

Jorge Coca

October 07, 2015
Tweet

More Decks by Jorge Coca

Other Decks in Technology

Transcript

  1. Wikipedia says... An architectural pattern is a general, reusable solution

    to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design pattern but have a broader scope.
  2. MVC

  3. Model Model objects encapsulate the data specific to an application

    and define the logic and computation that manipulate and process that data. » Domain object (POJO) » Holds data, but not behaviors
  4. View A view object is an object in an application

    that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application’s model objects and to enable the editing of that data. » Decoupled from Model objects » Activities, Fragments, custom views...
  5. Controller A controller object acts as an intermediary between one

    or more of an application’s view objects and one or more of its model objects. » Communication between models and views » "Activities, Fragments, custom views..." :(
  6. During the last years, the community seemed to be inclined

    to incorporate *MVP patterns in their Android apps* ... but then, during the last Google IO
  7. What's the goal of these patterns? 1.Independent of frameworks 2.Testable

    3.Independent of UI 4.Independent of storage mechanisms 5.Independent of external dependencies
  8. Model View Presenter » Derivation of MVC » Mostly used

    for UI interfaces » Main problem that solves is testing
  9. View » Displays data » Routes commands to presenter »

    It's going to be abstracted using an interface implemented by Android components » It's passive
  10. Presenter » Acts upon the model and the view »

    Receives commands from the view and responds accordingly » Responsible for formatting data » Responsibe for presentation logic » Doesn't have Android dependencies: Unit tests :) » Attached to View lifecycle
  11. Benefits » Modular approach » Extensible » Test all UI

    code without framework code Not so good: attached to the View lifecycle
  12. ViewModel (1/2) » ViewModel implementations will contain state logic of

    the view » Activities and Fragments lifecycle tied to VM (and that's why DataBinding is so cool, we don't have to worry about this)
  13. ViewModel (2/2) » ViewModel won't contain a view instance ->

    will use event mechanisms » Decouple our views from the model by introducing the ViewModel layer » Don't tie directly to Domain models -> create a POJO for the binding
  14. View Views will keep an instance of the ViewModel and

    will register different listeners to know when the ViewModel has changed
  15. Data Binding (from Wikipedia...) Data Binding is the process that

    establishes a connection between the application UI and the Business logic. If the settings and notifications are correctly set, the data reflects changes when made. It can also mean then when the UI is changed, the underlying data will reflect that change.
  16. Data Binding (from Wikipedia...) Data Binding is the process that

    establishes a connection between the application UI and the Business logic. If the settings and notifications are correctly set, the data reflects changes when made. It can also mean then when the UI is changed, the underlying data will reflect that change.
  17. public class ContactViewModel extends BaseObservable { private String mContactName; //

    Constructors and other things omitted for clarity. @Bindable public String getName() { return mContactName; } public void setName(String name) { mContactName = name; notifyPropertyChanged(BR.name); } }
  18. BaseObservable » Provides the infrastructure fot setting up the data

    binding process » BR class is generated: Each POJO field adorned with @Bindable will have a constant declared in BR corresponding to the name.
  19. public class AddNewContactActivity extends Activity{ private ContactViewModel mViewModel; @Override protected

    void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); mViewModel = createViewModel(); initializeViewModel(); } private void ContactViewModel createViewModel() { ... } private void initializeViewModel() { ActivityAddNewContactBinding binding = DataBindingUtil.setContentView(this, R.layout.activity_add_new_contact); binding.setContact(mViewModel); } // Rest of the code omitted. }
  20. » Lots of bugs » Not even all the examples

    work » It can cause errors even in snippets where you don't use data binding » https://developer.android.com/tools/data-binding/ guide.html
  21. Rock hall of fame MVP RecyclerView with a list of

    rock bands implemented following MVP
  22. Band Details - MVVM Mix of MVP with data binding

    Example of how data binding works and its current status