Skip to content
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

Add coverage on map #470

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add coverage on map #470

wants to merge 1 commit into from

Conversation

sim6
Copy link

@sim6 sim6 commented Jan 30, 2025

No description provided.

@sim6 sim6 force-pushed the add-coverage-map branch from b4f0f4d to aea9e61 Compare January 30, 2025 22:50
@sim6 sim6 changed the title Add coverage map Add coverage on map Jan 30, 2025
@sim6 sim6 mentioned this pull request Jan 30, 2025
@sim6 sim6 marked this pull request as draft January 31, 2025 09:43
@sim6 sim6 force-pushed the add-coverage-map branch from aea9e61 to d2db4c5 Compare January 31, 2025 10:12
@sim6 sim6 marked this pull request as ready for review January 31, 2025 10:13
@sim6 sim6 force-pushed the add-coverage-map branch from d2db4c5 to e833de1 Compare January 31, 2025 10:19
Copy link
Owner

@mjaakko mjaakko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks! This should improve UX for BeaconDB contributors :)

We might have to rethink in the future where the map layers are configured (in the settings or on the map screen), but this is good enough for now

mapStyle.value!!.styleJson != null && map.style!!.json != mapStyle.value!!.styleJson
)
) {
map.setStyle(styleBuilder(mapStyle, getCoverageParams()))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to also check if the coverage params have changed here. Otherwise if the coverage params have changed, the coverage won't be shown unless the map style has also changed

Yeah, it's kind of an edge case and doesn't really happen in practice, but it's better to handle it now

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I change the settings and I back to the map the map also changed.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's because it's very likely that the map screen will recompose after switching tabs and the factory method will run again. But it's not guaranteed that it will recompose

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -279,6 +288,36 @@ fun MapScreen(mapViewModel: MapViewModel = viewModel()) {
}
}

private fun styleBuilder(mapStyle: State<MapViewModel.MapStyle?>, coverageParams: CoverageParams): Style.Builder {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also thinking about this, maybe it would be better to add the TileJSON layer independently from the map style?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not know how to add the layer without org.maplibre.android.maps.Style. Could you give me a hint?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean you need the style, but you don't have to set the base style (meaning the background map layer) and the TileJSON coverage layer at the same time. You could use getStyle() to get the base style and then add the coverage layer using that. Or do something similar like what is done with the hexagon layer

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


data class CoverageParams(
val tileJson: String?,
val layerId: String?,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this layer ID necessary? From UX perspective it might be kind of confusing, especially for non-technical users. I think we can just use all layers specified in the TileJSON?

Copy link
Author

@sim6 sim6 Feb 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Layer ID should be used as source layer to render it. I will change the code to parse it from the TileJSON.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would definitely make it more usable 👍 Maybe we can add all layers from the TileJSON? Then in the future if there are multiple layers (e.g. different ones for Wi-Fi coverage and cell tower coverage), they would work without changes

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sim6 sim6 force-pushed the add-coverage-map branch from e833de1 to ba63cd7 Compare February 7, 2025 12:39
@sim6
Copy link
Author

sim6 commented Feb 7, 2025

I reworked it, please take another look.

@sim6 sim6 requested a review from mjaakko February 7, 2025 12:41
@sim6 sim6 force-pushed the add-coverage-map branch from ba63cd7 to 65e800d Compare February 7, 2025 13:14
@@ -284,6 +300,43 @@ fun MapScreen(mapViewModel: MapViewModel = viewModel()) {
}
}

private fun addCoverageLayer(style: Style, tileJson: String) {
getTileJsonLayerIds(tileJson) { layerIds ->
Handler(Looper.getMainLooper()).post {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This Handler feels a little bit awkward here. I think it would be better to load the layer IDs with coroutines in the view model and then just add them to the style here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I done it.

@@ -50,6 +51,7 @@ fun SettingsScreen() {
GeosubmitEndpointSettings()
AutoUploadToggle()
DbPruneSettings()
CoverageLayerSettings()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this should be placed directly below the endpoint configuration

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fun getTileJsonLayerIds(tileJson: String, callback: (List<String>) -> Unit) {
val layerIds = mutableListOf<String>()

OkHttpClient().newCall(Request.Builder().url(tileJson).build()).enqueue(object : Callback {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An existing OkHttpClient instance should be reused here so that we can benefit from caching and connection pooling. In MapViewModel it's available from httpClient.value.

Also coroutines could be used here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reused it.


OkHttpClient().newCall(Request.Builder().url(tileJson).build()).enqueue(object : Callback {
override fun onFailure(call: Call, e: IOException) {
Log.e("Network", "Request failed: ${e.message}")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use Timber for logging

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Owner

@mjaakko mjaakko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a couple more comments. If it feels like too much work to refactor this to use coroutines, it's ok to keep it as it is - I'm going to do some refactoring anyway so I can fix it then

But if you could fix the other things I commented on, then we're ready to merge this 🙂

@sim6 sim6 force-pushed the add-coverage-map branch from 65e800d to a6077a2 Compare February 7, 2025 15:52
@sim6
Copy link
Author

sim6 commented Feb 7, 2025

@sim6 sim6 force-pushed the add-coverage-map branch 4 times, most recently from 2e214c0 to 9de8dab Compare February 7, 2025 18:28
@sim6
Copy link
Author

sim6 commented Feb 7, 2025

@sim6 sim6 force-pushed the add-coverage-map branch from 9de8dab to 7b45e2b Compare February 7, 2025 19:09
@sim6
Copy link
Author

sim6 commented Feb 7, 2025

Signed-off-by: Simó Albert i Beltran <sim6@probeta.net>
@sim6 sim6 force-pushed the add-coverage-map branch from 7b45e2b to 214cb90 Compare February 7, 2025 19:12
@sim6
Copy link
Author

sim6 commented Feb 7, 2025

@sim6 sim6 requested a review from mjaakko February 7, 2025 20:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants