Fix: Update of generate.dart and its template files. Fixed Offset, Translate and expressions arrays on iOS. #481
Conversation
Added checks in LayerPropertyConverter.swift to correct property values, in cases of arrays and expressions.
|
Thanks for all the namespace/path fixes, I completely missed those in the generator. |
@kuhnroyal On Android everything was fine for line-patharray, but it only accepts expressions and not arrays, when using an array a console error appears with "array not allowed". Do we want to accept only expressions on iOS as well? Currently, with my edits, arrays are also allowed on iOS (I think this must be the correct way also on Android, for a better UX). |
|
@kuhnroyal I did some checking on Android, and well, the bug isn't only on iOS but also on Android. But on Android it doesn't cause a crash, just an error log:
These days I will fix the LayerPropertConverter.java, also applying some optimization fixes, in case I will update you with commits and comments here. |
…n Android. Minor fix on iOS template and generate.dart.
|
Hi guys, any update on this? |
| @@ -65,7 +74,16 @@ static PropertyValue[] interpretSymbolLayerProperties(Object o) { | |||
| properties.add(PropertyFactory.textHaloBlur(expression)); | |||
| break; | |||
| case "text-translate": | |||
| properties.add(PropertyFactory.textTranslate(expression)); | |||
| if (jsonElement.isJsonArray()) { | |||
There was a problem hiding this comment.
Maybe put all this logic into convertJsonToFloatArray to avoid repetition?..
There was a problem hiding this comment.
I actually don't remember why I did this, it was a while ago. Maybe because in some cases the conversion was handled differently, but currently it seems logical to put everything in convertJsonToFloatArray.
Hello, I am currently developing a bike navigation app for a client (RadroutenPlaner Bayern). After publishing the first version of the app, we noticed that the location accuracy on Android was significantly poor when switching to a Following Mode. The location puck updates very slowly and with a noticeable delay, it felt like it was only using coarse location. Upon investigating, I discovered that MapLibre Android uses the FusedLocationProvider by default, which only accepts a balanced location priority. Observing other major navigation apps like Komoot and Outdooractive via logcat, I found that they switch from the native fused provider to the GPS provider when the device enters Following Mode. To address this issue, I added the ability to manipulate the native LocationEngine and LocationEngineRequest in flutter_maplibre. I introduced a property to the MaplibreMap widget called locationEnginePlatforms. This property currently allows you to adjust settings like interval, displacement, and priority (only on Android). I don't have extensive experience with Java and Kotlin, so please let me know if there are any issues or if improvements are needed. Thanks for your feedback!
This pull request includes several changes to the Android project setup and dependencies, as well as some code refactoring in the `GlobalMethodHandler` class. The most important changes are grouped by theme and summarized below: ### Android Project Setup: Upgrade to latest Flutter Gradle plugins configuration: https://docs.flutter.dev/release/breaking-changes/flutter-gradle-plugin-apply ### Dependency Updates: * [`example/pubspec.yaml`](diffhunk://#diff-565b0869896732da3b937c64bc8fd5f0ca37ea1f629d579c29fc70e0f1e3e48eL20-R20): Updated the `path_provider` dependency version from `2.0.15` to `2.1.5`. * Set minimum supported Flutter version to 3.22.0 ### Code Refactoring: * [`maplibre_gl/android/src/main/java/org/maplibre/maplibregl/GlobalMethodHandler.java`](diffhunk://#diff-9c836abc6c8048cf093a291198c86b17f16530e99328202318c54f9fe1c65c40L29-L37): Removed the `registrar` field and related code, updating the constructor and `openTilesDbFile` method to use `flutterAssets` instead. [[1]](diffhunk://#diff-9c836abc6c8048cf093a291198c86b17f16530e99328202318c54f9fe1c65c40L29-L37) [[2]](diffhunk://#diff-9c836abc6c8048cf093a291198c86b17f16530e99328202318c54f9fe1c65c40L155-R149) --------- Co-authored-by: thanhdt-vietmap <[email protected]> Co-authored-by: Joscha <[email protected]>
Head branch was pushed to by a user without write access
Hi guys, this PR aims to solve the #480 issue that I opened recently.
I started by refactoring all template files, used in generate.dart, updating them because they were obsolete (there were still some mapbox references inside).
Next, I fixed some problems with the paths in generate.dart, which were also obsolete.
Testing #480, I realized that the problem wasn't only with the “line-dasharray” property, but with all arrays that were part of a linear expression or that were arrays of doubles (generally numbers).
I introduced some checks in LayerPropertyConverter.swift and now every array or expression, for every property (even on Offset and Translate, which work with the CGVector class), works correctly on the iOS platform.