Skip to main content
ViewModel and its usage

Should we use viewmodel and what benefits it brings?

Architecture Components provides ViewModel helper class for the UI controller that is responsible for preparing data for the UI. ViewModel objects are automatically retained during configuration changes so that data they hold is immediately available to the next activity or fragment instance

  • ViewModel objects are designed to outlive specific instantiations of views or LifecycleOwners. This design also means you can write tests to cover a ViewModel more easily as it doesn't know about view and Lifecycle objects.
  • ViewModel objects are scoped to the Lifecycle passed to the ViewModelProvider when getting the ViewModel. The ViewModel remains in memory until the Lifecycle it's scoped to goes away permanently: in the case of an activity, when it finishes, while in the case of a fragment, when it's detached./li>
  • If the ViewModel class is of type AndroidViewModel, then it will create a new instance passing the Application instance as a single parameter in the constructor.

Additional ViewModel benefits

ViewModels and onSaveInstanceState() address UI data in very different ways. onSaveInstanceState() is a lifecycle callback, whereas ViewModels fundamentally change the way UI data is managed in your app. Here are a few more thoughts on the benefits of using ViewModel in addition to onSaveInstanceState():

ViewModels encourage good architectural design. Your data is separated from your UI code, which makes the code more modular and simplifies testing.

onSaveInstanceState() is designed to save a small amount of transient data, but not complex lists of objects or media data. A ViewModel can delegate the loading of complex data and also act as temporary storage once this data is loaded.

onSaveInstanceState() is called during configuration changes and when the activity goes into the background; in both of these cases you actually do not need to reload or process the data if you keep it in a ViewModel.

Comments

Post a Comment

Popular posts from this blog

How will you track foreground and background events in android? Implementing a Foreground and Background Handler First, lets create our interface that will be implemented by a custom Application class. Something as simple as this: interface LifecycleDelegate { fun onAppBackgrounded() fun onAppForegrounded() } we could use onTrimMemory and the TRIM_MEMORY_UI_HIDDEN flag to detect background events. So lets do that now. Add this into the onTrimMemory method callback body if (level == ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) { // lifecycleDelegate instance was passed in on the constructor lifecycleDelegate.onAppBackgrounded() } So now we have the background event covered lets handle the foreground event. To do this we are going to use the onActivityResumed. This method gets called every time any Activity in your app is resumed, so this could be called multiple times if you have multiple Activities. What we will do is use a flag...
Post a Comment
Read more
Have you ever used Room how to implement room db? Room is an ORM, Object Relational Mapping library. In other words, Room will map our database objects to Java objects. Room provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite. Database : This component represents data holder. The annotated class should be an abstract class that extends RoomDatabase. At runtime, you can acquire an instance of it by calling Room.databaseBuilder() or Room.inMemoryDatabaseBuilder(). DAO : DAOs are the main component of Room and are responsible for defining the methods that access the database. All queries are written in DAO only. IEntity : This component represents a database row of table. Each field of the entity is persisted in the database unless you annotate it with @Ignore . Difference between room and sqlite In case of SQLite, There is no compile tim...
Post a Comment
Read more