Book
  • Introduction
  • Welcome !!
  • Chapter 1: The mobile ecosystem
    • Fragmentation is the devil
    • There is more than one type of mobile app
    • ... more than one type of app
    • ... one type of app
    • Under pressure (ee da de da de) !!
    • Further reading!!
  • Chapter 2: Let's start with design thinking
    • A taste of design thinking
    • The five steps
    • Design for everybody
    • Accessibility in mobile apps
  • Chapter 3: Give me a context and I will give you an app
    • Users
    • Personas? Users ? What is the difference?
    • Please, help me to model the context
    • The context canvas
  • Chapter 4: Powerful models
    • Data architecture is the foundation of analytics
    • From data to information and knowledge
    • Information/Knowledge in our mobile ecosystem
    • Questions to ask yourselves when building and classifying questions
    • The visualization-data map
    • On the scene: describing how personas interact with your app
  • Chapter 5: A GUI is better than two thousand words
    • 'Good to Go:' Let's explore the Design Systems
    • Designing GUI Mocks
    • No prototype... no deal
  • Chapter 6: About mobile operating systems ... and other deamons
    • The Android OS ... son of LINUX
    • iOS son of Darwin? or is it iOS son of UNIX?
    • Kernels
  • Chapter 7: Yes, software architecture matters !!
    • Self-test time
    • About design and design constraints
    • Architects' mojo: styles and patterns
    • What you need is a tactic !!
    • Self-test time 2 (for real)
    • Further reading
  • Chapter 8: Finally... coding
    • MVC, MVVM, MV*, MV...What?
    • Programming models: the Android side
    • Hello Jetpack, my new friend... An Android Jetpack Introduction
    • Programming models: the iOS side
    • Controllers and more controllers
    • Flutter son of... simplicity
    • Programming models: Flutter?
    • Flutter: State matters... Let´s start simple
    • Flutter: State matters... Complex stuff ahead
    • Micro-optimizations
  • Chapter 9: Data pipeline
    • Generalities data pipelines
    • Data storage types
    • Types of data pipelines
  • Chapter 10: Error Retrieving Chapter 10
    • Eventual Connectivity on Mobile Apps
    • How to handle it on Android
  • Chapter 11: The jewel in the crown: Performance
    • As fast as a nail
    • Memory bloats
    • Energy leaks
    • Final thoughts
  • Chapter 12. Become a performance bugs exterminator
    • Weak or strong?
    • Micro-optimizations
    • The single thread game !!
    • Using multi-threading like a boss !!
    • Caching
    • Avoiding memory bloats
    • Further readings
Powered by GitBook
On this page
  1. Chapter 8: Finally... coding

Programming models: the Android side

PreviousMVC, MVVM, MV*, MV...What?NextHello Jetpack, my new friend... An Android Jetpack Introduction

Last updated 1 year ago

(By Mario Linares-Vásquez)


There is a clear distinction in how iOS and Android apps are programmed. In the case of iOS, mobile apps are implemented using the iOS MVC pattern and it is explicit in the programming model. In the case of Android, at the beginning there was no clear architectural pattern to follow, but with the release of the "" MVVM appears as the official guide to implement Android apps.

Android Architecture Components

The image above depicts the MVVM approach for designing and implementing apps using the Android Architecture Components:

Wait a second. MVVM requires data binding between the View and ViewModel layers. The figure does not show the binding mechanism.

MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);

model.methodThatReturnsLiveData().observe(this, users -> { // update the UI here });

: provide Android apps with a GUI. Both, activities and fragments, have a lifecycle with callback/lifecycle methods that should be carefully used to avoid bugs and performance issues. The layout and graphical components are declared in by using Android-specific XML tags.

: these are the mediators between the GUI and the model layers. ViewModels invoke the business methods in the model side based on the View events and the GUI lifecycle methods executions. ViewModels in Android apps should extend the ViewModel class from from the Android API (e.g., public class MyViewModel extends ViewModel{...}).

ViewModels MUST NOT have a reference to the view. The binding between the View and ViewModel layers is done via objects, which operate like observable data holders that automatically notifies the observer (e.g., an Activitiy) when the data in the holder changes. To this, the Activity/Fragment that wants to be notified when the data changes, registers itself as an observer of a ViewModel and has a reference to it in the Activity onCreate method. The definition of the behavior to be executed in the view, when there are changes on the live data, is done via a lambda expression:

Note that methodThatReturnsLiveData is a placeholder name for public methods you define in the ViewModel. More information about the data binding library in Android is available .

Repositories: a repository is a that encapsulates the business and data access logic. A repository is a plain helper class; it does not inherit from any Android API class. As shown in the figure, a repository encapsulates persistence and caching functions. A repository class is expected to invoke methods from a web service (via a broker), local persistence methods (via a DAO), or cache and retrieve cached data with a plain cache manager.

Activities and Fragments
layout files
ViewModels
LiveData
here
Facade
Android Jetpack