Refactored location sharing timeline items to use the mapserver configured by the wellknown file

[artkoenig]

Type of change

• [x] Feature
• [ ] Bugfix
• [x] Technical
• [ ] Other :

Content

The map server configuration (style.json), provided by the wellknown file, should be used for all use-cases, showing locations on a map.

Motivation and context

The map configuration (style.json), provided by the wellknown is not used for displaying the location in the timeline. Currently the Maptiler static map API is used for this, which is loading map data from the other source. This is problematic, due to copyright and/or network limitations, which may prohibit the use of map sources other than specified in the wellknown file.

This PR also removes the static attribution string, hard-coded in the app. The attribution should be defined in the style.json file to match the used data source.

Tested devices

• [x] Physical
• [x] Emulator
• OS version(s): API 21, API 33

Signed-off-by: Artjom König [email protected]

[Johennes]

My understanding was that we previously decided not to use the dynamic maps because of poor performance in the timeline. Have we falsified this concern?

[artkoenig]

@Johennes to favor performance over functional correctness is IMO problematic. The new solution is slower and more memory consuming (here some tests results for scrolling a timeline full with location events):

Old:

New:

And also network performance (for one location event in the timeline): Old:

New:

But

• The Web-Client and the iOS-Client already use the dynamic maps in the timeline - for the sake of consistency, the Android-App should have the same behavior
• The solution has to respect the customer's mapstyle settings. As I stated above - in the enterprise setup, there are copyright- and network access limitations (due to security considerations) which prevent using other than specified map servers
• Even with the worst case scenario (timeline is full with location events), the performance impact is not so bad that you could not use the solution

[Johennes]

Thanks for compiling the performance data @artkoenig. The CPU activity does look quite a bit inflated, sadly. Seems like a factor of 5 in the peaks. 😞

I think it's reasonable to allow forks to use the vector maps with style.json if they can accept the performance overhead. I don't think we should force this onto all FOSS users though, especially since with the default style.json there seem to be little to no differences between the static and the vector maps.

What seems better to me is to add support for both variants to the well-known file and let clients pick (which coincidentally is what we already had planned here).

WDYT?

[bmarty]

Thanks for the PR. If I am correct it is addressing this comment?

[artkoenig]

@bmarty actually not

@Johennes after an internal discussion, we decided to implement this internally due to time constraints. I will adjust the implementation to keep the differences to FOSS as minimal as possible to avoid merge conflicts. We will wait until you provide an official solution for configuring the static map API via the well-known. Feel free to close the PR or postpone it for later use.

[Johennes]

Here's a screen recording of scrolling through a room with multiple location tiles on a Nokia 5.4 with a build from this PR:

https://user-images.githubusercontent.com/1137962/210792583-254c93e2-06c3-4228-b080-ebef38924469.mp4

And here is a recording of the same action on the current store version of the app:

https://user-images.githubusercontent.com/1137962/210793205-7297e767-0859-4437-b73d-f14c17c51ea2.mp4

Unfortunately, the scrolling experience is quite poor with the vector maps compared to the static images.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}