LIFECYCLE ROLE "A single abstraction on top of an Android component lifecycle (Activity, Fragment) that unifies both states and events transitions representations in a component-independent fashion"
LIFECYCLE OWNER FRAGMENT + getLifecycle( ) FRAGMENT ACTIVITY PROCESS LIFECYCLE + getCurrentState( ) + removeObserver( ) + addObserver( ) LIFECYCLE REGISTRY Dependency ๏ Colaborator Return Type ๏ Actual State ๏ Observers ๏ Parent States
Favors composition over inheritance class YourLifecycleObserver : LifecycleObserver { @OnLifecycleEvent(Lifecycle.Event.ON_START) fun onStart() { // Some action at start } @OnLifecycleEvent(Lifecycle.Event.ON_STOP) fun onStop() { // Some action at stop } } // At your Activity / Fragment lifecycle.addObserver(YourLifecycleObserver())
TYPICAL USAGES FOR OBSERVERS Auto-release for RxJava2 Disposables Auto bind/unbind presenters into/from their passive Views Auto register/unregister into/from some external framework, outside Activity/Fragment code Auto track some screen view at every screen resume ETC
VIEWMODEL ROLE "An abstraction that provides a brigde between an Android component (Activity, Fragment) and the "business logic" of the application, with a proper lifecycle scoped according the related component itself"
class YourViewModel(val repository: SomeRepository) : ViewModel() { val items by lazy { repository.retrieveFromDatabase() } fun fetchData(): List { return items } }
class YourViewModel(val repository: SomeRepository) : ViewModel() { fun fetchData(): List { return repository.retrieveFromNetwork() } } object YourViewModelFactory : ViewModelProvider.Factory { override fun create(modelClass: Class?): T { val repository = // Retrieve your repository here return YourViewModel(repository) as T } }
class YourViewModel(val repository: SomeRepository) : ViewModel() { fun fetchData(): List { return repository.retrieveFromNetwork() } } object YourViewModelFactory : ViewModelProvider.Factory { override fun create(modelClass: Class?): T { val repository = // Retrieve your repository here return YourViewModel(repository) as T } }
class YourViewModel(val repository: SomeRepository) : ViewModel() { fun fetchData(): List { return repository.retrieveFromNetwork() } } object YourViewModelFactory : ViewModelProvider.Factory { override fun create(modelClass: Class?): T { val repository = // Retrieve your repository here return YourViewModel(repository) as T } }
VIEWMODEL TL;DR A ViewModel has a dedicated lifecycle, which is provided according the scope of the related component A ViewModel scope will stand longer than the related Android component itself (if needed) : a ViewModel survives configuration changes, backed by a retained Fragment
VIEWMODEL IN PRACTICE Should not store any reference for a passive view Should store and provide data related to user interface state Plays well with a single source of truth for data retrieving / processing (eg Repository Pattern) onCleared( ) can be used to release colaborators Should not have any Android framework related code
LIVEDATA ROLE "A container that aims to provide the Observer Pattern for data, letting some observer be notified of data changes at proper lifecycle state (Started or Resumed)"
// At your Activity / Fragment val viewModel by withFactory { SomeFactory() } viewModel .fetchData() .observe(this, Observer { // Update your UI here } )
LIVEDATA TL;DR Publishes data updates to observers only at STARTED or RESUMED lifecycle states Ensures that a destroyed observer will not get any updates It not holds any data history, only the actual data state We can perform a few functional operations over LiveData via the Transformations API
EXTENDING LIVEDATA "You should derive from LiveData only when you need to adapt some external, probably async data source at your repository implementation level"
IMPLEMENTATION INTENT LiveData Stores some data in an immutable way MutableLiveData Allows some client object to modify the contents of data - setValue( ) to update from the Android main thread - postValue( ) to update from another thread MediatorLiveData An abstraction to combine two or more LiveDatas in a desired way
LIVEDATA IN PRACTICE A RxJava for dummies the masses (???) Only publishes results on Android MainThread Offers a "bridge" to RxJava2 reactive types, but it should be avoided (personal opinion) Confusing roles for MutableLiveData and LiveData (personal opinion)
ACTIVITY DEATH REASON TRIGGER USER EXPECTATION Navigation, back or up USER App on a new state Swipe-off from recents USER App on a new state Explicit finish( ) USER (call to action) App on a new state Configuration changes (rotation, locale, etc) DEVICE / USER App on the same state as before Resources reclaim, application in background ANDROID SYSTEM App on the same state as before Process death in extreme conditions, app in background ANDROID SYSTEM App on the same state as before
"Bundle, ViewModel or Local storage may serve as holder for the actual screen state, but each one of them has pros and cons to be dealt with. A comprehensive strategy may use all three ways together : the answer will be given by the application context"
STATE SAVING STRATEGY MAY HANDLE RESOURCES RECLAIMS ? HANDLE CONFIG CHANGES ? IS DATA READY FOR THE SCREEN ? AMOUNT OF DATA AVAILABLE RESISTS SYSTEM CRASHING / REBOOT DEMANDS IO ACCESS? Bundle YES YES PROBABLY YES SMALL (order of KB) NO NO ViewModel NO (Process Death) YES PROBABLY YES LARGE (order of MB) NO NO Local Storage YES YES PROBABLY NO LARGER (order of GB) YES YES
SAVING STATE MECHANISM COMPREHENSIVE USAGE Bundle Store only a small information footprint that you need to rebuild the entire screen state from the other available means, usually information generated by user interactions (inputed texts, actual page from a large list, actual list position, etc) ViewModel Store related-and-processed data for screen, acessed previously from a single source of truth (Networking, Database, etc) behind a repository Local Storage Store data as soon you get it. Data format may not be UI-related at all, and can be adapted for the UI at ViewModel or Repository level
FINAL REMARKS Choose your components wisely! Do not misuse / overabuse ViewModels Use an Observer Pattern implementation to communicate between ViewModels and Activity / Fragments ( ) ViewModels should be a very tiny layer : leverage some presentation strategy to avoid fat classes!
ubiratansoares
ivargrimstad
knr109
aridlehoover
zakky21
blueswen
ivanova1991
smt7174
gregonnet
.jpg){kind=avatar}
yumnumm
twada
chimame
chinen
vanstee
holman
cassininazir
smashingmag
addyosmani
hatefulcrawdad
chriscoyier
eileencodes
cromwellryan
geoffreycrofte
kevinliebholz