Your Second Kotlin Android App

An activity represents a screen in your app. These activities respond to various life cycle events and when you need to show a different screen, you must launch an entirely new activity. Activities also have a problem in that they are destroyed during configuration changes. A configuration change occurs when something happens on the device that may alter the way a user interacts with your app.

When this occurs, Android will recreate your activity so that you can take advantage of the new environment. This means it is up to you to recreate the state each time a configuration change occurs which turns out to be a lot since rotating the device is also a configuration change.

Android does allow you to manage this process yourself so you can avoid the activity restart, but it’s not the recommended approach and should be considered a last approach. Thankfully, ViewModels persist between configuration changes.

The result of all this is instead of composing your app from different activities, you put all your interface logic into screens and thus use only one activity. This is called single activity architecture and the recommended approach for building your apps.

Single Activity Architecture is a modern approach to developing Android apps that uses one main activity and multiple fragments to handle different parts of the app’s UI.

With Jetpack Compose, implementing Single Activity Architecture has become easier and more efficient. You have one activity and create multiple screens as destinations. You can navigate between destinations using the navigation library. You don’t need to create additional activities or fragments to navigate between screens.

The benefits of using Single Activity Architecture are:

• It is easier to share data between screens. You can scope a viewmodel in a specific graph and be able to share data across all the screens in that graph.
• All navigation within the app occurs within a single activity. This can simplify the navigation code.
• Creating multiple activities for different screens, results in increased overhead due to the creation and destruction of these activities. Single Activity Architecture reduces this overhead by using a single activity and multiple fragments, thereby improving performance.

The ListMaker app you’ve been building throughout this course is a good example of an app that can benefit from Single Activity Architecture. The app has multiple screens and you can navigate between them. You can also share data between screens.