The following is based on my experience working on various Android apps for the past few years and seeing how the framework and the development ecosystem evolved over time.
Concurrency
- Avoid Async tasks, really do not use them. Kotlin coroutines (👍) or RxJava are much nicer to use.
- Don't use Loaders, if you don't know what they are don't bother really.
- Don't use bare threads or manage them on your own.
Clean Code
- Use a dependency injection framework, Koin is great to start with.
- Avoid dagger in your first project.
- Don't use Guice!
UI
- Use Jetpack Components instead of the original Android Support Libraries. And when going through old tutorials remember to replace dependencies with their
andoridx.*equivalent. - 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.
- Don't use headless fragments for communicating between them within an activity. Maintain view state via ViewModels and shared ViewModels instead.
-
ConstraintLayoutis great, give it a try. - Use
RecyclerViewinstead ofListView,GridView,GridLayout, … - Favor Jetpack Fragments over platform Fragments.
Push notifications
- GCM is deprecated, use FCM instead.
- Starting in Android 8.0 (API level 26), all notifications must be assigned to a channel, without a notification channel, the notification will not appear and the system logs an error.
Other
- Eclipse, what is that! Android Studio is great.
- Use Room if you need to manage your internal databases. You can use them with Kotlin coroutines as well.
- Use exo player for audio and video playback.
- Use Kotlin instead of Java and make use of what Kotlin has to offer instead of writing Java code disguised in Kotlin syntax.
-
DownloadServiceis still great. - Keep an eye on Compose.
Top comments (10)
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?
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 👍
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
Is this your opinion or some sort of guideline? Disappointed that it is not backed by any data or cite any source or simple explanation on why/why not.
Much all of this info can be found readily in the Android docs. A few things here are different (preference of Koin over Dagger, which I agree with), but in general, if you spend any time hanging out around Android or Kotlin communities you see all this same stuff. It's not opinion, its the general trends common in the current Android ecosystem.
Some of this is based on my experience working on Android apps for the past few years and seeing how the framework and the development ecosystem changed since. Happy to back and answer any questions.
Since you mentioned how cool kotlin is, u deserve props👍