Need advice on what to focus. I have developed some iOS apps and just recently learning Android dev. I have learn the basic (and glance through example apps) of Kotlin, Coroutines, Flow, Multiplatform, Ktor, Jetpack LiveData, Navigation, ViewModel, Fragment etc, and understand what stacks are required for modern Android app. The next step for my learning is develop an actual app and plan to master Android development by end of the year. I have more or less settle on Multiplatform with sqldelight, koin and kTor http client for the common codes. On the Android side, the choices are option A: current Jetpack components (Navigation, LiveData, ViewModel) or option B: Compose. Option A has many different pieces to learn and will take more time to master. The easy solution to to pick up both but it might be a waste as it appears that many Jetpack components such as Navigation, LiveData might not be even needed in Compose. On the other hand there are many tutorials, sample apps and architecture recommendation for the current Jetpack components, while its practically non existent for Compose (for example what’s the best stacks to use for an MVVM, MVI architecture Android app with Compose? Can one use Flow instead of LiveData?). Any advice, insights is much appreciated as I probably have some misunderstanding of modern Android stacks. Is knowledge of LiveData, Navigation, ViewModel etc essential for future (next year onwards) Android app development (assuming I do not need to support old Android codes)? If you’re planing a new Andoid app from scratch to start developing beginning 2021, what components/stacks would you use?

I myself am a fullstack dev and just started learning android recently so take that under consideration. In general the best way to learn stuff is to make projects, same goes for android. Just start making apps that are more and more complex, one simple screen with current weather info would be great at first. From what I understood from the android docs, MVVM is the way to go for now. In other words LiveData, ViewModel etc are indeed essential. Compose is great but simply isn't there yet, there's no navigation built in, no pre-made components (you have to build everything from scratch basically)

I have build a few toy apps and in the midst of going through the Google/Udacity course. Next I’ll be porting one of my iOS app over. Will use the current Jetpack components for this app, and then look into Compose end of the year. Thanks for the response.

When starting new project I’d just to stick to using a minimal 3rd party stack. Only the necessities should be there. As for the rest, I’d stay away from Coroutines / Flow (personally!) and use RxJava. But that heavily depends on what your use case is and whether or not you will actually benefit from FRP or you just need some async work. MVVM etc. doesn’t really matter. See what fits you most and as an iOS dev be aware of the Android’s app lifecycle and process death. It is quite different compared to iOS and you have to keep the process death in mind when designing your code.

I noticed the difference. Thanks for the highlight and the advice.

The state of Android developement is frustrating, I tried to build apps using different component and architectural patterns MVC, MVP, MVI and MVVM, and I found MVVM to be the most comfortable for me, so choose what’s comfortable for you and build the app, there’s no perfect architecture.

I use Flow or Rx instead of LiveData, I think those components and navigation are really bad. There are many samples but I find them needlessly complex. I like MVVM as an architecture, but the Android implementation is just bad. I suggest you try it out tho, see what you feel comfortable with. Just respect seperation of concerns and SOLID and you’ll be fine. Compose etc is cool but not ready. Watch out for all the hype with the new stuff, a lot isn’t really better, for example the constraintlayout is good for complex UI but performs worse for simple nested layouts. People follow the hype of all the new components, use it all the time and defend that it’s the best way without ever validating it. The google samples really don’t produce the “best” code, but it allows a lot of people to follow a predefined architecture.

@Christophe Smet out of curiosity, do you deal with the lifecycle stuff manually when using rx instead of live data?

Sure, I wrote an extension that allows any Flowable,Single, Observable to compose with a lifecycleOwner. Then you can decided between what events you want to recieve the data. So going in onPause could keep the http calls going, but an onDestroy would cancel and dispose everything. That way you don’t have to make multiple sealed classes for loading states if you have multiple data sources in a UI. Its also easier to hookup retry strategies. It doesn’t really store data like LiveData does, but thats not really an issue for me.