Android MVP & MVVM - GDG West Chicago October 2015

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Jorge Coca Senior Mobile Engineer @ SPR Consulting

Slide 3

Slide 3 text

We're hiring!

Slide 4

Slide 4 text

Let's get started

Slide 5

Slide 5 text

What architectural pattern does Android adopt?

Slide 6

Slide 6 text

None

Slide 7

Slide 7 text

Do we really need to adopt any patterns?

Slide 8

Slide 8 text

No, but...

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

What is an architectural pattern?

Slide 11

Slide 11 text

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.

Slide 12

Slide 12 text

Tonight we'll talk about... 1.MVC 2.MVP 3.MVVM

Slide 13

Slide 13 text

What's the best architectural pattern?

Slide 14

Slide 14 text

There is no such thing

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Which one should I choose?

Slide 17

Slide 17 text

Understand your problem

Slide 18

Slide 18 text

Understand the requirements

Slide 19

Slide 19 text

Make an informed decision

Slide 20

Slide 20 text

Follow the convention

Slide 21

Slide 21 text

Show me the patterns!

Slide 22

Slide 22 text

MVC

Slide 23

Slide 23 text

Model View Controller

Slide 24

Slide 24 text

MVC is the foundation of many different patterns

Slide 25

Slide 25 text

Model Model objects encapsulate the data speciﬁc to an application and deﬁne the logic and computation that manipulate and process that data. » Domain object (POJO) » Holds data, but not behaviors

Slide 26

Slide 26 text

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...

Slide 27

Slide 27 text

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..." :(

Slide 28

Slide 28 text

Beneﬁts » Separation of concerns » Modulable » Extensible » "Easy to test"

Slide 29

Slide 29 text

MVP & MVVM Model-View-Presenter Model-View-ViewModel

Slide 30

Slide 30 text

Why do I need to learn both?

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Data Binding

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Model View Presenter » Derivation of MVC » Mostly used for UI interfaces » Main problem that solves is testing

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

View » Displays data » Routes commands to presenter » It's going to be abstracted using an interface implemented by Android components » It's passive

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Beneﬁts » Modular approach » Extensible » Test all UI code without framework code Not so good: attached to the View lifecycle

Slide 40

Slide 40 text

MVVM

Slide 41

Slide 41 text

Model View ViewModel » Commonly used by Microsoft » Binding engine will avoid boilerplate code

Slide 42

Slide 42 text

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)

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

View Views will keep an instance of the ViewModel and will register different listeners to know when the ViewModel has changed

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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); } }

Slide 50

Slide 50 text

BaseObservable » Provides the infrastructure fot setting up the data binding process » BR class is generated: Each POJO ﬁeld adorned with @Bindable will have a constant declared in BR corresponding to the name.

Slide 51

Slide 51 text

Establish the binding

Slide 52

Slide 52 text

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. }

Slide 53

Slide 53 text

Data Binding looks awesome

Slide 54

Slide 54 text

What's its current status?

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

» 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

Slide 57

Slide 57 text

Don't use Data binding in production

Slide 58

Slide 58 text

...yet

Slide 59

Slide 59 text

Rock hall of fame MVP RecyclerView with a list of rock bands implemented following MVP

Slide 60

Slide 60 text

Band Details - MVVM Mix of MVP with data binding Example of how data binding works and its current status

Slide 61

Slide 61 text

Links » Github repo: https://github.com/jorgecoca/ RockHallOfFameMVP » Slides: https://speakerdeck.com/jorgecoca » Great example: https://github.com/ivacf/archi