Should I create a separate activity for different user types in a Jetpack Compose single activity architecture?

Question

I'm developing an Android application using Jetpack Compose, and I'm facing a design decision regarding handling different user types, such as admin and user, within the app. Currently, my application follows the single activity architecture.

I'm wondering if it's a good practice to create a new activity, let's call it "ClientActivity," to separate the logic and UI components for different user types. This would mean that when a user logs in, they would be directed to either the main activity or the client activity based on their user type.

I'm aware that Jetpack Compose promotes a more modular and composable UI design, but I'm not sure if creating a new activity is a good fit for this situation. I'd like to get some opinions and advice from the community:

1.Is it advisable to create a new activity for handling different user types in a Jetpack Compose application?

2. What are the pros and cons of using multiple activities in Jetpack Compose for this purpose?

3. Are there alternative approaches or design patterns that would be more suitable for managing different user types within a single activity?

4. How can I maintain a clean and maintainable codebase while accommodating different user types?

I appreciate any insights, best practices, or experiences you can share regarding this architectural decision. Thank you!

Answer 1

By adding a new activity you are introducing a hall set of new problems to deal with.

• When to load this new activity? Is it part of the activity launcher or not?
• What should be the launching mode? Should it have it's own activity stack?

On top of that

• How to promise Admin/User isolation? What if admin is loosing privilege? Should we terminate the activity? Will it exit the app?

While it is possible to solve all those problems, handling it in a single activity where you have a clear admin state as a LiveData that allows you to quickly update the UI as needed, sounds like a much simpler approach to me.