I am a Developer Advocate for Security in Mobile Apps and APIs at approov.io.
Another passion is the Elixir programming language that was designed to be concurrent, distributed and fault tolerant.
Location
Scotland
Education
Self teached Developer
Work
Developer Advocate for Mobile and API Security at approov.io
The recommendation now is to build single Activity applications (or small number of activities) which contradicts the old advice of having a ton of activities. JetPack navigation works great if you follow this advice.
If I understand this well, it means a file of code with thousands of lines, that will handle all the screens in your mobile app?
Can you elaborate why this is now the recommendation?
Instead of using tons of activities, use fragments that can be retained so on screen rotation we avoid creating elements, just put on front, for example.
Even though Fragments have some shortcomings it is still a good idea to use them. This could work out great for you if you want to support different form factors in the future (phones, tablets, chromebooks, ....).
That said Fragments will not retain much on config changes (screen rotation for example) to handle state there are a few options out there, I would recommend Lifecycles with ViewModel
Back in the day you could find in an Android application codebase a ton of Activity wrappers that are basically doing nothing other than holding fragments. To avoid creating a ton of activities some people would use a generic SingleFragmentActivity.
With something like the Navigation Jetpack library and NavHostFragment you can support the typical forward path of your application + back and up handling + deep linking and deep linking back stack.
It definitely does not mean using a single file with thousands of lines of code. In fact, quite the opposite.
In the past, everything was dumped into an Activity. Handling UI events, formatting data to display on the screen, inserting data into a database, calling to an external service.... everything. It was horrible to maintain, nearly impossible to test, and extremely prone to getting into invalid states due to too much stuff being managed in the wrong place and getting messed with because of the Activity lifecycle. Activities were expected to handle app state, navigation flows to other activities, UI, interaction, and data processing. Clearly no separation of concerns.
The first steps toward breaking up those activities were Fragments, but people tended to just move all that stuff from an Activity into a Fragment. Now, the problem was compounded because you have both the Activity and Fragment lifecycles to worry about. But a single Fragment inside in Activity is no bueno, and kinda defeats the purpose they were created for. This period of time is why so many people are still very soured on Fragments (including myself; I haven't quite made the jump to the NavigationComponent yet).
The way to go about it now should be to utilize the NavigationComponent to swap Fragments in-and-out, and use ViewModels for holding and managing the data needed between those fragments. Now, an Activity should host a NavigationComponent. Fragments handle UI and interaction. ViewModels handle app state. Data processing should be done in RxJava or Kotlin Coroutines, typically in dedicated service classes. Overall, a much better separation of concerns.
If I understand this well, it means a file of code with thousands of lines, that will handle all the screens in your mobile app?
Can you elaborate why this is now the recommendation?
Instead of using tons of activities, use fragments that can be retained so on screen rotation we avoid creating elements, just put on front, for example.
Even though Fragments have some shortcomings it is still a good idea to use them. This could work out great for you if you want to support different form factors in the future (phones, tablets, chromebooks, ....).
That said Fragments will not retain much on config changes (screen rotation for example) to handle state there are a few options out there, I would recommend Lifecycles with ViewModel
Back in the day you could find in an Android application codebase a ton of Activity wrappers that are basically doing nothing other than holding fragments. To avoid creating a ton of activities some people would use a generic SingleFragmentActivity.
With something like the Navigation Jetpack library and NavHostFragment you can support the typical forward path of your application + back and up handling + deep linking and deep linking back stack.
To learn more about why Single Activity makes sense, check out this great talk by Ian Lake
It definitely does not mean using a single file with thousands of lines of code. In fact, quite the opposite.
In the past, everything was dumped into an Activity. Handling UI events, formatting data to display on the screen, inserting data into a database, calling to an external service.... everything. It was horrible to maintain, nearly impossible to test, and extremely prone to getting into invalid states due to too much stuff being managed in the wrong place and getting messed with because of the Activity lifecycle. Activities were expected to handle app state, navigation flows to other activities, UI, interaction, and data processing. Clearly no separation of concerns.
The first steps toward breaking up those activities were Fragments, but people tended to just move all that stuff from an Activity into a Fragment. Now, the problem was compounded because you have both the Activity and Fragment lifecycles to worry about. But a single Fragment inside in Activity is no bueno, and kinda defeats the purpose they were created for. This period of time is why so many people are still very soured on Fragments (including myself; I haven't quite made the jump to the NavigationComponent yet).
The way to go about it now should be to utilize the NavigationComponent to swap Fragments in-and-out, and use ViewModels for holding and managing the data needed between those fragments. Now, an Activity should host a NavigationComponent. Fragments handle UI and interaction. ViewModels handle app state. Data processing should be done in RxJava or Kotlin Coroutines, typically in dedicated service classes. Overall, a much better separation of concerns.
Excellent explanation and a great brief history of how things used to be in the Android world 👍