Raccoon/docs/tech_manual/tech_stack.md
Dieguitux e0ee7eb4e0
refactor(di): migrate from Koin to Kodein (#181)
* update version catalog

* remove convention plugin

* create :core:di module

* migrate android and ios apps

* migrate :shared module

* migrate core modules

* migrate domain modules

* migrate feature modules

* migrate unit modules

* update licences screen

* update documentation

* add a test for ProfileSideMenuViewModel
2024-12-22 15:12:42 +01:00

7.3 KiB

Tech stack

Here is a list of the technologies used in the project, with a short historical explanation in the cases where the initial choice changed over time and the reasons why the change was made.

Dependency Injection
The choice here is the Kodein library. The main reason it was selected because of its great multiplatform support and the integration with the navigation library (which at the beginning of the project was not there yet, but was added later and proved to work great). You can find module definitions (beware, Gradle modules and DI modules are two different concepts and should not be confused) in a `di` package inside each subproject, modules can include each other and all top-level modules are included in the shared module, more on it in "Module overview and dependencies". Initially the project started using another very popular DI library, Koin, but after discovering that, if you use their annotation processor to generate modules by reading annotations, builds are not reproducible any more (which is written nowhere in the documentation), I decided to make a U-turn and move to a more reliable library and I don't want to hear about Koin ever (ever!) again in my life as a developer.
Navigation
For navigation the Voyager library has been selected. Again, the choice was driven by its multi-platform support, its very practical approach and ease to set up and get going, compared to other multi-platform libraries like Decompose that were used in the past. Nonetheless, and this lesson was learned the hard way, easiness of use and compactness mean that things will go smooth in the future, and as the project grew the navigation library started to show its limits. Part of them were addressed by encapsulating the transition logic (to push/pop screens into the navigation stack and open/close modal bottom sheets) into a centralized component NavigationCoordinator.kt. Something similar was done for the navigation drawer in DrawerCoordinator.kt. Even the DI integration was not totally pain-free, the :core:navigation module contains some glue code that is used to work around some of the issues that were encountered.
Networking
Here, at least for Android developers, no surprises: the choice was Ktor which has great multiplatform support. Instead of using Retrofit, to create network adapters the Ktorfit library is used, which uses KSP to parse annotations and generate code.
Resource management
Initially the project used the Moko resources library to load fonts, icons and all the localized messages used in the UI. It worked great, since in those areas Compose multiplatform missed the needed functionalities. But as long as the project grew in size and more complex KSP configurations were needed, having all modules depend on resources became unmaintainable. This is why I migrated drawable and font loading to Compose build-in system. For localization, the choice was the Lyricist library, which better handles dynamic language changes but it had a couple of issues: its XML processor made builds non-reproducible which was a huge issue in order to publish on F-Droid and it did not manage plurals correctly; if using pure Kotlin files its format is non-standard and therefore incompatible with tools like Weblate.
Image loading
This was something that was expected to be simpler but unfortunately it wasn't. In the beginning the project used the Kamel library which had a major bug while rendering large images, which took a long time to be considered. The project was already relying on Kamel for many things, from loading images on demand to Markdown rendering, so deciding to switch was not easy at all. So as a first step, Coil 2.x was adopted on Android while keeping Kamel on iOS and, finally, when Coil 3.x became stable with multiplatform support all the project has been completely migrated.
Preference storage
Here the choice was the Multiplatform settings libary which not only works great but also offers support for encryption.
Primary persistence
This project was a chance to experiment with SQLDelight (in other multiplatform projects other libraries were tested like Exposed), whereas database encryption is obtained through SQLCipher Android, formerly Android Database SQLCipher.
Markdown rendering
This was another part, like image loading, where KMP was at the beginning quite lacky. After having given up for some time and used Markwon (Java + Views) on the Android part of the app, I decided to give a second chance to Multiplatform Markdown Renderer which was initially user for the multiplatform source set. The project grew and matured over time and it made it possible to add custom handlers (like modular plug-ins) which made possible to support Lemmy's custom features like spoilers. The migration from multiplatform renderer to Markwon and back to multiplatform renderer was not easy, but this project is about KMP so, as a consequence, a pure Kotlin and pure Compose solution had to be preferred. Even if it implies to sacrifice some functionality.
Video playback
The initial choice was to write a custom native implementation based on Exoplayer on Android and on AVPlayer on iOS. This solution kind of worked but had some issues and with later updates of Compose Multiplatform it was using deprecated functions on iOS. This is why the video player was eventually migrated to ComposeMultiplatformMediaPlayer.
Theme generation
The application allows to select a custom color and generate a Material 3 color scheme as a palette originate from that seed color. This is achieved by using the MaterialKolor library which was designed to be multiplatform and works as a charm for the purpose. Thanks!
Reorderable lists
The ability to reorder lists is achieved thanks to the Reorderable library which starting from version 1.3.1 has become multiplatform. This functionality is still experimental and is used only in the instance selection bottom sheet for anonymous users.
Web view
Initially a custom web view was implemented, relying on native views (WebView on Android and WKWebView on iOS), but in the end the project was migrated to Calf component to display portions of the Web.