I haven’t really written a proper documentation yet. I am planning to do it once I finish the Desktop and Web implementations.
However here are some general steps I would follow to get started:
1. First of all, we start from the shared code and we define the screens of our app in the ScreenEnum.kt file, initialially just specifying the string and the navigation level.
2. After you have done this, for each screen you need to define 2 data classes:
a. the data class for the screen state (extending the interface ScreenState), which you specify in the _screen_State.kt file inside the screen folder (e.g. viewmodel/screens/countrieslist/CountriesListState.kt)
b. the data class for the screen parameters (extending the interface ScreenParams), which you specify in the _screen_Init.kt file inside the screen folder (e.g. viewmodel/screens/countrieslist/CountriesListInit.kt)
3. In the NavigationSettings.kt file, specify all your Navigation Level 1 items, which basically are the items that go in the main Menu (such as the bottom bar). For each Navigation Level 1 item, you need to specify the ScreenIdentifer.
4. The ScreenIdentifier requires 2 elements, the Screen Enum value and (optionally) a ScreenParams object. In the D-KMP sample we are using 2 Navigation Level 1 items, which are different instances of the same Screen Enum value “CountriesList”. Different instances means that they have different params, as you can see in the NavigationSettings.kt file of the D-KMP sample.
5. Let’s now define how the data loads in each screen. You can do that by specifying a Navigation extension function inside the _screen_Init.kt file (e.g. viewmodel/screens/countrieslist/CountriesListInit.kt), the same where you defined the the ScreenParams data class. The function takes the ScreenParams data class as its only parameter, and returns an instance of the ScreenInitSettings, where you define in initState the initial state of the screen, and in callOnInit the function to be run to load the data.
6. Give the above extension function the name of _initScreen (_e.g. initCountriesList). And specify this function in the initSettings property of the Screen Enum in the ScreenEnum.kt file.
7. Going back to the callOnInit function we specified in 5). As you can see, what this function does it to take data from the repository and update the ScreenState.
8. In the screenEvents.kt file inside the screen folder (e.g. viewmodel/screens/countrieslist/CountriesListEvents.kt), we define any event function that can be fired by inside the app. Events functions also do the same 2 operations of the “callOnInit” function: take the data from the repository and update the ScreenState.
9. Inside the datalayer folder, you define all the repository functions inside the functions folder, any data classes used by the repository functions inside the objects folder, and any function connecting to a specific datasource inside the sources folder.
10. At this point you have defined the whole shared code for your apps, and you can proceed to write the UI layer.
11. Let’s start with Android. In the composables/screen folder create a subfolder for each screen. Suffix the main screen composable file with “Screen” (e.g. CountriesListScreen). Conveniently split the code in different composables, which you keep inside the same folder.
12. Inside the composables/navigation/*screenPicker.kt* file define the list of all your Composable Screens.
13. Let’s now move to iOS. Similarly to Android, in the view/screen folder create a subfolder for each screen. Suffix the main screen view file with “Screen” (e.g. CountriesListScreen). Conveniently split the code in different views, which you keep inside the same folder.
14. Inside the views/navigation/*screenPicker.swift* file define the list of all your Composable Views.
This is pretty much it. As you can see you don’t need to care about:
• platform-specific view models
• dependency injection
• coroutines scopes
• kotlin/native concurrency issues
• app lifecycles
• platform-specific navigation
It’s all taken care by the architecture.
If you need any more specific explanation, please let me know.
Please bear in mind that the sample is in continuous evolution, so the code might change often in the future, but hopefully for the better.
Next week there will be an update where the sample will start wrapping the native iOS NavigationLink component under the hood, so providing the native iOS framework animations when navigation from one page to another.
Within a couple of weeks, also the Web and Desktop apps will be added, sharing as much Compose as possible between the Android, Desktop and Web apps.