To achieve this, my fellow developers, I decided to spread the word about a very powerful feature of DataBinding: DEPENDENT PROPERTIES.

“What are dependent properties?” you may ask.

About a year ago, I found this short article by George Mount which introduced a really neat feature of DataBinding * drrrrrrrrrrrrrrrrrum-roll * the Bindable properties which depend on other Bindable properties.

The cool thing about dependent properties is that any change in dependencies will automatically trigger an update to the field that declared them as dependencies. This is really powerful on screens where you have input views that rely upon the state of other views.

Let’s look at an example, so you can easily get the gist of it and see how useful this can be when implementing a reactive UI.

For the sake of simplicity I chose to have a first name and a last name as input fields, format them somehow and display the result. In the followings I’ll refer to this as the “displayName”.

This is how it looks in action:

But how can this be implemented? Fair question. I’ll show how I did it.

If you’ve gotten this far, I assume you’re familiar with the DataBinding library, so I won’t explain how to set it up, but if you’d like to dust off your knowledge here’s a guide on how to do it.

As a first step I created the layout file.

What you’ve just seen is a short version of the layout. I’ve left out the irrelevant tags to focus on what’s important right now. I declared a variable, the view model that stores and handles the data, then bound the displayName property from within the ViewModel to the TextView. Next, the firstName and lastName properties were bound using the two-way data binding syntax to the EditTexts (meaning that any changes made in the EditTexts, will show up in the ViewModel’s String properties too).

Following this, in the view model class, I declared the displayName bindable property to depend on the firstName and lastName bindable properties, by enumerating them in the @Bindable annotation as follows:

To use the notifyPropertyChanged method which signals whenever the @Bindable properties change, the ViewModel had to extend the BaseObservable class. With this, every time the firstName & lastName changes the notifyPropertyChanged is called. This updates the displayName, which on its turn updates the UI with the new value.

To wrap this up, as a final step, I tied the UserViewModel instance to the XML layout:

In the activity class I created a binding instance and set a UserViewModel to it.

Aaaaand that’s it.

Or is it? 🤔

Well, not exactly. I mean it’s nice and everything, but as you can see I filled the UserViewModel with boilerplate code in order to make this work.

Luckily, not so long ago I stumbled upon this interesting talk by Lisa Wray about using DataBinding together with Kotlin. She used Kotlin’s delegated properties feature to create a custom delegate for bindable fields, making the code more readable this way. Following her steps, this is what I ended up having:

The BindableDelegate has a receiver of R which extends BaseObservable and handles any kind a property of type T. In the constructor of the delegate it expects an initial value of the bindable property as well as its binding resource identifier. So now, when a value is set, notifyPropertyChanged will be called on the receiver class.

After rewriting the ViewModel to use the custom delegate I had something like this:

All right, now the code is clean and concise. It can’t get any better, I’m pretty sure!

What seems to be the problem?

Turns out, the data doesn’t survive configuration changes such as screen rotations or entering multi-window mode.

So that’s where Android Architecture Components: ViewModel came into play. ViewModel is designed to store and manage UI-related data in a lifecycle conscious way. Well then, let’s extend it, use it and problem solved, right? It’s not exactly that simple, the UserViewModel already extends BaseObservable, in order to use bindable properties.

Since extending multiple classes is not possible, my options were limited. I could have extended the Architecture Components provided ViewModel and copy-paste the whole code from the BaseObservable class. It’s doable, but let’s be honest, that’s an ugly solution, so I chose not to pursue it.

Fortunately, the DataBinding library provides Observable classes, more specifically an ObservableField(or it’s primitive variants) which behaves like a BaseObservable but also wraps a value. Instances of this class can be used as properties in the view model instead of the @Bindable properties. This way properties can be bound to the view and retain the data on configuration change events by extending the ViewModel class.

Mmmkay, but what about the dependent properties? How can one deliver this feature with ObservableField? In the Android Studio 3.1 update, Google silently updated the DataBinding library, and one of the changes was:

The ObservableField class can now accept other Observable objects in its constructor.

Crystal clear, right? It turns out, using this, the same dependent property behaviour can be achieved as with @Bindable properties. So I refactored the UserViewModel to use the Architecture Component ViewModel and ObservableFields as properties:

To make the code more readable, I created a top-level inline function which hides the ObservableField instantiation and overrides the get() method:

I also modified the view model creation logic in the activity:

Et voila! Problem solved! Now the data is retained on configuration change and the dependent property is working as expected.

Bonus: LiveData

Like ViewModel, LiveData is another class from the Lifecycle Architecture Component library. LiveData is a data holder which also happens to be lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, this ensures that if an activity or fragment is observing a LiveData, it will only send an update to them in an active lifecycle state.

Android Studio 3.1 brought another sweet update to the DataBinding library:

You can now use a LiveData object as an observable field in data binding expressions. The ViewDataBindingclass now includes a new setLifecycleOwner() method that you use to observe LiveData objects.

So instead of using ObservableField’s I used LiveData for binding the data to the UI. The property dependency can be achieved by using a MediatorLiveData: I created another top-level inline function only this time returning a MediatorLiveData instead of ObservableField and its dependencies were LiveData instead of Observable:

All that was left do is swapping out all ObservableField properties to LiveData in the UserViewModel:

and calling setLifecycleOwner() on the binding instance in the activity:

The end!

Hope you find this feature useful and now that you’ve seen how easy it is to integrate it into your codebase, you’ll start experimenting with it. I’d be thrilled to hear your thought on this functionality, as well as ideas about cases you see yourself using it.

You can find all the code here. Any feedback, and of course shares and claps are more than welcome.

Android Architecture Components: DataBinding - Dependent Properties was originally published in The Halcyon Mobile Collection on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of their new joiner apps is Tasks, a simple and clean productivity app that integrates well with other G suite apps. I’ve been using it since its release and I really like it.

News, formerly known as Play Newsstand is another app that has been well received at the event. Besides its new Material theme News is now powered by AI.

Both of these products have a neat, simple and intuitive design, that showcases the capabilities of the updated Material Design for Android. It’s stunning. So much so, that it got me taking these apps as design examples for a side project I started working on.

Shortly after I started implementing the UI, I stumbled upon my first issue: the BottomSheetDialog component, available through the new design library, did not look like the ones from these apps:

As you can see, both apps use a modal bottom sheet dialog to present their menu, but their top edges are rounded and the NavigationBar isn’t dimmed. If we use the BottomSheet from the MaterialComponents library this is what we get:

The screenshot from the left hand side shows the home screen with its menu closed. The one on the right illustrates how the modal bottom sheet is shown when the menu icon from the bottom app bar is tapped.

The question: how can one implement the same behaviour that’s present in the apps from the examples? My goal was to do it as simple and elegant as possible, so here’s how I did it:

EDIT: Since publishing this article the Material Components team released Shape Theming support in the Material Design Components Android library, version 1.1.0-alpha02.

If you are already using the latest version of Material Design Components library for Android, then implementing this rounded corner bottom sheet got much easier. All you have to do is to set the shapeAppearanceLargeComponent attribute in your Theme to a style which extends ShapeAppearance.MaterialComponents.LargeComponent and has the cornerFamily attribute set to rounded and the cornerSize to 16dp or your dimension of choice.

For more details about shape theming check out this documentation.

First I created a shape drawable which I’ll be using as background for the bottom sheet:

Next, I made a custom style for the BottomSheet widget and a custom theme for the BottomSheetDialogFragment:

In the BottomSheet style, I set the custom background drawable to be used as the bottom sheet’s background. After that I created a custom theme for the fragment, set the statusBarColor to transparent and the navigationBarColor to white (that’s our desired color in this case). Then I set the fragment’s window floating attribute which wraps the dialog to false.

Lastly, I extended the BottomSheetDialogFragment and set my new theme on it:

Aaaand that’s it. All that was left to do is extend the RoundedBottomSheetDialogFragment, inflate a layout of my choice in it and simply show it, like you’d do with a normal BottomSheetDialogFragment:

The result:

You can find all the code here. Let me know if you have a similar or better solution. Any feedback, and of course shares and claps are more than welcome.

Implementing Google’s refreshed modal bottom sheet was originally published in The Halcyon Mobile Collection on Medium, where people are continuing the conversation by highlighting and responding to this story.