-
-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert core module to Kotlin Mutliplatform #133
base: main
Are you sure you want to change the base?
Conversation
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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! |
|
||
@Before | ||
fun setUp() { | ||
Dispatchers.setMain(mainThreadSurrogate) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider resetting the main dispatcher in a teardown to avoid polluting other test classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅
*/ | ||
open class GoogleLocationEngine( | ||
context: Context, | ||
private val looper: Looper |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looper was nullable beforehand, which was consistent with the underlying Google API: FusedLocationProviderClient
Since the null
value doesn't cause any trouble and its effect is specified in Google's docs, I'd consider making it nullable again.
private val looper: Looper | |
private val looper: Looper? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅
This reverts commit 3af4b82.
This PR is migrating the core module to Kotlin Multiplatform.
Breaking changes
android.location.Location
we have now our own genericorg.maplibre.navigation.core.location.Location
.libandroid-navigation
renamed tomaplibre-navigation-core
(important for Jitpack reference)org.maplibre.navigation.android.navigation.v5.
has renamed toorg.maplibre.navigation.core
MapLibreNavigation
, but there it's now required to set aLocationEngine
. Alternative usingAndroidMapLibreNavigation
/IOSMapLibreNavigation
for a default implementation of this parameter.Some key facts
context
and other Android platform related classes.NavigationService
,Notification
and 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. The navigation core logic is now located innavigation.engine
package. The notification is now located in the UI module innavigation
packageandroid
, I renamed the module tomaplibre-navigation-core
android
, I renamed the package fromorg.maplibre.navigation.android.navigation.v5.
toorg.maplibre.navigation.core
Platform 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
LocationEngine
and 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-geo
that holds some partial (simplified) copies of thegeojson
andturf
stuff. 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-java
and 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.