Current status 11/28:
Thank you Steve, (and Evan)
In the mean time I tested the Map component in Kodular and in Niotron.
Both show exactly the same reload issues, so there must be a common cause.
Good to see that Evan already reported the issue on april 6.
Hope it will be cured soon!
On april 5 Evan suggested that it may be a fault in osmdroid.
I found the following issue in osmdroid dated jan 23,2020 describing similar behavior:
Just re-built my Map-App to see if the tile-reload issue has been resolved, but no found improvement whatsoever.
Don't know if I should be hopeful or dissapointed...
Hi @ all,
i tested my app today without wifi and ran into the same problem.
Is there any progress in that topic?
Or is the only recommendation to use the OSM through webview?
That would be really bad for me, need to change all my runtime Marker stuff...
Greetings, Rudi from Germany
Welcome Rudi.
Explain the problem? No problem using WIFI; using Data an issue?
You can read the issue ticket
Evan at MIT believes the problem Wil describes is an unsolved OSM api issue. Sorry, MIT can only work with the api; they can't fix it.
-
OSM through a WebViewer is a possibility . Since the issue is an OSM problem that use of OSM might not solve your issue, whatever that is. An example showing how to use OSM without the Map Component. If this 'solution' works for you, please let us know and provide an example. Thank you.
-
A way to ameliorate tile reload issues might be to use cached tiles with WIFI and Data turned off Offline osm Map - #2 by SteveJG .
-
An possibly better alternative to OSM tile issues is not to use the Map component. Instead use the Google Map API using a Static Map or a Java Map, the Web component and structure your code by constructing a url as described in numerous posts in the community and original App Inventor Google Forum.
If you can send us an example AIA with the map set to replicate the issue this is most helpful, since we can compare it to known tiles that cause or don't cause issues.
Moving to OSM or Google maps throuh a webviewer is not an option for my application.
I was charmed by the all the features the MIT Map component offers and I used a lot of them in my Radio Direction Finding app 1.5 years ago when I stumbled over this problem that the app sometimes uses more than 1Mb per second(!) of my mobile data bundle.
And when I dropped the problem here it turned out that the issue was already reported by Eutill a year earlier .
I realize and respect that this may be a tricky problem, but I think it's about time MIT provides some form of clarity:
1, They can and will solve the problem soon, or:
2, They simply can't solve the problem in which case I think a warning should be issued to all students/users that -in all ignorance- might use the Map Component and discover the problem only after their data bundle has evaporated.
1 Like
Thanks for your fast answers 
I think the Problem is shown and explained already a lot. If someone didn´t believe here is the simply AIA witch also have the Problem (maybe related to the Centre area). Start the app, and check mobile or Wifi data usage after a minute. Its downloading the whole time without moving the map.
map_issue.aia (1.1 KB)
The main issue is that your mobile data bundle will evaporated after some hours.
Of course it doesn't matter if you are connected to wifi. But i think the most time you need the map component is in some mobile (not Wifi) environment.
The Map Component has really nice features. But it is not applicable for mobile use.
I also understand that the Problem comes from OSM not from MIT.
So in my Case i have to switch to some alternative Map component.
I need to checkout the possibility of markers and map features for the Webview options. But i think i will use some Paid extension. like this: GmapsPro
And i agree with pa8w:
2, They simply can't solve the problem in which case I think a warning should be issued to all students/users that -in all ignorance- might use the Map Component and discover the problem only after their data bundle has evaporated.
Greetings, Rudi
Still unsolved unfortunately.
@ewpatton : Did you dive into the link I posted here:
They seem to have solved a similar issue.
Thanks,
Wil
Hi Evan,
Can you please speak out if there's any chance of a fix for the frequent tile reload in the Map function?
Kind regards,
Wil.
Ok, if the Map tile reloading issue can't be solved, would a workaround be possible?
In a way that the loading of tiles can be disabled / enabled, with all other functionalities left functional?
I don't see a way to do that in the current Map settings but I would be glad if I overlooked something useful...
Anyone?
I think internally we might be able to switch osmdroid from using sqlite as a cache to using the file system. My hypothesis is that the tiles that are getting frequently reloaded are larger than the 2 MB cursor window limit, so they fail to get written to sqlite and constantly refreshed (which fails to write, ad infinitum). I've allocated some time on my schedule tomorrow to build a version of App Inventor with this change to see if it alleviates the problem.
I have figured out a way to swap the tile cache to one in the filesystem rather than in an sqlite database. By default, osmdroid uses a sqlite database on Android 3.0 and later, but as I mentioned in my last post I think certain tiles fail to be persisted there.
Here's a test server with corresponding companion available via the Help > Companion Information dialog. I did not set up a build server, but the idea is if you don't see significant usage in the companion you wouldn't see it in compiled apps either.
Seems to work!
I've used datatest.aia which I previously shared in this thread, and used my previous (Android 10) Samsung phone and Companion to follow your suggestion:
Tiles load fairy fast and after a few seconds, data usage drops to zero.
Looks a bit sluggish using companion but still it behaves fine.
Seems like you nailed it Evan!
Are you going to implement this solution in the normal companion- and build server?
Thanks so far!
Wil.
Yes, I will submit a pull request for the team to review for the next release.
Excellent, any idea when that next release can be expected?
I will discuss this with the team. At the latest it will be sometime this summer, but I expect we will do at least one before then.
The bugfix is now available on ai2-test.appinventor.mit.edu as part of our testing for our next release.
Great job Evan!
The Map reload issues are solved, and all other functions of my app are working like a charm,
(BT client, Web, TinydB, locationsensor, clocks)
Congratulations and a big thank you to all that helped solving this issue!