Exploring Interoperability APIs

The aim of this book is to show you how to develop beautiful, fast, and maintainable Jetpack Compose apps. The previous chapters helped you get familiar with the core techniques and principles, as well as important interfaces, classes, packages, and—of course—composable functions. The remaining chapters cover topics beyond a successful adoption of Android’s new declarative user interface toolkit.

In this chapter, we are going to look at AndroidView(), AndroidViewBinding(), and ComposeView as the interoperability application programming interfaces (APIs) of Jetpack Compose. The main sections we will cover are the following:

• Showing Views in a Compose app
• Sharing data between Views and composable functions
• Embedding composables in View hierarchies

We start by looking at how to show a traditional View hierarchy in a Compose app. Imagine you have written a custom component (which, under the hood, consists of...

Technical requirements

Please refer to the Technical requirements section of Chapter 1, Building Your First Compose App, for information on how to install and set up Android Studio, as well as how to get the example apps. This chapter covers the ZxingDemo and InteropDemo example apps.

Showing Views in a Compose app

Imagine you have written a View-based custom component for one of your previous apps—for example, an image picker, a color chooser, or a camera preview—or you would like to include a third-party library such as Zebra Crossing (ZXing) to scan Quick Response (QR) codes and barcodes. To incorporate them into a Compose app, you need to add the View (or the root of a View hierarchy) to your composable functions. Let’s see how this works.

Adding custom components to a Compose app

The ZxingDemo example, shown in the following screenshot, uses the ZXing Android Embedded barcode scanner library for Android, which is based on the ZXing decoder. It is released under the terms of the Apache-2.0 License and is hosted on GitHub (https://github.com/journeyapps/zxing-android-embedded):

Figure 9.1 – The ZxingDemo example app

My example continuously scans for barcodes and QR codes. The decorated barcode view...

Sharing data between Views and composable functions

State is app data that may change over time. Recomposition occurs when state being used by a composable changes. To achieve something similar in the traditional View world, we need to store data in a way that changes to it can be observed. There are many implementations of the Observable pattern. The Android Architecture Components (and subsequent Jetpack versions) include LiveData and MutableLiveData. Both have been used frequently inside ViewModels to store state outside activities, but are increasingly often replaced by other techniques, such as StateFlow and MutableStateFlow.

Revisiting ViewModels

I introduced you to ViewModels in the Surviving configuration changes section of Chapter 5, Managing State of Your Composable Functions, and the Persisting and retrieving state section of Chapter 7, Exploring App Architecture. Before we look at how to use ViewModels to synchronize data between Views and composable functions, let...

Embedding composables in View hierarchies

As you have seen, integrating Views in composable functions is simple and straightforward using AndroidView() and AndroidViewBinding(). But what about the other way round? Often, you may not want to rewrite an existing (View-based) app from scratch but migrate it to Jetpack Compose gradually, replacing View hierarchies with composable functions step by step. Depending on the complexity of the activity, it may make sense to start with small composables that reflect portions of the UI and incorporate them into the remaining layout.

The androidx.compose.ui.platform.ComposeView view makes composables available inside classic layouts. The class extends AbstractComposeView, which has ViewGroup as its parent. Once the layout that includes it has been inflated, you can configure the ComposeView as follows:

binding.composeView.run {
  setViewCompositionStrategy(
      ViewCompositionStrategy.DisposeOnDetachedFromWindow...

Summary

In this chapter, we looked at the interoperability APIs of Jetpack Compose, which allow you to mix composable functions and traditional Views. We started by incorporating a traditional View hierarchy from a third-party library in a Compose app, using AndroidView(). As recent apps favor View Binding over the direct use of findViewById(), I also showed you how to embed layouts in a composable with View Binding and AndroidViewBinding(). Once you have embedded a View in a Compose UI, you need to share data between the two worlds. The Sharing data between Views and composable functions section explained how to achieve this with ViewModels. The final main section, Embedding composables in View hierarchies, discussed how to include a Compose UI in existing apps using ComposeView.

Chapter 10, Testing and Debugging Compose Apps, focuses on testing your Compose apps. You will learn how to use ComposeTestRule and AndroidComposeTestRule. Also, I will introduce you to the Semantics tree...

Questions

1. Why might it be desirable to mix Views and Compose hierarchies?
2. What are the similarities between AndroidView() and AndroidViewBinding()? In which aspect are they different?
3. What role do ViewModels play with regard to synchronizing between Views and Compose hierarchies?