A Kotlin multiplatform (Android/iOS) Library app. The app utilizes the following:
- Ktor for networking
- Kotlinx Serialization
- Multiplatform Settings
- SqlDelight
- ReduxKotlin
Building and testing the Android App can be completed with:
./gradlew build
or install with:
./gradle androidInstall
or opened and ran in Android Studio
iOS can be implemented quickly now that code is in a common module.
A LibraryApp object holds the state of the app in a redux store and provides a methods for views (fragments/UIViewControllers) to "attach". The LibraryApp is initialized in the Application class on Android, and the AppDelegate on iOS. Because this LibraryApp and the store is created at the application scope, the application state survives between ViewControllers/Fragments and rotation. Each view must attach/detach from the GameEngine when it is visible. LibraryApp.attachView(view) returns the appropriate presenter for the view.
BaseLibraryViewFragment & BaseLibraryViewController handle attaching/detaching the presenter at the appropriate lifecycle methods. Each Fragment/ViewController extends from these.
An MVP arch is used with a redux store as the 'Model'. This approach allows maximum reuse of code and a simple contract for the platforms to satisfy. Presenters send ViewStates (simple data classes with fields needed to render UI) to the View interface. The View implementation has a reference to the presenter, and calls methods on the presenter for user interaction. This creates a unidirectional dataflow:
User interaction -> Dispatch Action -> new state (reduce) -> view rendered by presenter
Views in this arch are truly 'dumb' - they should contain nearly no logic. They are responsible for rendering the view based on the ViewState given to them by the presenter. They are implemented for each platform and utilize native UI SDKs and libs for each platform. Android uses Fragments and iOS uses UIViewControllers.
TODO
In the redux world there are many ways to handle creation of async actions. Thunks have been used in this app. NetworkThunks both use coroutines to launch concurrent operations that dispatch actions.
In this app, Navigation is considered a side effect of the AppState. The NavigationMiddleware handles changing screens based on dispatched actions. The NavigationMiddleware takes an implementation of Navigator which is implemented for each platform.