Hey everyone. Earlier when we created KMP app with...
# multiplatform
r
Hey everyone. Earlier when we created KMP app with shared UI logic too. It would have provided
composeApp
and
shared
modules. and shared would be containing logic till domain layer. But after migrating my application to domain and started composeApp module with UI and viewmodel I realised in composeApp don't have way for viewmodel to be initialised via
koin
.(If have way then please let me know) But now when we create new project using KMP plugin it do not provide shared module instead official documentation suggest to put shared logics in same module too. My question: is KMP really stable. without knowing it changed a lot in 4-5 months for me. Can it be trusted.
m
Hello @RANJAN, • yes KMP is stable since a long time, what was alpha/beta was Compose Multiplatform (CMP), but now also stable on iOS. It can be trusted • Basically Jetbrains changed the “new project” setup, but you are free too choose any project structure you would like, what they give in sample app is just one approach • Yes you can use Koin in you composeApp module. But what is important, there must be one entry point to Koin (creation of the Koin application, most likely in composeApp). So you can basically do the following: 1. Have composeApp module for UI 2. Have shared module which contains domain until viewmodels 3. In composeApp, inside your composable, use koinViewModel() to retrieve VM from shared module
r
Thanks for clarifying @Max. Well a follow up question, viewmodels should lie in composeApp module with UIs correct? asked chatGPT the same confusion of using old shared module way structure or using the latest project structure. It suggested to use the latest for prototypes only. What would you prefer to use.?
m
Hey @RANJAN, Where the ViewModels lay depends on your desired goal. Yes ViewModels belong to the UI part of the app but if you want to implement a native iOS UI with Swift, then you need to be able to integrate the ViewModels into your XCode project without getting the Compose UI. So to your specific setup with
composeApp
and
shared
module: You want compose UI on all plattforms? --> ViewModels in
composeApp
is fine You want native UI on some plattform which only consumes ViewModels and renders native UI -> ViewModels in shared (so you can just depend on shared, and are not forced to add dependency on composeApp for a platform that doesn’t need compose) I prefer a slightly different setup depending on the project. Main question: do i want compose everywhere or native iOS UI? Case 1: Compose everywhere:
:app
(you
composeApp
module, i just like to rename it), hosts Koin setup and entrance point to App
:core
hosts all core data and domain logic with various submodules like
:core:auth
or
:core:network
. They are not actually submodules, just if you name them with
:
then Android Studio nicely sorts them in like :core :network :auth :data etc
:feature
with submodules for each feature. For example
:home
or
:settings
Case 2: Native UI on iOS If i want to only share down to ViewModels, then everything from above stays the same, but each feature module has actually two modules. A shared and a ui module. So for example
:feature:settings:compose
(purely compose consuming ViewModels) and
:feature:settings:shared
(data, domain, down to ViewModel). iOS then just consumes
feature:settings:shared