Coda Pizza is now fully operational, but there is one more change you can make to look toward the future. Every app you have built so far has relied on several Jetpack libraries, the most fundamental being the AppCompat library.

AppCompat back-ports many important UI behaviors to ensure consistency across versions of Android. It acts as the building block for many other Jetpack libraries, including ConstraintLayout and the Material Design Components. It also brings along many other tools you have used, including Fragments.

Despite the importance of these components in the other apps you have built, these dependencies are designed for the world of the framework UI toolkit. Compose does not depend on AppCompat; it reinvents so many APIs that AppCompat does not provide the same value as it does for apps with framework views. In fact, AppCompat arguably does not provide any value if your UI exclusively uses Compose.

But AppCompat is still present in your application, increasing its size and adding more dependencies to download when your project builds. You can reclaim these resources and part ways with the framework views entirely by removing AppCompat from your project.

But do not jump straight to your build.gradle file to delete the dependency. There are still a few references to AppCompat you must remove first.

The first reference to AppCompat that you need to remove is in your MainActivity. Your MainActivity extends from AppCompatActivity, following the recommendation for all apps using the framework UI toolkit. In addition to back-porting behaviors to older versions of Android, AppCompatActivity also provides hooks that other Jetpack libraries, like ViewModel, require.

If you replace AppCompatActivity with the platform-provided Activity class, you will lose the ability to use several other Jetpack libraries, which is not ideal. Instead, you can use ComponentActivity, which exists in the middle ground between the base Activity class and the full-fledged AppCompatActivity class.

ComponentActivity exists outside AppCompat and provides hooks so that other libraries that need deeper access to your activity, such as the AndroidX Lifecycle library and ViewModel, can do what they need to do. Using ComponentActivity allows these integrations to continue working, while removing your dependence on the AppCompat library.

To migrate to ComponentActivity, update your MainActivity class to change which variation of Activity it extends from. Also, delete the import statement for AppCompatActivity.

import androidx.appcompat.app.AppCompatActivity
...
class MainActivity : AppCompatActivity() ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            AppTheme {
                PizzaBuilderScreen()
            }
        }
    }
}

There is one final usage of AppCompat lingering in your project. It is in the application theme you specify for Coda Pizza. To remove this reference, you will need to change the theme that your application theme, Theme.CodaPizza, is based on.

AppCompat themes provide many customizations to the built-in themes provided by the platform to ensure consistency and to bring new features to the views you can use. But these benefits only apply to framework views, which are nowhere to be found in Coda Pizza.

Because these customizations are unnecessary, you can safely remove the reference to Theme.AppCompat and replace it with a reference to the Theme.Material theme that ships with the platform. Although there may be discrepancies in this theme’s appearance across versions, nothing in the theme will affect your Compose UI, making the differences negligible.

<resources xmlns:tools="http://schemas.android.com/tools">
    <!-- Base application theme. -->
    <style name="Theme.CodaPizza" parent="Theme.AppCompat.Light.NoActionBar">
    <style name="Theme.CodaPizza" parent="android:Theme.Material.NoActionBar">
    </style>
</resources>

At this point, Coda Pizza no longer references anything from the AppCompat library. To confirm this, open the Find in Files dialog by pressing Command-Shift-F (Ctrl-Shift-F). In the dialog, enter the query appcompat to search every file in your project for this term (Figure 29.15).

Figure 29.15  Looking for AppCompat

You will see one hit in your Gradle build file, but none of your Kotlin files should contain references. If you see any Kotlin files in these results, double-check that the code in these files matches the code in this book exactly, with no leftover references to AppCompat. You may also need to delete a few lingering import statements in your project if Android Studio did not automatically remove them.

After cleaning up any rogue references to AppCompat, your last step is to remove the venerable dependency from your project. While you are removing AppCompat’s dependency, also remove the dependency for ConstraintLayout, which was automatically added with the blank project template.

...
dependencies {
    implementation 'androidx.core:core-ktx:1.7.0'
    implementation 'androidx.appcompat:appcompat:1.4.1'
    implementation 'androidx.constraintlayout:constraintlayout:2.1.3'
    ...
}

Sync your changes, then run Coda Pizza one last time. It should behave exactly as it did before – but now, Android Studio can build your project ever so slightly faster, and your application size will be smaller.

Although the benefits of removing AppCompat are somewhat small, this change signifies the start of a major paradigm shift powered by Jetpack Compose. Under Jetpack Compose, many of the tools you have become familiar with are no longer necessary. Components like RecyclerView and Fragment can be big sources of complexity in an Android app, but you do not need them in Compose.

We love Jetpack Compose for its ease of use and effectiveness at building UIs in Android apps. You have only scratched the surface of what Jetpack Compose can do, and we encourage you to experiment with it in your own apps. You will almost certainly encounter and create many framework views in your time as an Android developer, because they have been the only way to build UIs for more than a decade. But we expect that you will see fewer and fewer framework UIs over time as Compose brings about a renaissance in the world of Android development.