Modernize Your Android App With The Single Activity Pattern

If you’ve been developing Android apps for around 3–5 years, probably you learned at the beginning that a screen of your app should be assigned to an activity, following a 1–1 relationship.

This is one of the main lessons when taking the firsts steps into the framework, to keep simplicity when starting and because it was the standard way of developing apps for a long time.

The framework has evolved over the years and different approaches have come and go, and one of those, which is my personal preference, is the Single Activity Pattern.

The Single Activity Pattern

This pattern defends that instead of using an activity for each screen, the app is built with a single activity that works as a container for fragments that will be replaced for each screen, and manage through a stack. The core idea is to change the activities for fragments.

These days, Google is promoting this pattern as a standard to develop Android apps. You can check this conference by Ian Lake, a software engineer at Google, but if you feel lazy, these are the main benefits that are pointed out in the talk:

• Sharing state between activities is harder than doing it between fragments. Fragments can use the container activity to share this data with the help of a ViewModel attached to the lifecycle of the activity, which is going to survive the fragment replacements.
• It’s easier to test UI in isolation when working with fragments.
• Better support for animation when transitioning between fragments than between activities.
• Avoid implying the OS when changing between screens. Activities need to notify the OS every time they are created and destroyed, adding extra overhead that is not really necessary. Overall, fragments are lighter.
• Following the Single Activity Pattern allows the developer to take fully advantage of the Navigation Jetpack library and makes deep-linking easier.

By using the navigation library you can also have a visual representation of the navigation logic of your app as you can see in the following picture.

Nowadays, with the release of Jetpack Compose, we have one more alternative to implement the Single Activity Pattern. Instead of using fragments, we can use composables for each screen, and navigate through them using the Compose Navigation library and completely eliminate fragments.

You could also have a main composable function per fragment and keep using the navigation component explained before to keep that visual representation of your navigation. To be honest, I don’t think that using these fragments as containers for your composables is going to have a penalization in performance, so I personally prefer it to have this overall view of what displays my app has, the navigation logic and I think that the transition to Jetpack Compose is going to be easier this way.

If you want to read more content like this and support me, don’t forget to check my profile or subscribe here to get an email every time I publish new content.