the architecture of D-KMP may be too complex?

[jiqimaogou]

if I just write a network request and update the UI. D-KMP has so many concepts:

1. Events.kt
2. KMPViewModel.kt
3. StateManager.kt
4. StateProviders.kt
5. StateReducers.kt
6. Repository.kt

and the relation between these concept is also complex. I think these are hard to maintain.

can you simple the architecture of D-KMP, make more less concepts, and less relationship between these concepts.

[dbaroncelli]

Hi @jiqimaogou thanks for your feedback.

I think the most important concept is the separation between the ViewModel and Repository, which is present in all architectures. These are the main 2 blocks.
Specifically, the D-KMP Architecture is implementing the MVI pattern, which requires to organize the ViewModel in a certain way. The MVI pattern helps writing very simple code, but in order to do that you need to give a very neat structure.

The 4 elements in the KMPViewModel are simply:

• Events, called by the UI layer to perform actions
• StateProviders, called by the UI layer to get the state for each screen
• StateReducers, where we define all functions that make modifications to the state (they are always called by the Events)
• StateManager, this is the core class of the whole architecture. It provides a consistent mechanism to manage state initializations and coroutine scopes.

The 6 files you mentioned:
Events.kt
KMPViewModel.kt
StateManager.kt
StateProviders.kt
StateReducers.kt
Repository.kt
stay the same for each app. There is not really anything to maintain.

What you personalize in the shared code of each app, is just:

• the 4 files (Events, State, StateProvider, StateReducers) in each screen folder in the ViewModel
• the functions, objects and sources in the DataLayer

Feel free to provide more specific feedback on which further simplifications you think could be made.

[jiqimaogou]

ok, thank you. I think the answer is ok.