I'm looking to move into multiplatform, going forward. My past is all Android, using MVVM, Uncle Bob...

# multiplatform

[Eoin Conroy]

I'm looking to move into multiplatform, going forward. My past is all Android, using MVVM, Uncle Bob's Clean Code Architecture, Android Architecture components (LiveData, Navigation etc), dagger, rxjava, retrofit. When I move to multiplatform, do I need to shift my thinking, or can I still use MVVM (Decompose?) and Clean Code Arch? Whats the industry standard now for multiplatform apps, in terms or architecture? I presume its up to me if I want to structure my packages in the common module to have a data and domain layer? Although, in Android i'd have separate modules for each layer. I'm just starting to get into multiplatform so just wanna start on the right path. Is it possible to use the same architecture as an android app or should I forget everything I've learned and start fresh? Thanks.

[CLOVIS]

You're free to use any architecture you want. As with Android, you can create any number of modules. What I recommend is having utility modules where you expect-actual what you will need, then domain modules which are 100% common code, to avoid having platform-specific stuff in domain modules.

[Alex Acosta]

Your Android knowledge appears to be solid and can work as your base for KMM coding. Regarding architectures, KMM is not really bound to a specific so you can apply the one you feel is the best for your app and your coding.

[ankur2037]

You can start off with some core logic modules like Networking (using Ktor), Serialization (go with kotlinx-serialization) and Analytics (a combo of Networking, Serialization and Sql-Delight), Plus some common extension functions utility module. That'll pretty much cover major part of your business logic.
After done with this, you can move on to building your feature-specific modules.

[ankur2037]

For every feature module, you can make two separate modules - one for API and one for implementation. Keeping in mind that each implementation module should only depend on API modules.
To connect all your modules and sort out their dependencies along with platform specific dependencies, you can make a dedicated Injector module using the Koin DI framework.

[Eoin Conroy]

Thanks guys. I appreciate the replies. I think I can figure out the rest. I was getting slowed down by the absence of ViewModels and navigation but I think they're covered by Decompose in some way. Although it seems I can use a more familiar ViewModel by using Moko-MVVM or KMM-ViewModel (or roll my own ViewModel class).

[CLOVIS]

In my experience, what you will find the weirdest is that there is no lifecycle constraints on KMP. Backend doesn't have lifecycle, Desktop doesn't have lifecycle, Web doesn't have lifecycle… So a lot of things that are taken as the One Way™ on Android just aren't there.

[Arkadii Ivanov]

I believe all client targets have some kind of lifecycle. E.g. a desktop window can be minimized or lose focus, so onPause/onStop/onStart/onResume do make sense, right? Same with iOS and even Web Browser.

[Arkadii Ivanov]

Decompose provides lifecycle abstraction for all targets, and even state preservation (Parcelize) for iOS and Desktop.

[CLOVIS]

If you do want to support it, sure, it's possible. What I meant is, I know no desktop app which actually frees its memory when it's minimized; unlike in the Android world where it's very important to always do it.

[CLOVIS]

Developers who mainly do desktop apps or web apps are not in the mindset of always thinking of the lifecycle, and in my experience that has made communication with Android devs a bit harder sometimes. KMP libraries often are not built with this in mind either. Of course, this doesn't mean you can't deal with the lifecycle, I'm just saying you should keep all that in mind.