Redesign the way MapViews are created to add support for MapLibre. #38
Conversation
alejandrocalles
requested review from
violoncelloCH,
Greenade,
srsingh04,
octogradiste,
ntissieres and
unglazedstamp
alejandrocalles
force-pushed
the
feature/map-composable
branch
from
17ef32f
to
f577bc4
Compare
|
This should also close #40. Adding support for markers has been done for |
|
from a quick search how to draw on the map, I found this: https://maplibre.org/maplibre-native/docs/book/android/annotation-guide.html |
|
Yes, that's exactly it. It's tagged as deprecated in the source code. Specifically the function |
alejandrocalles
force-pushed
the
feature/map-composable
branch
2 times, most recently
from
c24a0f9
to
712af94
Compare
|
I did some more research, and the If you click on any of the classes in the package, they suggest using the Mapbox annotation plugin, which hasn't been updated in 4 years (unless I'm misinterpreting something), and is in a repository that was archived last year. I'll try to get it to work using the deprecated features first, and if that fails I'll try out the plugin. I'm adding these links for future reference: |
| override fun update(view: MapView, events: List<Event>, callback: (Event) -> Unit) { | ||
| mapView.apply { drawAllMarkers(events, callback) } | ||
| } |
There was a problem hiding this comment.
Here, the view param is actually not used.
In this case view will be equal to the mapView variable, but what about using the view parameter directly, or if it isn't necessary simply remove the unused parameter from the function.
What do you think ?
There was a problem hiding this comment.
Thanks for catching this! In principle, the AndroidView is responsible for passing the View instance to the update function, so it's the parameter that should be used in this case.
In fact, the very existence of the mapView field is questionable, but I haven't found a better way to properly test my code...
| * activity, or the [LocalContext][androidx.compose.ui.platform.LocalContext]`.current` if it is | ||
| * called from a composable. | ||
| */ | ||
| open class OsmdroidMapViewProvider( |
There was a problem hiding this comment.
Why specifically make the class open, should this class be further extended later ?
There was a problem hiding this comment.
It should not :) I'll remove it. Thanks again for catching this!
The open modifier is a remnant of an attempt I made to test this class. I wanted to access the mapView field without making it public, so I created a mock class that inherited from OsmdroidMapViewProvider. In the end I simply added getters for the relevant fields of the mapView.
| mapViewFactory: (Context) -> MapView = { createMapView(it, TileSourceFactory.MAPNIK) }, | ||
| update: (MapView) -> Unit = { updateMapView(it, LAUSANNE_GEO_POINT) } | ||
| context: Context, | ||
| events: MutableState<List<Event>>, |
There was a problem hiding this comment.
I saw that the events param is expected to be a MutableState<...>. I was wondering why not simply take a List<Event> here? So that outside of the MapDrawer, it is possible to instantiate the list as val myEvents by remember { mutableStateOf(emptyList<Event>()) }. And then simply pass the myEvents to the composable, it would prevent the need to call the .value when updating the list outside.
I haven't done the test myself, would it prevent the MapDrawer from recomposing ?
There was a problem hiding this comment.
No, you''re right. I had my doubts about whether the AndroidView would be properly recomposed without the MutableState, but it seems to work just fine. Thanks!
alejandrocalles
force-pushed
the
feature/map-composable
branch
from
56db00b
to
8470593
Compare
alejandrocalles
force-pushed
the
feature/map-composable
branch
from
6d58145
to
a150545
Compare
Add the `IMapViewProvider` interface. Modify `MapDrawer` to take an instance of `IMapViewProvider` as an argument. The provider is in charge of defining the `factory` and `update` functions. Implement `OsmdroidMapViewProvider` to replicate the previous functionality with the new `MapDrawer`. Adapt the tests accordingly.
Now the `osmdroid` provider can receive a list of `Event`s as an argument and it will draw a marker at each `Event.location`. The provider also accepts a callback function that wil be called with the respective `Event` object whenever a marker is clicked.
Add the `EchoAndroidView` composable. It is just a wrapper around an `AndroidView` but it improves readability. Change the signature of the `update` method in `IMapViewProvider` to take advantage of the way `AndroidView`s work (the `factory` function is only called when the view is created, and the `update` function is called both when the view is created and anytime the `AndroidView` is recomposed). Adapt the `update` function and the constructor in `OsmdroidMapViewProvider` to comply with interface changes. Improve the `MapDrawer` signature to to take a context instead of a provider to facilitate usage. Add documentation for relevant classes/composables.
Add the `toLatLng` method to get the `LatLng` representation of a `Location`.
Remove the `context` as a parameter of the constructor. The initialization of the `osmdroid` `Configuration` is now done in the `factory` function. Adapt the `MapDrawer` signature to no longer take the context as an argument. Address the errors pointed out by David.
A new provider that uses the `MapLibre` library. Add support for `MapLibre` markers using a deprecated API. Add the necessary dependencies and resources.
alejandrocalles
force-pushed
the
feature/map-composable
branch
from
a150545
to
eda0428
Compare
|
Will close #34. The objective is to abstract the way
MapViews are provided in order to be able to choose freely betweenosmdroidandMapLibreview providers.Ideally, support for markers will also be added for both
osmdroidandMapLibre.