Handling the UI State in Jetpack Compose and Using Hilt

All Android applications display the state to users, which helps inform users on what the outcome is and when. The state in an Android application is any value that changes over time, and a good example is a toast that shows a message when there is an error. In this chapter, readers will learn how to handle the UI state better with the new Jetpack library.

It is fair to say with great power comes great responsibility, and managing the state of any Composable component requires a distinct approach compared to using the older way of building Android views, or as many might call it, the imperative way. This means Jetpack’s library, Compose, is entirely different from XML layouts.

Handling the UI state in the XML View System is very straightforward. The process entails setting the properties of the views to reflect the current state – that is, showing or hiding the views accordingly. For instance, when loading...

Technical requirements

The complete source code for this chapter can be found at https://github.com/PacktPublishing/Modern-Android-13-Development-Cookbook/tree/main/chapter_three.

Implementing DI with Jetpack Hilt

In object-oriented programming, DI is vital. Some people use it, and some prefer not to use it for their own reasons. However, DI is the practice of designing objects in a manner where they receive instances of the object from other pieces of code instead of constructing them internally.

If you know of the SOLID principles, you know their primary goal is to make software design easier to maintain, read, test, and build upon. In addition, DI helps us follow some of the SOLID principles. The dependency inversion principle allows the code base to be easily expanded and extended with new functionalities and improves reusability. In Modern Android Development, DI is essential, and we will implement it in our application in this recipe.

There are different types of libraries that you can use in Android for DI, such as Koin, Dagger, and Hilt; Hilt harnesses the power of Dagger and benefits from compile-time correctness, good runtime performance, Android...

Implementing ViewModel classes and understanding the state in Compose

In Android, a ViewModel is a class responsible for consciously managing the UI-related data life cycle. There is also a lot of debate in the community about whether developers should use ViewModel in Compose or not. However, Manuel Vivo, a senior Android developer relations engineer at Google, says:

“I’d include them if their benefits apply to your app. No need to use them if you handle all configuration changes yourself and don’t use Navigation Compose. Otherwise, use ViewModels not to reinvent the wheel.”

“On the other hand, the debate as to why one should not use ViewModels is based on the argument that in pure Compose, since Compose handles configuration changes, having your Composable functions reference the ViewModel is unnecessary.”

You can also refer to this tweet by Jim Sproch: https://twitter.com/JimSproch/status/1397169679647444993.

Note

You can...

Implementing Compose in an existing XML layout-based project

Since Compose is a new UI framework, many code bases still rely heavily on XML layouts. However, many companies are opting to build new screens using Compose, and this is achievable by utilizing existing XML layouts and adding unique views using ComposeView XML tags. This recipe will look into adding a Compose view to an XML layout.

Getting ready

In this recipe, we can create a new project or opt to use an existing project that does not heavily rely on Compose. We will try to display GreetingDialog and use an XML layout to show how we can use the ComposeView tag in XML layouts. If you already have a project, you do not need to set this up; you can skip to step 4 in the preceding How to do it… section.

How to do it…

Now let us go ahead and explore how we can utilize existing XML layouts with Compose:

1. Let’s start by creating a new project or using a preexisting one; if you create a new...

Understanding and handling recomposition in Jetpack Compose

Jetpack Compose is still very new, and many companies are starting to use it. Furthermore, Google has done a great job by giving developers significant documentation to help them embrace this new UI toolkit. However, despite all the documentation, one concept needs to be clarified. And that is recomposition.

Fair enough, all new software has its ups and downs, and as many people start using it, more people start giving feedback – hence, the need for more improvement. Recomposition, in Compose, involves calling your Composable again when the input changes. Or you can think of it when the composition structure and relation change.

Unless its parameters change, we want to avoid a Composable function being re-invoked in most use cases. So, in this recipe, we look into how recomposition happens and how you can debug and solve any recomposition in your application.

How to do it…

Since our view system is...

Writing UI tests for your Compose views

It is essential to test your code when developing Android applications, especially if your applications have many users. Furthermore, when you write tests for your code, you basically verify the functions, behavior, correctness, and versatility of the Android application. The most popular UI testing tools in Android are Espresso, UI Automator, Calabash, and Detox.

In this book, however, we will use Espresso. The most notable advantages of Espresso are as follows:

• It is easy to set up
• It has highly stable test cycles
• It supports JUnit 4
• It is made purely for Android UI testing
• It is suitable for writing black-box tests
• It supports testing activities outside the application as well

Getting ready

You will need to have completed previous recipes to follow along with this one.

How to do it…

As with the other recipes in this chapter, we will use the new project we created in Chapter 1, Getting Started...

Writing tests for your ViewModels

Unlike Model-View-Controller (MVC) and Model-View-Presenter (MVP), MVVM is the favored design pattern in Modern Android Development because of its unidirectional data and dependency flow. Furthermore, it becomes more accessible to unit test, as you will see in this recipe.

Getting ready

We will use our previous recipe, Implementing ViewModel and understanding the state in Compose, to test our logic and state changes.

How to do it…

In this recipe, we will write unit tests to verify our authentication state changes since that is what we have implemented so far:

1. Start by creating a LoginViewModelTest class in the test package:

Figure 3.14 – Created unit test

2. We will use the cashapp/turbine testing library for coroutine flows to test the flow we have created. Hence, you will need to include the processing code snippet in build.gradle:

   repositories {

     mavenCentral()

   }

   dependencies...