In the last year, the Android development team in Google became very opinionated about how we should architect our apps, and it very blessed, it doesn’t mean that we have to implement our app in their suggested way but it does mean that we have to compare the way that we currently / plan to architect our apps with their suggesting.

In the last Google I/O the Android development team suggest that all screens in our app should be in single Activity as opposed to wide conception until now that each screen should reside in its own Activity, more precisely they suggest to treat the Activity as our main function in console app, meaning that it’s just visual entry point to our app and if we have more than one visual entry point so we should have more than one Activity, For me, it feels more consistent with other App Components like BroadcastReceiver, we never jump from on BroadcastReceiver to other BroadcastReceiver.

Alternatives To Multi Activities

There some libraries that use only custom views in single Activity instead of Fragments or Activities such as Conductor, scoop, and Litho, so the concept of single Activity is not new, besides that with the new awesome Navigation Architecture Component, the job to navigate between screens become much easier and standardised so we don’t need to invent the wheel every time.

Why To Think About it?

As I mentioned before the fact that the Android development team suggest moving to this architecture doesn’t mean that we have to do it but it does force us to think what are the problems with multi Activities, in the rest of this post I’ll share some of the problems that occur to my team while working with multi Activities, it’s not meant to be complete list but hopefully it will make you consider to move to single Activity approach.

Share Data From One Activity To Other One

In order to share data from one Activity to other one we need that all the data Object types will be Parcelable (the use of Parcelable isn’t unique just for sharing data from one Activity to other one but at least in our case it’s the majority use case to use it) this force us that all the data’s classes need to implement the Parcelable interface and the read and write of Parcelable is very error prone so Android Studio plugins and Annotations libraries that help with this read-write process became very popular.

What is even worse is the size of data that you need to move, when you just start, the size is very small but over the time you need to share more and more data and than to across crashes so you start to use the SharedPreferences and marshall and unmarshall the data and then face other crashes so you start to think on other crazy ideas while all you wanted is just share the data.

Share Data In The Same Activity

Within the same Activity, there are much simpler solutions, one that I’m really like is just use ViewModel on the Activity level, from one Fragment (or View) to write into LiveData that reside in the ViewModel and from the other Fragment (or View) read the data from the LiveData.

suggest solution to share data between 2 fragments

Show Overlay When The Activity End Its Work

In one of our apps we have a flow that Activity A call to Activity B to do some work and before we go back to Activity A we need to show overlay screen for a couple of seconds in order to notify the user that the current action has been ended and after it we should show again Activity A, we can delay the call to the Activity B finish method until after the overlay will end or we can return result to Activity A which will show the overlay, in both cases this is too much work for just show this overlay screen. In single Activity world, this problem not exist.

Inter-App Communication

Our code base is 6 years old and we do have some old patterns in the code like use of LocalBroadcastManager and Otto both of them working great most of the time but I have fixed more than one bug that its description is similar to the following scenario, event was fire from one component while Activity transition occurring so we register to receive this event a bit after the event was fired, this cause to miss this event, once again in single Activity world it will not happen.

Base Activity

Our nature as a software developer is to reduce code duplication, if we need to check whether the user is logged in or to handle runtime permissions and we do it in more than one Activity we will create Base Activity and move that code to there. Once we have Base Activity it will become a monster very quickly, in order to test Activity with Espresso tests I need somehow to disable some functionality of the Base Activity, and if we lost our focus on our quality, the Base Activity start to know other Activities and our way to modularize our code into modules lost with it.

Summary

To all of the problems that I have described here, there are solutions in multi Activities world, and we used them as well but those solutions cause us to write more patchy code, In single Activity model all of the problems not exist or have much more elegant solutions. I encourage you into 2 things, try to think what are the downsides of multi Activities for your app and share problems that you faced here so others can take them into account as well.