Convert core module to Kotlin Mutliplatform #133
Conversation
There was a problem hiding this comment.
Could we also add altitude to the location?
There was a problem hiding this comment.
I currently added only the fields, that are used internal by us. But yes, I think adding altitude make sense.
Something else what you missed?
| /** | ||
| * Date & time of this location fix in UTC zone. | ||
| */ | ||
| val time: Instant = Clock.System.now(), |
There was a problem hiding this comment.
We made some bad experiences with kotlinx.datetime, especially since they have issues with Android SDK 26 and below:
If you target Android devices running below API 26, you need to use Android Gradle plugin 4.0 or newer and enable core library desugaring.
Not sure if you did that, but in general, we could just use time millis (or actually time in seconds - because that's what we get from iOS) and simply store this here? So no instant, simple Long?
There was a problem hiding this comment.
Wow okay.. Okay then I would also suggest to use Long as time. I'm more fan of using objects instead of natives. But I'm on your side in this case. I will change this
There was a problem hiding this comment.
Does it make sense to have this in KMP?
There was a problem hiding this comment.
No, only for the Android package. I moved this out now.
Fabi755
force-pushed
the
feature/kmp-core
branch
from
202922a to
6ddcf15
Compare
| @@ -118,7 +120,7 @@ private void cacheRouteOptions(RouteOptions routeOptions) { | |||
| private void cacheRouteDestination() { | |||
| boolean hasValidCoordinates = routeOptions != null && !routeOptions.getCoordinates().isEmpty(); | |||
| if (hasValidCoordinates) { | |||
| List<Point> coordinates = routeOptions.getCoordinates(); | |||
| List<Point> coordinates = toMapLibrePoints(routeOptions.getCoordinates()); | |||
There was a problem hiding this comment.
This converting is very annoying and confusing for the developers. We now having three Point types
- MapLibre (Android)
- MapLibre Navigation (generic KMP)
- Mapbox
But as mentioned, we need to decide how and where we want to have the generic GeoJson stuff. Changing this before this, make multiple effort and work.
|
If the package movements are to annoying for the review to you, I can also create a pre-PR that only moving stuff. So this changes are then not visible anymore in the changes. Only an offer to you reviewers! |
There was a problem hiding this comment.
@Fabi755 changes in other languages are missing
Fabi755
changed the title
|
|
||
| @Before | ||
| fun setUp() { | ||
| Dispatchers.setMain(mainThreadSurrogate) |
There was a problem hiding this comment.
Consider resetting the main dispatcher in a teardown to avoid polluting other test classes.
This PR is migrating the core module to Kotlin Multiplatform.
Breaking changes
android.location.Locationwe have now our own genericorg.maplibre.navigation.core.location.Location.libandroid-navigationrenamed tomaplibre-navigation-core(important for Jitpack reference)org.maplibre.navigation.android.navigation.v5.has renamed toorg.maplibre.navigation.coreMapLibreNavigation, but there it's now required to set aLocationEngine. Alternative usingAndroidMapLibreNavigation/IOSMapLibreNavigationfor a default implementation of this parameter.Some key facts:
contextand other Android platform related classes.NavigationService,Notificationand Android specific threading. I don't see a reason to keep this, I switched the threading to coroutines, and the notification and foregrounds service are now optional components, that included in the UI module.android, I renamed the module tomaplibre-navigation-coreandroid, I renamed the package fromorg.maplibre.navigation.android.navigation.v5.toorg.maplibre.navigation.corePlatform specific logic
Two categories of platform specific parts are affected this module.
**1. the location logic.*+ I'm very happy with the solution around the
LocationEngineand the platform specific logic.2. the MapLibre library / GeoJson / Turf logic. I'm very unhappy with the geojson stuff. I now added a new module
maplibre-navigation-geothat holds some partial (simplified) copies of thegeojsonandturfstuff. The original repository maplibre-java are used before by the Android client. But Java code can not included to iOS with KMP.I see three solutions for this:
All of this points having up- and downsides. I choosed now the 3. point, because it was the fastest. I would suggest to create a follow up issue and discuss this here.
To find a solution, we need also input from the maintainers of
maplibre-javaand needing also a look to the iOS side, and how we implement this core module.Performance
I changed a the whole logic structure, that was necessary to remove all Android related things, and using plain Kotlin. I tried my best to keep it simple and efficient. But I think we all should do some performance tests with real navigations and real-life example usages.