ViewModel: A deep dive (Mobile Optimized Minsk)

ViewModel: A deep dive (Mobile Optimized Minsk)

At Google I/O we got the Android architecture components.
One of its most interesting concepts is the new ViewModel.
How does it work? How do I plug it into my app? Can I use it without any of the other components?
Can I plug it into an existing MVVM or how would I build MVVM with Google's ViewModel?

A8b79d304b5184e5a5b0a109590f6683?s=128

Danny Preussler

July 15, 2017
Tweet

Transcript

  1. 2.
  2. 5.

    ViewModel in data binding <TextView … android:id="@+id/all_shows_item_title" android:text="@{viewModel.title}" /> <android.support.v7.widget.CardView

    … android:onClick="@{() -> viewModel.onClicked()}"> <data> <variable name="viewModel" type="com.vmn.playplex.main.allshows.SeriesViewModel"/> </data>
  3. 8.

    Is MVP dead? It’s like Java and Kotlin: •MVP will

    stay for quite some time •There is a new cooler kid in town that won’t leave Put the ViewModel behind Presenter
  4. 9.

    Is MVP dead? It’s like Java and Kotlin: •MVP will

    stay for quite some time •There is a new cooler kid in town that won’t leave Put the ViewModel behind Presenter
  5. 10.

    Is MVP dead? It’s like Java and Kotlin: •MVP will

    stay for quite some time •There is a new cooler kid in town that won’t leave Put the ViewModel behind Presenter
  6. 11.

    Is MVP dead? It’s like Java and Kotlin: •MVP will

    stay for quite some time •There is a new cooler kid in town that won’t leave Put the ViewModel behind Presenter
  7. 12.

    In architecture components •A ViewModel provides the data for a

    specific UI •The ViewModel does not know about the View! •Survives configuration change
  8. 13.

    In architecture components •A ViewModel provides the data for a

    specific UI •The ViewModel does not know about the View! •Survives configuration change
  9. 14.

    In architecture components •A ViewModel provides the data for a

    specific UI •The ViewModel does not know about the View! •Survives configuration change
  10. 21.

    How to use class MyViewModel extends ObservableViewModel { Coming soon

    Jose Alcérreca, Google https://medium.com/@dpreussler/add-the-new-viewmodel-to-your-mvvm-36bfea86b159
  11. 24.

    How to use class MyViewModelFactory implements ViewModelProvider.Factory { @Inject MyUseCase

    useCase; @Override public MyViewModel create(Class modelClass) { return new MyViewModel(useCase); } }
  12. 26.

    How to use •Always try to build your own Factory

    •Default factory uses newInstance() which is some hundred times slower than new calls (reflection) https://speakerdeck.com/dpreussler/comparing-dependency-injection- frameworks-and-internals-for-android •Don’t forward life cycle events!
  13. 27.

    How to use •Always try to build your own Factory

    •Default factory uses newInstance() which is some hundred times slower than new calls (reflection) https://speakerdeck.com/dpreussler/comparing-dependency-injection- frameworks-and-internals-for-android •Don’t forward life cycle events!
  14. 28.

    How to use •Always try to build your own Factory

    •Default factory uses newInstance() which is some hundred times slower than new calls (reflection) https://speakerdeck.com/dpreussler/comparing-dependency-injection- frameworks-and-internals-for-android •Don’t forward life cycle events!
  15. 30.

    What if… class MyViewModel extends ViewModel { @Override protected void

    onCleared() { super.onCleared(); cleanupSubscriptions(); }
  16. 32.

    How does it actually work? class HolderFragment extends Fragment {

    public HolderFragment() { setRetainInstance(true); } …
  17. 35.

    How does it actually work? @Override public void onDestroy() {

    super.onDestroy(); mViewModelStore.clear(); }
  18. 40.

    Could you write that? •What if asked for ViewModel but

    fragment transaction not done yet? •You might end up with duplicates
  19. 41.

    Could you write that? •What if asked for ViewModel but

    fragment transaction not done yet? •You might end up with duplicates
  20. 42.

    Could you write that? static class HolderFragmentManager { private Map<Activity,

    HolderFragment> mNotCommittedActivityHolders = new HashMap<>(); private Map<Fragment, HolderFragment> mNotCommittedFragmentHolders = new HashMap<>(); private ActivityLifecycleCallbacks mActivityCallbacks = new EmptyActivityLifecycleCallbacks() { @Override public void onActivityDestroyed(Activity activity) { HolderFragment fragment = mNotCommittedActivityHolders.remove(activity); …
  21. 43.

    What if Two Fragments of same Activity ask for same

    ViewModel.class via ViewModelProviders .of(this) .get(MyViewModel.class);
  22. 45.

    What if Two Fragments of same Activity ask for same

    ViewModel.class via ViewModelProviders .of(this) .get(MyViewModel.class);
  23. 46.

    result •Fragment and Activity share the same FragmentManager but: •Implementation

    uses Activity’s FragmentManager but ChildFragmentManager for Fragments
  24. 47.

    What if Two Fragments of same Activity ask for same

    ViewModel.class via ViewModelProviders .of(getActivity()) .get(MyViewModel.class);
  25. 51.

    all problems solved? ViewModels provide a convenient way to retain

    data across configuration changes but they are not persisted if the application is killed by the operating system https://developer.android.com/topic/libraries/architecture/viewmodel.html#viewm odel_vs_savedinstancestate
  26. 53.

    Why? The data saved via onSaveInstanceState is kept in the

    system process memory and the Android OS allows you to keep only a very small amount of data so it is not a good place to keep actual data for your app. TransactionTooLargeException anyone?
  27. 55.

    after The truth •Keep non-UI states in non-UI layer Not

    in bundle! •Use real caching strategies •Allows updating cache in background
  28. 56.

    after The truth •Keep non-UI states in non-UI layer Not

    in bundle! •Use real caching strategies •Allows updating cache in background
  29. 57.

    after The truth •Keep non-UI states in non-UI layer Not

    in bundle! •Use real caching strategies •Allows updating cache in background
  30. 58.
  31. 64.

    lets tweak it class MyModelFactory implements ViewModelProvider.Factory { … public

    MyModelFactory(Bundle bundle) { this.bundle = bundle; } @Override public MyViewModel create(Class modelClass) { MyViewModel viewModel = new MyViewModel(); viewModel.readFrom(bundle); return viewModel; }
  32. 66.

    lets tweak it class BundleAwareFactory<T extends BundleableViewModel> implements ViewModelProvider.Factory {

    Bundle bundle; ViewModelProvider.Factory provider; public BundleAwareViewModelFactory( @Nullable Bundle bundle, ViewModelProvider.Factory provider) { this.bundle = bundle; this.provider = provider; }
  33. 67.

    lets tweak it ... @Override public T create(final Class modelClass)

    { T viewModel = (T) provider.create(modelClass); if (bundle != null) { viewModel.readFrom(bundle); } return viewModel; }
  34. 68.

    lets tweak it public abstract class BundleableViewModel extends ViewModel {

    abstract void writeTo(Bundle bundle); abstract void readFrom(Bundle bundle); }
  35. 74.

    list item ViewModels In MVVM: •each item in RecyclerView should

    be backed by a ViewModel •ListViewModel and ItemViewModels •ItemViewModels normally don’t retrieve their own state so no need to extend Googles ViewModel
  36. 75.

    list item ViewModels In MVVM: •each item in RecyclerView should

    be backed by a ViewModel •ListViewModel and ItemViewModels •ItemViewModels normally don’t retrieve their own state so no need to extend Googles ViewModel
  37. 76.

    list item ViewModels In MVVM: •each item in RecyclerView should

    be backed by a ViewModel •ListViewModel and ItemViewModels •ItemViewModels normally don’t retrieve their own state so no need to extend Googles ViewModel
  38. 79.

    list item ViewModels •Key could be position? public <T extends

    ViewModel> T get( String key, Class<T> modelClass)
  39. 82.

    list item ViewModels “ViewModelProvider, which will create ViewModels via the

    given Factory and retain them in a ViewModelStore “
  40. 83.

    public class ViewModelStore { private final HashMap<String, ViewModel> mMap =

    new HashMap<>(); final void put(String key, ViewModel viewModel) {…} final ViewModel get(String key) { …} public final void clear() {…} }
  41. 84.

    public class ViewModelStore { private final HashMap<String, ViewModel> mMap =

    new HashMap<>(); final void put(String key, ViewModel viewModel) {…} final ViewModel get(String key) { …} public final void clear() {…} }
  42. 90.

    Can I do it differently? •Let’s assume we build transactional

    flow spreading over multiple Activities and wand to keep data in ViewModel •Can not use the retained fragment approach •Need to override how the ViewModel is stored •Need to override the ViewModelStore is stored
  43. 91.

    Viewmodelstoreowner “A responsibility of an implementation of this interface is

    to retain owned ViewModelStore during the configuration changes and call ViewModelStore#clear(), when this scope is going to be destroyed.“
  44. 94.

    ViewModelproviders public static ViewModelProvider of( Fragment fragment, Factory factory) {

    return new ViewModelProvider( ViewModelStores.of(fragment), factory); }
  45. 98.

    How to extend life? Toothpick: A scope tree based Dependency

    Injection (DI) library https://github.com/stephanenicolas/toothpick
  46. 99.

    lets do it class LongLivingViewModelStoreOwner implements ViewModelStoreOwner { @Override public

    ViewModelStore getViewModelStore() { return Toothpick.openScope(SCOPE_NAME) .getInstance(ViewModelStore.class); } public void discardViewModel() { Toothpick.closeScope(SCOPE_NAME); }
  47. 100.

    let`s sum up •Well designed API •Know the life time:

    Never have Activivity or View reference in ViewModel •Be aware of Recreation •Careful with RecyclerView •Still alpha