https://kotlinlang.org logo
Join Slack
Powered by
Hi, a bit of a high level question. My company has...
# multiplatform
r
Hi, a bit of a high level question. My company has various products and we are looking to create a shared library to reuse across android/iOS. I could build one huge shared library that supports all of them but that seems wrong, or I could build 3 libraries but that seems a duplication of effort as all of them need some things (date formatting across the company has been standardised) 2 of them are very similar and have a large overlap. How best to approach this? I’m currently thinking a standard lib with global stuff and then ProductA/B lib with a dependency on the standard lib and Project C lib with a dependency on the standard lib
I’m also thinking the standard lib could contain important classes and interfaces like the result wrapping pattern for success/error.
m
Make libraries based on domains/features, not platform
Modularization is very often a good thing so if you have clear boundaries, go for multiple libs
r
what do you mean by platform?
m
android/iOS, which re-reading your initial post doesn't seem what you were thinking of?
r
using KMM already means I am not splitting by platform
when I say project A/B/C i mean each project is already on android and iOS
so a fundamental part of the project-specific libs will be making network calls, I can put some common code in a standard lib (enforcing the tolls and how requests are made), with each specific project inheriting this and providing the specific urls/data classes
m
I currently working on a project which aims for a similar goal...luckly without any additional C involved...
Do you only aim for KMM context so - iPhone and AndroidPhone?
r
correct
m
I assume you also want to use threading, right?
r
well I read its a nightmare (on ios) so I can avoid it
calls to the library will be off the main thread so I think its fine to block
m
nightmare is a bit too much...but it can be difficult...since you need painfully keep track that all your data is immutable
But Coroutines work fine so far I know...
In general my advise is work your way up - meaning do any code which is complex or where no KMP/KMP solution is available on the platform
Facade it...and bridge it into Kotlin
and then facade your way up into common
r
thanks
m
Don’t try to make everything in common code...it shines mostly on abstract business rules and usecases...which can be bridged back into the platforms
And try to keep it simple and tested...otherwise you will experience some bad surprises...
hope that helps
And mostly importantly - try not to reinvent the wheel, if it is not necessary...also worth mentioning is to work with Results like kotlin-result - is might a good idea since you can avoid to keep record of your errors which has to be exposed.
r
can you explain your last statement, I don’t quite understand?
m
What I figured out in some projects that Dev tend to reimplement things which are already exists on the platform - for example Base64. It's true that this for example should be in the common stdlib...and it looks easy enough...but even if it looks easy, it might is not...like with Base64, where I saw that Dev done it by themself and of course it worked for ASCII, but not for UTF-8. However if you use the implementation of the platform instead you eventually avoid such traps. In regards of Result - as the docs state - you need to annotate the errors you are actively using otherwise it will be difficult on iOS to deal with them. If you instead use a Result you avoid that all since errors are simply a destructible return value.
t
I would start simple with one KMM library. I find one of the biggest pain points is maintaining the gradle scripts, so the fewer the better. And (in theory) the linker should handle stripping out unused code, so size may not be an issue…
Open in Slack
PreviousNext
Powered by