About

One of the more common issues developers initially face when developing on Android is how to handle orientation changes, device rotation. In Android when the users device rotates, the Activity, Fragments and any Views on screen are destroyed and recreated in order to adjust to the new configuration. The problem is that the state of the UI must be retained somehow when this happens. Android offers an elegant solution to this problem, with something ironically called the ViewModel, which comes as part of a separate library, Architecture Components.

Key concepts in this lesson that you will learn:
* Why the Activity and Views are destroyed on rotation.
* ViewModel and AndroidViewModel, what they are and how to use them to handle rotations in your app.
* The key differences between ViewModel and AndroidViewModel
* How to use within a Data Binding application, making a ViewModel that is both Observable and extends AndroidViewModel.
* Through this, you will have a deeper understanding of how Observability works with Data Binding.

Instructor

Links

Comments

Hi,

I've noticed that removeOnPropertyChangedCallback in ObservableViewModel never get called. Do we possibly have memory leak here?

Also, when I changed line: mCallbacks.notifyChange(this, BR._all) to mCallbacks.notifyChange(this, BR.vm) in ObservableViewModel, I've noticed that two-way data binding doesn't work, i.e. labels don't get refreshed. What is the reason for that? I thought that when choosing BR.vm would be fine-grained update, suitable for some much bigger project.

Thanks in advance. Great course, by the way, great topic and easy to understand explanations.

Drasko Saric - 9 months ago

Hi there! Great questions! I’ll take each individually here.

removeOnPropertyChangedCallback never gets called?

This actually does get called, eventually and periodically, by the Data Binding framework to clean listeners that have been collected. It’s likely however, that your ViewModel will still have some callbacks registered when it is destroyed, and this is okay. The Data Binding framework uses weak references for the observers and it’s not required that they be unregistered before the ViewModel is destroyed. This won’t cause any memory leaks.

With that said, if you rotate the phone rapidly, several times in a row, while on the same screen. You’ll notice ObservableViewModel.addOnPropertyChangedCallBack is called several times and if you look inside the source for android.databinding.ViewDataBinding, you’ll see the observer count does rise each time.

This is where the periodic removal comes in. If you use the app long enough, rotate a few times, and have a breakpoint set on ObservableViewModel.removeOnPropertyChangedCallback. You’ll see that it is called periodically to clean up old observers and if you look up the call stack you can find more detail about where that comes from, how it’s triggered, etc.

Much of this is internal implementation details of Data Binding and not covered in the course lecture, but these are great questions to ask! Thank you!

Can I notify the View of individual property changes?

If you change the property Id from BR._all to BR.vm none of the properties change (not only the 2-way bound properties). This is because the VM object reference isn’t changing, only some of the properties contained within.

With that said, you can notify the view of an individual property change. To do that, you’d have to annotate any property that you want to notify individually with a @Bindable annotation.

The size of your app doesn’t matter too much when considering this, but if you have a View in your application that is referencing many properties and a use case where only one or two of the properties change. Then, notifying the View of individual property changes, as you suggested, can be more efficient.

However, for our app, it would actually be less efficient to notify the View of individual property changes, because we’re almost always changing at least 3 properties and on save/load, 5. If we were to notify the View of each property change individually, we would spam the View each time with 5 notifications to process instead of one with BR._all.

Eric Maxwell - 9 months ago

Would be nice to see another video showing how to replace this using LiveData (via ViewDataBinding.setLifecycleOwner).

- 8 months ago

Thank you for this feedback and for watching. This is something we might be able to include in a Data Binding or LiveData course, more focused on different ways to integrate these two concepts. In the meantime, there is a great blog post by Paulina Szklarska that walks through an example of using this approach.

Eric Maxwell - 8 months ago

Really nice. Voice is clear and they way you go about introducing concepts is super easy to follow. Loved every bit of your videos..

- 5 months ago

Thank you! I'm really happy to hear that! :-)

Eric Maxwell - 5 months ago

Very well explained! Congratulations! Just got a bit lost when u change the name of variables and classes, and don't show doing it on video, but is not a very big deal. I recommend!

Something went wrong

Lesson added to
playlist

Create new playlist

We've got you covered

At Caster.IO we provide the best hyper focused & bite-sized development training available. Our goal is to
not waste your time, but to give more of it to you. From implementing a new pattern to learning a new technology,
we've got you covered.