This is what I think a typical app architecture will be.
With third parties starting to release KMP libraries too.
08/25/2020, 4:30 AM
Hey @Daniele B thanks for this! How do I structure a multiplatform library that is basically an API wrapper of a third-party payment service. Should the library include View Model and Data Repository?
08/25/2020, 11:30 AM
@Jeff This architecture I am showing fits to apps that use the new declarative UIs.
If you just want to have a KMP library to be used in an existing app, you don’t have to stick to this architecture.
In my opinion a KMP ViewModel makes a lot of sense in an MVI-declarativeUI app.
But at the same time KMP is so flexible, that it can adapt to any architecture.
A clear distinction between ViewModel and Data Repository helps to organize the code in a clean way.
The ViewModel just defines what is the data to be shown on the UI, and deals with stuff like localization, accessibility text, etc.
The Data Repository is the layer that collects the data from different sources (network calls, local settings, databases) and manages any caching mechanisms.
The UI layer shows the data held in the ViewModel.
The ViewModel queries any data from the Data Repository, without caring what’s the actual source.
The Data Repository manages all the sources, and provides the data required by the ViewModel.
The Data Repository is also what connects to plaftorm-specific services, such as location, or in-app-purchasing or bluetooth, etc.
If you want to use a Watch OS or Wear OS app, you can keep the same Data Repository, and just design a new View Model, which would typically be a stripped down version of the full app View Model
View Model is basically the place where you define your user interaction and usability