Theming the app could be one of the most confusing topics in Android development. It is getting harder to maintain the styles of your components and theming of your app while the project is getting bigger. If you don’t have a good design system, you might have inconsistent designs and colors in the app. Having a good understanding of styling & theming will help you create UIs consistent across the app. Also if you are thinking about migrating to Compose, a poor design system might create more complexity.

Having a good design system requires to have a proper styling & theming setup. This helps us to have consistent and reusable styles for our components. But how do we actually have a proper styling & theming setup?

Well, this question does not have only one answer but it can be divided into 5 pieces.

• Attributes
• Default style
• Style vs Theme
• Theme overlay
• TextAppearance

Attributes

Everything starts with an attribute. Without attributes, nothing in XML would have any characteristic that we can define. Attributes are named values that have their definition in attrs.xml file. An attribute can be defined for a view as well as a theme. For instance, android:layout_width attribute is a view attribute whereas colorPrimary is a theme attribute.

A view attribute is set in the view’s XML either by setting directly on the view tag or indirectly by using style(will be mentioned later). Let’s look at how we can set the background of a button to red with android:backgroundTint view attribute.

Note: In order to access the built-in attributes, android prefix is used.

Let’s say you want to change its background to white. You can do this by setting the android:backgroundTint attribute to white.

This is fine if you will only change a single button. But what about if you would like to change all the red buttons to white? It can be achieved by:

• Using a theme attribute for android:backgroundTint
• Creating and applying a style to all buttons

A theme attribute is an attribute that does not belong to any view and can be changed at the theme level.

In order to use a theme attribute for android:backgroundTint, let's first define a custom theme attribute called myButtonBackground in attrs.xml.

An attribute’s type is set with format field. The format can be given as a single type or multiple, for example with android:background format="reference|color" which accepts both references to a drawable resource (“reference”) and color (“color”).

You can now use myButtonBackground attribute to set your button's background. But before that, you need to set a value to myButtonBackground. It must be defined either in the theme or the theme overlay that’s going to be used.

Then you can use this attribute to set the background of your buttons.

If you change the attribute value, then the background of all buttons using ?attr/myButtonBackground attribute as its background will change. Alternatively, you can use ?myButtonBackground as a short hand instead of ?attr/myButtonBackground.

But setting android:backgroundTint to myButtonBackground for all buttons might be overwhelming. In order to overcome this, we will be creating a style and applying it to all buttons using a default style.

Default style

Have you ever noticed that even if you don't give any background to the button, you get a background drawable? This is because the Button component has a default style as any other view. A default style is a style that is used as a view’s base style.

Let's check the button's default style.

Button’s default style is set through R.attr.buttonStyle theme attribute. So it means that you can change the default style of all buttons in your app with this attribute.

Let’s change the default style of the button in our theme so that the background will be red.

Then whenever you create a button, you will get this.

Isn’t this more like a text with a red background? This is because MyButton style does not inherit from any styles. For this reason, all buttons will only contain the background attribute in their default style. Let’s check how the default button style looks like in AppCompat.

As you can see, these attributes are the base style for the button. Let’s give Widget.AppCompat.Button as a parent to the MyButton style and change the background attribute with backgroundTint since we only want to change the color not the drawable.

Then we get a button with a red background 🎉.

Style vs Theme

We have mentioned both style and theme but what is the difference between them? Both style and theme are set of attributes but the difference is what they apply to. Styles are meant to be applied to views and themes to an activity or entire app. Because of this reason, a style should only contain view attributes and a theme should only contain theme attributes.

You can change the style of a view in 3 ways:

• Changing the view attribute on the layout file
• Creating a new style and applying it with views style attribute on the layout file
• Specifying a default style

Let’s see how we can change the background of a button in the layout file.

Now let’s check how we can create a style and apply it to this button.

Applying a style only takes the view attributes into an account. If you try to set any theme attribute inside MyButton style, it will not work. In order to give an example, we will:

• Use colorPrimary theme attribute inside background drawable of the button
• Change the value of colorPrimary inside the MyButton style

Then even though we set the primary color as red, we get a button with a purple background.

This is because a view only knows about its own attributes; Button isn’t aware of the colorPrimary attribute so it’s ignored.

A view gets the view attributes from the layout file or the style attribute. If a view style includes a theme attribute, it will be ignored.

Then, how do we actually change the theme attributes only for a single view? Here is where theme overlay comes into play.

Theme Overlay

Theme overlay is a technique used to override theme attributes for any view or view group. Theme overlays are very useful when you update the theme of a specific part of your app.

Applying a theme overlay consists of 2 steps:

• Create a style that consists of theme attributes desired to be changed
• Apply this style on the layout file by using android:theme or programmatically by using ContextThemeWrapper

Let’s continue with the aforementioned scenario where we are changing the button background color by the colorPrimary theme attribute. First, we need to create a style for a theme overlay where we set colorPrimary.

A theme overlay does not have any parent.

Furthermore, it is better to start naming the style with ThemeOverlay since it will make it easier to distinguish from the other styles. This naming technique is used in Material Components and AppCompat too.

Let’s apply this overlay to a button in the layout file.

Bear in mind that if a theme overlay is applied to a view group, it will apply to all of its descendants too. In other words, the theme of every view group’s descendant is overlaid when a theme overlay is applied to a view group.

We can also apply a theme overlay programmatically wrapping the context of the view with ContextThemeWrapper.

ContextThemeWrapper creates a new context (wrapping the given one) with its own theme.

TextAppearance

TextAppearance is a class that contains data for only styling the TextView`s text-related attributes (For instance textColor, textSize but not view related attributes like maxLines or drawableTop etc.).

TextAppearance is set by android:textAppearance attribute on the TextView. android:textAppearance attribute works the same with style attribute. The main difference is the precedence order of them. style takes precedence over android:textAppearance meaning that style will always override the common attributes.

You might be asking why do we need it since we can give everything in style? The answer is having a way to set only text-related attributes makes it reusable for all TextViews whilst leaving the style attribute free.

For instance, let’s create a text appearance for a header.

Now, you can use this text appearance to make any TextView a header.

As you can see, the style attribute for TextView is free and can be used to customize other view attributes. You can also set android:textAppearance by creating a style.

Let’s create a single-line header style.

You can now set this style using style attribute and reuse this style for any text.

If you want to dive deep into text appearances and the precedence of styles more, I highly recommend you to read this article.

Conclusion

Attributes are a key concept in styling & theming. Use view attributes to style a view and theme attributes for the application, Activity, or view hierarchy. If you want to change the style for all instances of a given view type throughout the app, default styles are the way to go. Theme overlays are used to override the theme attributes and you can even use them for views in a given view hierarchy. Text appearances can help you to shape your TextViews text-related attributes with android:textAppearance, while leaving style attribute free.

Thanks Ataul Munim and Nick Butcher for the reviews.

References

Android styling: themes vs styles

• Refactoring Android Themes with Style: Default Styles - Ataul Munim
• Refactoring Android Themes with Style: Theme Overlays - Ataul Munim
• Visualising Theme Overlays - Ataul Munim
• What’s your text’s appearance?

Theming basics in Android was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since Jetpack Compose has joined our lives, it has been changing the way of our thinking and coding day by day. But more importantly, creating UI’s is becoming much easier compared to the old Android view system. This empowers developers to learn and adapt to the Compose environment in a much faster way (especially for animations 🥳).

After I started playing with Compose, I have built the following Compose Galaxy. In this post, I will share my learnings about animations in Jetpack Compose while building the Compose Galaxy.

JavaScript is not available.

There is so much fun with #JetpackCompose animation apis. Everything is random is this screen 😎 Even the number of sides of the shining stars 🌟 pic.twitter.com/JdiZuxQKHj

Disclaimer: Compose version used in this post is 1.0.0-beta02 and there might be API changes in the future.

You can access the Compose Galaxy source code from here.

Draw into Canvas

First things first. We need to draw something to the screen in order to animate. Canvas composable can be used to draw any custom shape that can be represented in the coordinate system. In order to create a canvas, just use Canvas(modifier: Modifier, onDraw: DrawScope.() -> Unit) composable function and place your drawings inside onDraw lambda. DrawScope provides stateless APIs to perform drawing into the canvas meaning that no need for maintaining the underlying canvas state.

Let’s draw a simple circle.

Then we will have a circle in the middle of the screen.

Animation

This is looking great but isn't it a bit boring? Let’s bring this little one alive. Luckily, we have very handy animation APIs in Compose. Let’s look at some of them and their use cases.

animate*AsState

animate*AsState is the simplest animation API that is used to animate a single value. You only need to give the target value and whenever the target value changes the animation will get triggered again. Compose supports some of the commonly used data types like Int, Float, Dp, Color. But you can still use it to animate any type of value using animateValueAsState. Additionally, no animate*AsState is cancellable without removing this composable function from the tree.

Let’s fade in the circle using animateAsFloat by changing its alpha on click.

Then we get:

animate*AsState is very handy if you need to animate a single value. But what if you want to animate multiple values simultaneously? Then the answer is updateTransition.

updateTransition

updateTransition creates a transition that manages running animations between given states. It gives you an opportunity to animate multiple values simultaneously. Remember that the transition created with this composable function only acceptsFiniteAnimationSpec to animate the values. It means that you can only create finite animations with this transition but not infinite ones.

Let’s use updateTransition both to fade in the circle and increase its radius simultaneously.

Here are the simultaneous animations.

Note that the animation here is behaving like a one-shot animation and not repeating itself (It seems like repeating because of the gif image but the animation itself is not repeating). You could easily make it repeatable by wrapping the animation spec with repeatable() . But still repeatable != infinite. Let’s look into how we can create infinite animations.

rememberInfiniteTransition

rememberInfiniteTransition creates a transition that runs infinite animations. Note that this is also a composable function and cannot be called from a non-composable block.

Let’s add an infinite blinking animation to the circle.

Animatable

Both updateTransition and rememberInfiniteTransition works really well inside the composable blocks. The animation created with these transitions happens during composition. But what if your animation is independent of composition and the animation itself is not the only source of truth (For instance touch events such as animating a circle to the point where the click happens) This is where Animatable comes into play. Animatable is a float value holder which can be used to animate any float value without needing to be called from a composable block. It provides animateTo and animateDecay suspend functions that are used to start an animation.

Let’s move the circle to a random point every time the user clicks on the canvas.

Here is the result.

Avoid starting animation inside onDraw block since it might be called many times during recomposition.

TargetBasedAnimation

Even though most of the aforementioned high-level APIs will be sufficient for most of the use cases, there are some cases we need to control the animation timing manually. (For instance, pausing and continuing the same animation) TargetBasedAnimation gives you an opportunity to control the animation playtime by yourself. Both the start and target values should be specified when creating the TargetBasedAnimation .

Let’s pause and resume moving the circle on each user click.

And the result is:

DecayAnimation

DecayAnimation also gives you control over the animation playtime. Unlike TargetBasedAnimation, there is no target value for DecayAnimation. You only give an initial value and a velocity, then the target value is calculated based upon those values. You can think of DecayAnimation like an animation calculating engine which gives you the right animation value calculated from the value and the velocity for the corresponding playtime. If you do not need to control the animation time, you should be using Animatable.animateDecay instead of DecayAnimation.

It is not recommended to use DecayAnimation unless you need to control the animation timing manually.

Let’s pause and resume moving a car image using DecayAnimation on each click.

Then we have:

Conclusion

Animations have never been so easy like in Compose. If you want to animate a single value then use animate*AsState. But if you need multiple animations simultaneously, then updateAnimation is the way. You can repeat your animations by wrapping your animation spec with repeatable. If you want to repeat animations infinitely, prefer using rememberInfiniteTransition. Animatable is used when your animation is not the only source of truth. Also do not prefer using TargetBasedAnimation and DecayAnimation unless there is a need to control the animation timing manually.

Thanks Adam Bennett and Doris Liu for the reviews.

Animating the Compose Galaxy was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dagger is an advanced dependency injection library and it is not easy to understand at the first glance for most developers. Using Dagger in Android requires much more effort for framework classes since it requires some boilerplate code. Hilt helps to reduce Dagger’s complexity and boilerplates with a set of ready components, scopes, and annotations.

In this post, we will see the Hilt migration of a sample app that uses dagger-android for DI. The migration will be in the order as shown below.

• Application class
• Dagger components and modules
• Activities & Fragments
• ViewModels
• WorkManager
• Tests

You can also check out the changes from the Hilt migration pull request for the sample app used in this post.

Note: This migration relies on Hilt version 2.28-alpha.

Before starting the migration, you need to add Hilt dependencies to your grade files.

Application Class

The first thing you will do is to add@HiltAndroidApp annotation to the Application class.

It is better to keep the old dagger-android implementation in the application class since the migration will be done incrementally. It will give a chance to make a sanity check during the migration.

Dagger Components and Modules

Hilt provides ApplicationComponent which is to replace components which are annotated with@Singleton. In order to remove the AppComponent in this sample app, all modules are annotated with InstallIn(Applicationcomponent::class).

After adding the annotation to all modules, AppComponent could safely be removed.

Additionally, there is no need to provide a context since Hilt provides @ApplicationContext and @ActivityContext annotations to get different contexts. Any injected context in this sample app is annotated with @ApplicationContext.

Remember to include AndroidInjectionModule with one of your modules in order to be able to inject the activities and fragments without Hilt.

The last thing before making a sanity check is to tell Hilt how to inject AndroidInjector which is used in AndroidInjectionModule with using an entry point.

An entry point is a bridge between Hilt and the objects which cannot get its dependencies by Hilt.

Checkpoint: If you run the app, everything should be working fine. You can check this issue if you see any error similar to “Expected @HiltAndroidApp to have a value. Did you forget to apply the Gradle Plugin?”.

Activities & Fragments

Hilt provides @AndroidEntryPoint annotation which can also be used for activities and fragments. When migrating activities and fragments, all needs to be done is to add @AndroidEntryPoint annotation and remove the boilerplate code for dagger injection with HasAndroidInjector. Since this app is using DaggerAppCompatActivity and DaggerFragment, replacing them with AppCompatActivity and Fragment is sufficient.

Now, Dagger modules ActivityBuilderModule,FragmentBuilderModule and AndroidInjectionModule can be removed. Also, DaggerApplication can be replaced by Application, since there is no need for AndroidInjection. You can see these changes from this commit.

Checkpoint: Run the app and everything should be working fine.

Note: Currently, Hilt does not support Kotlin default args. You can check the issue from here.

ViewModels

In order to inject a ViewModel with Hilt, Jetpack integrations for ViewModel should be added to the project. This library provides @ViewModelInject annotation which is used for ViewModel constructor injection.

viewModels() extension could be used in an activity or a fragment to get a ViewModel injected using ViewModelInject. Use activityViewModels() extension to scope the ViewModel to an activity in a fragment.

After applying these changes to all ViewModels, ViewModelModule and ViewModelProviderFactory could be removed.

Checkpoint: Run the app and everything should be working fine.

Note 1: If the ViewModel is scoped to a navigation graph, defaultViewModelProviderFactory could be used as a factory.

Note 2: SavedStateHandle requires to be annotated with @Assisted when it is injected to a ViewModel.

WorkManager

Injecting WorkManager also requires Jetpack integrations.

@WorkerInject annotation is used to inject a worker.

In order to inject the worker factory to the graph, Jetpack integrations provideHiltWorkerFactory which could be used the setup the work manager configurations in the application class.

Note: Do not forget to remove the default WorkManager initialization in the Manifest.

Testing

The sample app uses dagger for integration tests. TestCoroutineModule is used in TestAppComponent to replace the CoroutineModule used in production. Also, CustomTestRunner is used to override the application with LiveDataWithFlowTestApplication. Let’s start migrating tests to Hilt with adding Hilt dependencies to the gradle file.

LiveDataWithFlowTestApplication could be removed since Hilt provides HiltTestApplication.

In order to remove TestAppComponent and use ApplicationComponent by Hilt, TestCoroutineModule should be installed in ApplicationComponent.

Bear in mind that there are 2 coroutine modules installed in ApplicationComponent now. Luckily, Hilt can uninstall modules too with @UninstallModules annotation.

Moreover, every test needs to be annotated with @HiltAndroidTest and HiltAndroidRule should be used in these tests.

If there is more than one rule, then HiltAndroidRule needs to be executed in the first order. You can check how to give an order to the test rules from docs.

Note: UsinglaunchFragmentInContainer is currently not possible with Hilt since it uses a hardcoded activity that does not have a Hilt annotation. You can check the workaround from here.

Checkpoint: If you run the tests, everything should be working fine.

Even though it takes some time to migrate Dagger to Hilt, it is a powerful library and makes developers' life easier by removing lots of boilerplate codes. It also simplifies the Dagger’s complexity with its handy annotations. In short, you won’t regret it after migrating to Hilt!

Thanks Manuel Vivo for reviewing this post.

References

• Dependency injection with Hilt
• Migrating your Dagger app to Hilt
• Migrating to Hilt
• Hilt and Jetpack integrations
• Dependency Injection on Android with Hilt
• Hilt — Adding components to the hierarchy
• Migrating the Google I/O app to Hilt

Hilt Migration Guide was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using LiveData & Flow in MVVM — Part III

Unit Testing LiveData & Coroutines and Flow

We have seen using LiveData & Flow and only Flow in MVVM architecture in Part I and Part II. In this post, we will see how to test LiveData & Coroutines and Flow. We will be solving a common race condition problem between LiveData and Coroutines with TestCoroutineDispatcher. After that, we will see how easy to test the Flow 😎

You can access the sample project from 👇

https://github.com/fgiris/LiveDataWithFlowSample/tree/fgiris/android_turkiye_work_around

Unit Testing LiveData & Coroutines ⚒

You might have seen your branch builds 💚 locally, but whenever you push it to remote your build gets 🔴. When you check the logs, you see that one of the tests which you have already added is failing because of LiveData not giving you the correct value. But why? Is it because of LiveData or Coroutines?

One of the common problems, when you are testing Coroutines with LiveData, is a race condition. You have to be very careful about the Dispatchers, Looper … If you do not have proper test rules for them, your mind could be blown and you can say “Let’s just comment out, and we can look at it later” (!).

To prevent this to happen, let’s start with a very simple function in the repository.

We will be testing if this function returns a success value.

We need to call the suspend function from a coroutine scope and this is why runBlocking is used here. This test function passes successfully ✅

What about ViewModel? Let’s go ahead and see how fetchWeatherForecastSuspendCase function is used in the ViewModel.

The important thing here is we are starting a new coroutine in the function we will test. We will be testing if fetchWeatherForecast function first returns Loading and then Success.

runBlocking is used since we have a suspend delay function to wait for an actual response. I know using delay is not a good solution, but this is a very basic example and we will fix it later, no worries 😊

When you run this test, you will get RunTimeException for getting the main Looper.

The reason for this from the official docs:

The android.jar file that is used to run unit tests does not contain any actual code — that is provided by the Android system image on real devices. Instead, all methods throw exceptions (by default). This is to make sure your unit tests only test your code and do not depend on any particular behaviour of the Android platform (that you have not explicitly mocked e.g. using Mockito).

It says that there is no access to the Android system image (which includes the main Looper for your application) in unit tests. To fix this, we have 2 options.

• Enabling default values for the unit tests in the gradle file. (Not recommended)
• Adding InstantTaskExecutorRule which overrides isMainThread method which will call to get the main looper. It also changes the background executor for Architecture Components, in order to execute them synchronously in the tests.

Let’s run the test again after adding the InstantTaskExecutorRule rule.

It does not let it pass again 🚷 🚯 🚳 🚱…

Now it is complaining for the main dispatcher not to be initialized. The reason for this is Dispatchers.Main requires main Looper which is not available in the unit tests. So the solution is to override Dispatchers.Main with TestCoroutineDispatcher.

Let’s write a general rule to use TestCoroutineDispatcher.

You can find the whole implementation of this rule from here. We are simply setting the main dispatcher to TestCoroutineDispatcher whenever a test is started. Let’s add this rule in our test too and run it again.

Voilà 🎉 Our test passes after all these processes.

TestCoroutineDispatcher has runBlockingTest which will immediately progress delays with a virtual clock. It can be used for faster tests instead of runBlocking.

But wait, we were using Dispatcher.Main, which is mainly suitable for UI operations, to make a network request in ViewModel. Let’s go back and replace that with Dispatchers.IO which is essentially a better option for network requests.

After changing the dispatcher with Dispatchers.IO, the test is failing again 🤦🏼. The reason is we only override the main dispatcher. However, when you start a new coroutine with other dispatchers, that coroutine will be executed in a different thread.

Can we also override the other dispatchers with a function like Dispatchers.setMain? Unfortunately not. This is why we need to inject the dispatchers.

Always inject the dispatchers for better testability.

We need to give the same test dispatcher to the ViewModel when it is created in the tests.

After that our test passes even if we use a different dispatcher.

It is time to remove the delay to wait for the api call. Since we are using runBlockingTest and all delay functions will be immediately progressed, you can choose to write a 100 seconds delay like delay(100000),which is hopefully bigger than each of your api call’s response time and test the api call after that delay. But it is a very bad solution 🤮

Fortunately, you can resume and pause the test dispatcher in order not to start a new coroutine while doing some tests. This lets us control any new coroutine which is started in the test function.

We just controlled the coroutine execution and our test passes 💪🏻.

Testing Flow 🚀

Testing Flow is much easier than testing LiveData & Coroutines. Because Flow is providing all of the data in the same coroutine context in which the Flow is collected, there is no race condition in the collector side. So, this lets us test the data sequentially without pausing or resuming anything.

Let’s use this simple function which returns a flow of data in the repository.

We will test if this function loading first and then giving a success response. We can use the collect terminal operator for starting the data collection in the test.

Since we don't have an index of data, let's use collectIndexed operator.

Alternatively, you can convert Flow to a list with toList operator and test the list 🔥

Controlling and testing the data flow becomes very easy with Flow operators.

Note: You can convert LiveData to a Flow with using asFlow extension and test the Flow instead of LiveData. The created Flow will only contain the latest value and then observe the updates from LiveData. Since fetching response & updating LiveData happens in our ViewModel initialization, it does not fit well for our test cases.

If you are testing LiveData & Coroutines, make sure to inject all dispatchers and use TestCoroutineDispatcher. Also, don't forget to make use of runBlockingTest to skip delays in your tests. If you are starting a new coroutine inside a test function, use the pause and resume functions in the test dispatcher to properly test the LiveData value. Additionally, you can prefer using asFlow extension and test Flow instead of LiveData 🤟🏻

Using LiveData & Flow in MVVM — Part III was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using LiveData & Flow in MVVM — Part II

We have seen how to use Flow in the repository layer and how to change the app theme with Flow & LiveData in Part I. In this post, we will see how to remove LiveData (even MediatorLiveData) and use only Flow in all layers. We will also dive deep into the common Flow operators like map, filter, transform, and more. In the end, we will implement a search bar example given by Sean McQuillan in “Fragmented Podcast — 187: Coroutines with Manuel Vivo & Sean McQuillan” with using Channel and Flow.

You can access the sample project from here.

Disclaimer: Some of the Flow apis used in this post are still experimental. They are subject to change in the future.

Say 👋 to LiveData

Using LiveData ensures that you will not be leaking any resources if the lifecycle owner does not exist anymore. What if I tell that you can almost* (explained later why not the same but almost) get the same benefit with using Flow?

Let’s see how we can do it.

Repository

The repository layer remains the same since we are already returning Flow.

ViewModel

Instead of converting Flow to LiveData with asLiveData, we just use Flow in ViewModel.

Before it was like this:

With only Flow, it becomes:

But, wait. map is missing 🤔 Let’s add it so that it converts Celsius to Fahrenheit when mapping.

You might want to show loading in UI, then onStart is the perfect place.

If you want to filter values, then go ahead. You have filter operator.

You can also make a transformation on data with transform operator which gives you the flexibility to emit as many as you want for a single value.

Since Flow is sequential, the total execution time of collecting a value is the sum of all operators' execution time. If you have a long-running operation in operators, you can use buffer so that the execution of all operators until buffer will be handled in a different coroutine than the coroutine in which the flow is collected. This makes the total execution faster.

What if you do not want to collect the same value multiple times? Then you can just use distinctUntilChanged operator which only sends the value when it is different than the previous one.

Let’s say you only want to cache the modified data before showing in the UI. You can make use of onEach operator to do your work for each value.

If you are doing some heavy work in all operators, you can simply change the context of the whole operators’ execution by using the flowOn operator.

What about errors? Simply use the catch operator to catch any error in the down stream flow.

What if we have another flow that is to be merged with _weatherForecast flow? (You might think this as a MediatorLiveData having multiple LiveData sources) You can use merge function to merge any number of flows.

Finally, our ViewModel looks like this:

The only thing left is to collect the flow from the fragment.

These are just some of the Flow operators. You can find the whole list of operators from here.

Note: Removing LiveData adds extra work for configuration changes. In order to retain configuration changes, you need to cache the latest value. You can check how Dropbox Store library handles caching from here.

Search bar using Channel and Flow

In this podcast, Sean McQuillan gave an example of how to create a search bar using Channel and Flow. The idea is to have a search bar with a filtered list. Whenever the user types something to the search bar, the list is filtered with the text in the search bar. This is done by saving the text value in the channel and observing changes with flow through this channel.

To demonstrate this example, let’s have a city list and a search bar. In the end, it will look like this:

We will have an EditText in the Fragment. Whenever the text is updated, we will send it to the channel which is stored in ViewModel.

When the channel gets updated with the latest value, we will filter the cities and send the list to the subscribers.

Then, just observe the changes in the fragment.

Well, we just implemented a searching and filtering mechanism with using channel and flow 👊

What’s next

In this post, we have seen how to replace LiveData with Flow in MVVM architecture. Also, we implemented a filtering mechanism with Channel & Flow.

In the next post, I will be explaining how to test LiveData & Flow. Stand by!

Using LiveData & Flow in MVVM — Part II was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using LiveData & Flow in MVVM — Part I

Lately, I have been searching for the best practices of Kotlin Flow in MVVM architecture. After I have answered this question about LiveData and Flow, I’ve decided to write this post. In this post, I will be explaining how to use Flow with LiveData in the MVVM pattern. Then we will see how to change the app theme by using Flow.

You can access the sample project from here:

fgiris/LiveDataWithFlowSample

Disclaimer: This post assumes that you are already familiar with Flow. If you are not, I suggest you check docs and this article by Roman Elizarov.

What is Flow?

Flow is a reactive stream in the coroutines library which is able to return multiple values from a suspend function [1].

Even though the use case of Flow seems very similar to LiveData, it has more advantages like:

• Asynchronous by itself with structured concurrency [2]
• Simple to transform data with operators like map, filter …
• Easy to test

How to use Flow in MVVM

If your app has MVVM architecture, you normally have a data layer (repository, data source, etc.), ViewModel and view (Fragment or Activity). You would probably be using LiveData for data transfers and transformations between these layers. But what is the main purpose of LiveData? Is it designed to make data transformation?

LiveData was never designed as a fully fledged reactive stream builder .

says Jose Alcérreca in Android Dev Summit 2019. Since LiveData is a lifecycle aware component, it is best to use it in view and ViewModel layer. But how about the data layer? I think the biggest problem of using LiveData in the repository level is all data transformation will be done on the main thread unless you start a coroutine and do the work inside. This is why you might prefer suspend functions in the data layer.

Let’s say you want to fetch weather forecast data from the network. Then it will be similar as below with suspend function in your repository.

You can call this function with viewModelScope in ViewModel.

This approach works fine with one-shot requests which are run each time when they are called [3]. But how about when fetching data streams?

Here is where Flow comes into play. If you want to fetch real-time updates from your server, you can do this with Flow without any concern of leaking resources since structured concurrency forces you to do so.

Let’s convert our repository so that it returns Flow.

Now, we are able to return multiple values from a suspend function. You can use asLiveData extension function to convert Flow to LiveData in ViewModel.

This looks pretty much the same as using LiveData since there is no data transformation. Let’s see fetching real-time updates from the repository.

When you are fetching real-time weather forecast data, all data transformation inside map function will be done asynchronously with the scope in which Flow is collected.

Note: You can achieve the same functionality for data transformation by using liveData builder if you are not using Flow in the repository.

To get back to real-time data fetch with Flow again, we can see that it is not blocking the UI by updating the text field while observing the data stream.

Then it will look like:

Changing the theme of your app with Flow 🌈

Since Flow can emit real-time updates, we can think of user input as an update and send it through Flow. In order to do that, let’s create a theme data source that has a theme channel for broadcasting updates.

As you see, there is no direct access to themeChannel from outside. themeChannel is converted to Flow before it is sent.

It is better to consume theme updates in activity level since all updates from other fragments can be safely observed.

Let’s fetch the theme updates in ViewModel:

And it can easily be observed in the activity:

The only thing left is to push the button in the fragment ⏯

Voilà! Just changed the theme with Flow 🔥

What’s next

In this post, we have seen how to use Flow for repository and LiveData for ViewModel in MVVM architecture. Also, we changed the app theme using Flow & LiveData.

In the next post, I will be explaining about using only Flow in all layers. Stay tuned!

Using LiveData & Flow in MVVM — Part I was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.