Android activity view models

Android Architecture Components. Часть 4. ViewModel

Компонент ViewModel — предназначен для хранения и управления данными, связанными с представлением, а заодно, избавить нас от проблемы, связанной с пересозданием активити во время таких операций, как переворот экрана и т.д. Не стоит его воспринимать, как замену onSaveInstanceState, поскольку, после того как система уничтожит нашу активити, к примеру, когда мы перейдем в другое приложение, ViewModel будет также уничтожен и не сохранит свое состояние. В целом же, компонент ViewModel можно охарактеризовать как синглтон с колекцией экземпляров классов ViewModel, который гарантирует, что не будет уничтожен пока есть активный экземпляр нашей активити и освободит ресурсы после ухода с нее (все немного сложнее, но выглядит как-то так). Стоит также отметить, что мы можем привязать любое количество ViewModel к нашей Activity(Fragment).

Компонент состоит из таких классов: ViewModel, AndroidViewModel, ViewModelProvider, ViewModelProviders, ViewModelStore, ViewModelStores. Разработчик будет работать только с ViewModel, AndroidViewModel и для получения истанца с ViewModelProviders, но для лучшего понимания компонента, мы поверхностно рассмотрим все классы.

Класс ViewModel, сам по себе представляет абстрактный класс, без абстрактных методов и с одним protected методом onCleared(). Для реализации собственного ViewModel, нам всего лишь необходимо унаследовать свой класс от ViewModel с конструктором без параметров и это все. Если же нам нужно очистить ресурсы, то необходимо переопределить метод onCleared(), который будет вызван когда ViewModel долго не доступна и должна быть уничтожена. Как пример, можно вспомнить предыдущую статью про LiveData, а конкретно о методе observeForever(Observer), который требует явной отписки, и как раз в методе onCleared() уместно ее реализовать. Стоит еще добавить, что во избежания утечки памяти, не нужно ссылаться напрямую на View или Context Activity из ViewModel. В целом, ViewModel должна быть абсолютно изолированная от представления данных. В таком случае появляется вопрос: А каким же образом нам уведомить представление (Activity/Fragment) об изменениях в наших данных? В этом случае на помощь нам приходит LiveData, все изменяемые данные мы должны хранить с помощью LiveData, если же нам необходимо, к примеру, показать и скрыть ProgressBar, мы можем создать MutableLiveData и хранить логику показать\скрыть в компоненте ViewModel. В общем это будет выглядеть так:

Для получения ссылки на наш экземпляр ViewModel мы должны воспользоваться ViewModelProviders:

Класс AndroidViewModel, являет собой расширение ViewModel, с единственным отличием — в конструкторе должен быть один параметр Application. Является довольно полезным расширением в случаях, когда нам нужно использовать Location Service или другой компонент, требующий Application Context. В работе с ним единственное отличие, это то что мы наследуем наш ViewModel от ApplicationViewModel. В Activity/Fragment инициализируем его точно также, как и обычный ViewModel.

Класс ViewModelProviders, являет собой четыре метода утилиты, которые, называются of и возвращают ViewModelProvider. Адаптированные для работы с Activity и Fragment, а также, с возможностью подставить свою реализацию ViewModelProvider.Factory, по умолчанию используется DefaultFactory, которая является вложенным классом в ViewModelProviders. Пока что других реализаций приведенных в пакете android.arch нет.

Класс ViewModelProvider, собственно говоря класс, который возвращает наш инстанс ViewModel. Не будем особо углубляться здесь, в общих чертах он являет роль посредника с ViewModelStore, который, хранит и поднимает наш интанс ViewModel и возвращает его с помощью метода get, который имеет две сигнатуры get(Class) и get(String key, Class modelClass). Смысл заключается в том, что мы можем привязать несколько ViewModel к нашему Activity/Fragment даже одного типа. Метод get возвращает их по String key, который по умолчанию формируется как: «android.arch.lifecycle.ViewModelProvider.DefaultKey:» + canonicalName

Класс ViewModelStores, являет собой фабричный метод, напомню: Фабричный метод — паттерн, который определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать, по факту, позволяет классу делегировать инстанцирование подклассам. На данный момент, в пакете android.arch присутствует как один интерфейс, так и один подкласс ViewModelStore.

Класс ViewModelStore, класс в котором и находится вся магия, состоит из методов put, get и clear. Про них не стоит беспокоится, поскольку работать напрямую мы с ними не должны, а с get и put и физически не можем, так как они объявлены как default (package-private), соответственно видны только внутри пакета. Но, для общего образования, рассмотрим устройство этого класса. Сам класс хранит в себе HashMap , методы get и put, соответственно, возвращают по ключу (по тому самому, который мы формируем во ViewModelProvider) или добавляют ViewModel. Метод clear(), вызовет метод onCleared() у всех наших ViewModel которые мы добавляли.

Для примера работы с ViewModel давайте реализуем небольшое приложение, позволяющее выбрать пользователю точку на карте, установить радиус и показывающее, находится человек в этом поле или нет. А также дающее возможность указать WiFi network, если пользователь подключен к нему, будем считать что он в радиусе, вне зависимости от физических координат.

Для начала создадим две LiveData для отслеживания локации и имени WiFi сети:

Теперь перейдем к ViewModel, поскольку у нас есть условие, которое зависит от полученных данных с двух LifeData, нам идеально подойдет MediatorLiveData как холдер самого значения, но поскольку перезапускать сервисы нам невыгодно, поэтому подпишемся к MediatorLiveData без привязки к жизненному циклу с помощью observeForever. В методе onCleared() реализуем отписку от него с помощью removeObserver. В свою же очередь LiveData будет уведомлять об изменении MutableLiveData, на которую и будет подписано наше представление.

И наше представление:

В общих чертах мы подписываемся на MutableLiveData, с помощью меnода getStatus() из нашего ViewModel. А также работаем с ним для инициализации и сохранения наших данных.

Здесь также добавлено несколько проверок, таких как RuntimePermission и проверка на состояние GPS. Как можно заметить, код в Activity получился довольно обширный, в случае сложного UI, гугл рекомендует посмотреть в сторону создания презентера(но это может быть излишество).

В примере также использовались такие библиотеки как:

Источник

Android ViewModels: Under the hood

In this article, we are going to discuss the internals of ViewModel which is a part of Android Architecture Components. We will first briefly discuss the usages of ViewModel in Android and then we will go in detail about how ViewModel actually works and how it retains itself on configuration changes.

According to the documentation, the ViewModel class is designed to store and manage UI-related data in a lifecycle conscious way. The ViewModel class allows data to survive configuration changes such as screen rotations.

The ViewModel class also helps in implementing MVVM(Model-View-ViewModel) design pattern which is also the recommended Android app architecture for Android applications by Google.

Also, there are other various advantages of using ViewModel class provided by Android framework like:

• Handle configuration changes: ViewModel objects are automatically retained whenever activity is recreated due to configuration changes.
• Lifecycle Awareness: ViewModel objects are also lifecycle-aware. They are automatically cleared when the Lifecycle they are observing gets permanently destroyed.
• Data Sharing: Data can be easily shared between fragments in an activity using ViewModels .
• Kotlin-Coroutines support: ViewModel includes support for Kotlin-Coroutines. So, they can be easily integrated for any asynchronous processing.

How ViewModel work internally?

This is the sample project we are going to use for explaining how the viewmodel retains itself on configuration changes.

This is a very simple application with a single activity named MainActivity which shows a counter. The counter value is our view state kept inside the CounterViewModel using a LiveData object. The activity also shows the hashcode of the current activity instance.

On any configuration change, the current activity instance is destroyed and a new instance of the activity is created which makes the hashcode to change. But the counter value is retained as we are keeping it inside our ViewModel and the viewmodels are not destroyed if the activity is getting recreated due to configuration changes.

The first thought around how viewmodels are retained might be that they are stored somewhere at the global(application) level and that’s why they are not destroyed when the activity is recreated. But this assumption is wrong. The viewmodels are stored inside the activity (or FragmentManager in case of fragments).

So let’s discuss how this magic happens and how our viewmodel instance is retained even if the activity is recreated.

This is the code to get a viewmodel instance in an activity. As we can see, we are getting an instance of ViewModelProvider by passing two arguments, our activity instance and an instance of ViewModelFactory . Then, we are using this ViewModelProvider instance to get our CounterViewModel object.

Note: In the above example, passing ViewModelFactory is redundant as our CounterViewModel does not have a parameterized constructor. In case we do not pass ViewModelFactory, ViewModelProvider uses a default view model factory.

So the creation of viewmodel involves 2 steps:

1. Creation of ViewModelProvider
2. Getting the instance of Viewmodel from ViewModelProvider

Creation of ViewModelProvider

The constructor of ViewModelProvider takes two parameters, ViewModelStoreOwner and Factory . In our example, the activity is the ViewModelStoreOwner and we are passing our own custom factory. ViewModelStoreOwner is a simple interface with a single method named getViewModelStore()

In the constructor, we are simply getting the ViewModelStore from ViewModelStoreOwner and passing it to the other constructor where they are just assigned to the respective class members.

So now we know that our activity is the ViewModelStoreOwner and its the responsibility of our activity to provide the ViewModelStore .

Getting the ViewModel from ViewModelProvider

When we invoke get() method on our ViewModelProvider , it gets the canonical name of the view model class and creates a key by appending the canonical name to a DEFAULT_KEY.

After creating the key from the model class, it checks the ViewModelStore (which is provided by our activity) whether a viewmodel instance for the given key is already present or not. If the viewmodel is already present, it simply returns the viewmodel instance present in ViewModelStore and if it’s not present, the ViewModelProvider uses the Factory instance to create a new viewmodel object and also stores it in ViewModelStore .

Now we know that our activity is responsible for storing the ViewModel instances. But it’s still a mystery that how these ViewModel instances are retained even when the activity instance is recreated on configuration change.

How ViewModel retain itself?

As we saw earlier when we created ViewModelProvider we were passing an instance of ViewModelStoreOwner i.e., our activity instance.

Our activity implements the ViewModelStoreOwner the interface which has a single method named getViewModelStore()

Now let’s have a look at the implementation of this method.

Here we can see that getViewModelStore() returns the mViewModelStore . When our activity is recreated due to any configuration change, nc(NonConfigurationInstances) contains the previous instance of ViewModelStore . nc(NonConfigurationInstances) is null when our activity is created for the first time and a new ViewModelStore is created in this case.

NonConfigurationInstances(Activity.java) is the object which is retained by the Android system even when the activity gets recreated. It has a member named activity which is an instance of NonConfigurationInstances(ComponentActivity.java) . This instance contains ViewModelStore .

Note: ViewModels are not retained directly. Instead, ViewModelStore is retained on configuration changes which internally maintains a map of viewmodels .

Let’s deep dive more into this.

Whenever our activity is getting recreated due to any configuration change, onRetainNonConfigurationInstance() gets invoked which returns the NonConfigurationInstances(ComponentActivity.java) instance. This object is retained by the Android system so that it can be delivered to the next activity instance on recreation.

Similarly, we can also retain our own custom objects by implementing the onRetainCustomNonConfigurationInstance() .

After the recreation of our activity, NonConfigurationInstances(Activity.java) is received in the attach( ) method of the Activity class.

This is how the viewmodels are retained on configuration changes.

You can also connect with me on LinkedIn , Twitter , Facebook and Github .

Источник

ViewModels : A Simple Example

A little over two years ago, I was working on Android for Beginners; a class that takes students from zero programming to their first Android app. As part of the course, students build a very simple one screen app called Court-Counter.

Court-Counter is a very straightforward app with buttons that modify a basketball score. The finished app has a bug though; if you rotate the phone, your current score will inexplicably disappear.

What’s going on? Rotating a device is one of a few configuration changes that an app can go through during its lifetime, including keyboard availability and changing the device’s language. All of these configuration changes cause the Activity to be torn down and recreated.

This behavior allows us to do things like use a landscape orientation specific layout when the device is rotated on its’ side. Unfortunately it can be a headache for new (and sometimes not so new) engineers to wrap their head around.

At Google I/O 2017, the Android Framework team introduced a new set of Architecture Components, one of which deals with this exact rotation issue.

The ViewModel class is designed to hold and manage UI-related data in a life-cycle conscious way. This allows data to survive configuration changes such as screen rotations.

This post is the first in a series exploring the ins and outs of ViewModel. In this post I’ll:

• Explain the basic need ViewModels fulfill
• Solve the rotation issue by changing the Court-Counter code to use a ViewModel
• Take a closer look at ViewModel and UI Component association

The underlying problem

The underlying challenge is that the Android Activity lifecycle has a lot of states and a single Activity might cycle through these different states many times due to configuration changes.

As an Activity is going through all of these states, you also might have transient UI data that you need to keep in memory. I’m going to define transient UI data as data needed for the UI. Examples include data the user enters, data generated during runtime, or data loaded from a database. This data could be bitmap images, a list of objects needed for a RecyclerView or, in this case, a basketball score.

Previously, you might have used onRetainNonConfigurationInstance to save this data during a configuration change and unpack it on the other end. But wouldn’t it be swell if your data didn’t need to know or manage what lifecycle state the Activity is in? Instead of having a variable like scoreTeamA within the Activity, and therefore tied to all the whims of the Activity lifecycle, what if that data was stored somewhere else, outside of the Activity? This is the purpose of the ViewModel class.

In the diagram below, you can see the lifecycle of an Activity which undergoes a rotation and then is finally finished. The lifetime of the ViewModel is shown next to the associated Activity lifecycle. Note that ViewModels can be easily used with both Fragments and Activities, which I’ll call UI controllers. This example focuses on Activities.

The ViewModel exists from when the you first request a ViewModel (usually in the onCreate the Activity) until the Activity is finished and destroyed. onCreate may be called several times during the life of an Activity, such as when the app is rotated, but the ViewModel survives throughout.

A very simple example

There are three steps to setting up and using a ViewModel:

1. Separate out your data from your UI controller by creating a class that extends ViewModel
2. Set up communications between your ViewModel and your UI controller
3. Use your ViewModel in your UI controller

Step 1: Create a ViewModel class

Note: To create a ViewModel, you’ll first need to add the correct lifecycle dependency. See how here.

In general, you’ll make a ViewModel class for each screen in your app. This ViewModel class will hold all of the data associated with the screen and have getters and setters for the stored data. This separates the code to display the UI, which is implemented in your Activities and Fragments, from your data, which now lives in the ViewModel. So, let’s create a ViewModel class for the one screen in Court-Counter:

I’ve chosen to have the data stored as public members in my ScoreViewModel.java for brevity, but creating getters and setters to better encapsulate the data is a good idea.

Step 2: Associate the UI Controller and ViewModel

Your UI controller (aka Activity or Fragment) needs to know about your ViewModel. This is so your UI controller can display the data and update the data when UI interactions occur, such as pressing a button to increase a team’s score in Court-Counter.

ViewModels should not, though, hold a reference to Activities, Fragments, or Context s. ** Furthermore, ViewModels should not contain elements that contain references to UI controllers, such as Views, since this will create an indirect reference to a Context.

The reason you shouldn’t store these objects is that ViewModels outlive your specific UI controller instances — if you rotate an Activity three times, you have just created three different Activity instances, but you only have one ViewModel.

With that in mind, let’s create this UI controller/ViewModel association. You’ll want to create a member variable for your ViewModel in the UI Controller. Then in onCreate , you should call:

In the case of Court-Counter, this looks like:

**Note: There’s one exception to the “no contexts in ViewModels” rule. Sometimes you might need an Application context (as opposed to an Activity context) for use with things like system services. Storing an Application context in a ViewModel is okay because an Application context is tied to the Application lifecycle. This is different from an Activity context, which is tied to the Activity lifecycle. In fact, if you need an Application context, you should extend AndroidViewModel which is simply a ViewModel that includes an Application reference.

Step 3: Use the ViewModel in your UI Controller

To access or change UI data, you can now use the data in your ViewModel. Here’s an example of the new onCreate method and a method for updating the score by adding one point to team A:

Pro tip: ViewModel also works very nicely with another Architecture Component, LiveData, which I won’t be exploring deeply in this series. The added bonus here of using LiveData is that it’s observable: it can trigger UI updates when the data changes. You can learn more about LiveData here.

A closer look at ViewModelsProviders.of

The first time the ViewModelProviders.of method is called by MainActivity, it creates a new ViewModel instance. When this method is called again, which happens whenever onCreate is called, it will return the pre-existing ViewModel associated with the specific Court-Counter MainActivity. This is what preserves the data.

This works only if you pass in the correct UI controller as the first argument. While you should never store a UI controller inside of a ViewModel, the ViewModel class does keep track of the associations between ViewModel and UI controller instance behind the scenes, using the UI controller you pass in as the first argument.

This allows you to have an app that opens a lot of different instances of the same Activity or Fragment, but with different ViewModel information. Let’s imagine if we extended our Court-Counter example to have the scores for multiple basketball games. The games are presented in a list, and then clicking on a game in the list opens a screen that looks like our current MainActivity, but which I’ll call GameScoreActivity.

For every different game screen you open, if you associate the ViewModel and GameScoreActivity in onCreate , it will create a different ViewModel instance. If you rotate one of these screens, the connection to the same ViewModel is maintained.

All of this logic is done for you by calling ViewModelProviders.of( ).get( .class) . So as long as you pass in the correct instance of a UI controller, it just works.

A final thought: ViewModels are very nifty for separating out your UI controller code from the data which fills your UI. That said, they are not a cure all for data persistence and saving app state. In the next post I’ll explore the subtler interactions of the Activity lifecycle with ViewModels and how ViewModels compare to onSaveInstanceState .

Conclusion and further learning

In this post, I explored the very basics of the new ViewModel class. The key takeaways are:

• The ViewModel class is designed to hold and manage UI-related data in a life-cycle conscious way. This allows data to survive configuration changes such as screen rotations.
• ViewModels separate UI implementation from your app’s data.
• In general, if a screen in your app has transient data, you should create a separate ViewModel for that screen’s data.
• The lifecycle of a ViewModel extends from when the associated UI controller is first created, till it is completely destroyed.
• Never store a UI controller or Context directly or indirectly in a ViewModel. This includes storing a View in a ViewModel. Direct or indirect references to UI controllers defeat the purpose of separating the UI from the data and can lead to memory leaks.
• ViewModel objects will often store LiveData objects, which you can learn more about here.
• The ViewModelProviders.of method keeps track of what UI controller the ViewModel is associated with via the UI controller that is passed in as an argument.

Want more ViewModel-ly goodness? Check out:

The Architecture Components were created based upon your feedback. If you have questions or comments about ViewModel or any of the architecture components, check out our feedback page. Questions about or suggestion for this series? Leave a comment!

Источник