Interoperability APIs for jetpack Compose

Compose or XML?

Hello 👋 Techies,

Today we are going to talk about Interoperability APIs, and why it's important if you have a huge code base, and you want to migrate to compose but not in one night (slowly move to compose)

Interoperability in Jetpack compose:

Migrating all the projects in Compose is Fun and everyone wants to have this, but what if

in your project, the custom component is not yet ready to adopt the compose. Or Third-party lib is not yet migrated in compose. Or, You just do not want to migrate in one shot, you need some time to do this, so here is the interoperability API in Compose.

You can have various reasons, but the Interoperability APIS will help as an Interface to convert the XML into Compose and at the same time you can have compose and XML, both in your project.

How cool 🤙 it is

PC: Android developer

in your project, you can have only View, View + Compose or only Compose:

We can do the migration in some ways:

• Build New Feature with Compose
• If possible, Convert all the reusable functionality into a component
• Replace existing Features, one screen at a time

In this article, we will see the Existing Screen Migration with Compose

If we need XML and at the same time Compose Migration, we can implement the below code in XML and in Activity we can design the Compose under setContent()

XML:
 <androidx.compose.ui.platform.ComposeView
         android:id="@+id/compose_view"
         android:layout_width="match_parent"
         android:layout_height="match_parent" />



Activity:
 binding.composeView.apply {
         
            setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
            setContent {
                // In Compose world
                MaterialTheme {
                    Text("Welcome Compose!")
                }
            }
        }

The Next Topic is, Once we have done with the XML Migration now we can Remove Fragments and Navigation component

We can remove the Fragment and Activity Entirely and instead replace them with screen-level composable driven by Navigation Compose.

View Model is also Easily Accessible by composable functions, Here is the basic sample app from Code lab

The NavController is the Central API for the Navigation Component. It is stateful and keeps track of the back stack of composable that make up the screens in our app and the state of each screen.

val navController = rememberNavController()

I will not go through the overall code base, but here is the link to adopt Navigation with Compose.

Thank you so much for reading this article, I know it is small but meaningful if you confuse it with Compose and thinking about where to start.

Some of my other articles that you might be interested in:

• Best practices for integrating SDKs into the Apps
• Frequently Asked Android Experienced Interview Questions
• S.O.L.I.D Principle
• Android Design Pattern
• HR / Behavioural Interview Questions
• Multiple Ways to Reduce APK Size

Happy Coding…

Follow me on LinkedIn :)