A whole non-trivial Jetpack Compose-backed app with very few (one?) activities?

Question

With Jetpack Compose, is it a viable way to develop an app by having a single Activity only, and have Compose manage navigation between @Composables? When would it be necessary to add more Activities or Fragments?

Long version: I did some Android development years ago, where you would work with Activities and it was necessary to have multiple of them in any non-trivial app as they were the 'primitive' building blocks of every app. Then, Fragments came along and it was possible to host different ones within a single activity (they supported replacement etc. all with animations) and suddenly it was possible to implement the same app with fewer activities.

Years later, I'm back to Android development, this time with Jetpack Compose. I have already written an app with a couple of screens, using Jetpack Compose Navigation (https://developer.android.com/jetpack/compose/navigation), where @Composables are replaced and I'm very happy with by how much simpler everything has become. It seems that it is now possible to have an app with just a single activity, possibly without fragments either. I think that sometimes different activities might be necessary, e.g. if the application can process various Intents, but even then Compose Navigation supports stuff like deep linking etc.

Answer 1

With Jetpack Compose, is it a viable way to develop an app by having a single Activity only, and have Compose manage navigation between @Composables?

That is the theory. It remains to be proven for massive apps (think Facebook), but for small to mid-size apps, as far as we know, it should be fine.

Also note that the single-activity architecture pattern is not new to Compose UI — some developers have been going that route with fragments for the screens.

When would it be necessary to add more Activities or Fragments?

Assuming that we do not encounter some practical limit, the primary scenario for needing other activities and/or fragments would be for integration with framework classes or third-party libraries, where those external dependencies expect activities or fragments.

For example, app widgets can have a configuration activity. It is possible you could have your one-and-only activity handle that case too, but you might find it simpler to have a one-off small activity class just for the app widget configuration. That way, your main activity class does not get cluttered with logic for trying to distinguish between normal launches and app widget configuration launches. More generally, activities become entry points into your UI, and you probably only need as many activities as you want distinct entry points for different roles.

And, overall, "everything in moderation". If having something be implemented as a separate activity or fragment will help your app materially — ease of initial development, ease of maintenance, etc. — use it! Just because it is practical to have few activities does not mean it is bad to have more than one activity. We just now have even easier means of not forcing multiple activities where we might not need them.