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

Android MVP & MVVM - GDG West Chicago October 2015

C887ad592770a197f114d0a1d3e3a5a7?s=47 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.

C887ad592770a197f114d0a1d3e3a5a7?s=128

Jorge Coca

October 07, 2015
Tweet

Transcript

  1. Modern Ways To Architect Your Android App -MVP and MVVM-

  2. Jorge Coca Senior Mobile Engineer @ SPR Consulting

  3. We're hiring!

  4. Let's get started

  5. What architectural pattern does Android adopt?

  6. None

  7. Do we really need to adopt any patterns?

  8. No, but...

  9. it is important that we, as developers, "speak" the same

    language
  10. What is an architectural pattern?

  11. 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.
  12. Tonight we'll talk about... 1.MVC 2.MVP 3.MVVM

  13. What's the best architectural pattern?

  14. There is no such thing

  15. None
  16. Which one should I choose?

  17. Understand your problem

  18. Understand the requirements

  19. Make an informed decision

  20. Follow the convention

  21. Show me the patterns!

  22. MVC

  23. Model View Controller

  24. MVC is the foundation of many different patterns

  25. 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
  26. 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...
  27. 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..." :(
  28. Benefits » Separation of concerns » Modulable » Extensible »

    "Easy to test"
  29. MVP & MVVM Model-View-Presenter Model-View-ViewModel

  30. Why do I need to learn both?

  31. 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
  32. Data Binding

  33. 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
  34. None
  35. Model View Presenter » Derivation of MVC » Mostly used

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

    It's going to be abstracted using an interface implemented by Android components » It's passive
  38. 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
  39. Benefits » Modular approach » Extensible » Test all UI

    code without framework code Not so good: attached to the View lifecycle
  40. MVVM

  41. Model View ViewModel » Commonly used by Microsoft » Binding

    engine will avoid boilerplate code
  42. 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)
  43. 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
  44. View Views will keep an instance of the ViewModel and

    will register different listeners to know when the ViewModel has changed
  45. 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.
  46. 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.
  47. <layout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto"> <data> <variable name="contact" type="net.opgenorth.hayha.droid.views.settings.firearm.ContactViewModel" /> </data> <!--

    layout is here, but omitted for clarity --> </layout>
  48. <EditText android:id="@+id/new_contact_name_text_view" android:text="@{contact.name}" android:layout_width="fill_parent" android:layout_height="wrap_content" android:layout_gravity="center_horizontal" android:contentDescription="firearm_name" android:hint="@string/firearm_name_hint" android:textSize="@dimen/default_font_size" />

  49. 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); } }
  50. 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.
  51. Establish the binding

  52. 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. }
  53. Data Binding looks awesome

  54. What's its current status?

  55. None
  56. » 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
  57. Don't use Data binding in production

  58. ...yet

  59. Rock hall of fame MVP RecyclerView with a list of

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

    Example of how data binding works and its current status
  61. Links » Github repo: https://github.com/jorgecoca/ RockHallOfFameMVP » Slides: https://speakerdeck.com/jorgecoca »

    Great example: https://github.com/ivacf/archi
  62. @jcocaramos

  63. jorgecoca

  64. We're hiring!

  65. Thank you