view ▪ Receives commands from the view and responds accordingly ▪ Responsible for formatting data ▪ Responsible for presentation logic ▪ Doesn’t have Android dependencies ◦ GOOD: unit tests ◦ BAD: attached to View lifecycle
Binding engine will avoid boilerplate code View Model State and operations View Model Data binding and commands Sends notification ViewModel updates the model Sends notification
will use events mechanisms ▪ Decouple our Views from the Model by introducing a ViewModel layer ▪ Don’t tie directly to Domain models; create a POJO for the binding
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.
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.
<variable name="contact" type="net.opgenorth.hayha.droid.views.settings.firearm.ContactViewModel" /> </data> <!-- layout is here, but omitted for clarity --> </layout>
<variable name="contact" type="net.opgenorth.hayha.droid.views.settings.firearm.ContactViewModel" /> </data> <!-- layout is here, but omitted for clarity --> </layout>