I was happy discovering the map component and gladly added it to my project. Unfortunately I noticed an increased data usage afterwards, so I went digging deeper:
In order of isolating the issue, I created an App Inventor project that contains only the map component without any code (blocks).
Then I monitored the data packets being sent/received by the app using Wireshark.
I then discovered what I had been suspecting:
The Map component is sending HTTP requests to the OpenStreetMaps server, demanding the same tile very frequently. The server then sends the requested tile to the app. This can happen as high as 200-300 times consecutively. This behaviour can also apply to different tiles at the same time. Meanwhile, the map viewport displays correctly, sometimes taking a while loading a tile through the busy connection from the OSM server.
When I drag the map to a different location, the whole procedure repeats, this time with other tiles being affected.
To recap: The map component is requesting the same tile again and again despite already having loaded it from the server correctly.
I haven’t had the opportunity to test on other phones. The problem seems to appear on both the Companion App and the project’s .apk version installed on the phone.
My phone: Sony Xperia Z3 compact, Android 6.0.1
Can someone reproduce this issue? Maybe someone with more technical knowledge can describe the behaviour more accurately.
I hope that this problem will be fixed as the increased data usage deeply affects my monthly data plan.
Thank you in advance!
Greetings
eutill
I haven’t had a chance to confirm this yet, but in normal workflow osmdroid (the library we use for maps on Android) is configured to cache its tiles in the app-private cache directory under osmdroid/tiles. Are the responses you’re seeing HTTP 200s with payloads, or are they HTTP 304 (not modified)? If the latter, than things are probably working okay, but your suggestion that it’s overloading your mobile data suggestions things are not.
I am sorry that I haven't come back to you before.
Now, a year later, I have conducted the same test again on a new phone and on Android 11 and the Map component still shows the same behaviour.
The responses are HTTP 200s with payloads.
Actually, I may refer you to another thread where a developer has also experienced the issue: Unpredictable data usage Map
Is this app-private cache directory supposed to be found in the Internal Storage at Android/data/appinventor.ai_user.appname/cache ? If this is the case, I cannot find it.
EDIT: After some more digging, I found that my test app created this directory (osmdroid/tiles) in the Internal Storage after being granted Storage permission (i.e. NOT at Android/data/etc but at the Internal Storage's (aka SD card) top level)! But from what I can tell, it remains empty and the issue persists. But the map component does have some kind of working cache (maybe at /data/data/app/cache? I cannot verify that, my device isn't rooted).
My suspicion is that osmdroid may be badly configured.
I made a screen recording of the app while it is trying to display affected tiles: Google Drive link. You can clearly see something flickering on the map. What's strange is that it seems to load two different versions of one tile. I made sure to clear the app's cache previously so that it should load all tiles freshly.
Okay, it seems like the flickering is caused by the constant re-loading of the same tile. Weirdly enough, the OSM server serves different versions of the same tile -- try reloading this tile some 10-20 times with your browser (Ctrl + F5): https://tile.openstreetmap.org/10/534/353.png
That's exactly what I noticed.
Today I tested my Map app and found a map location and zoom level where the data consumption was very high (approx. 1MB every 2 seconds) .
Then I turned off all internet access, and I could zoom in- and out without any problem, meaning that the necessary map tiles are nicely buffered.
Data usage zero obviously, until I activate wifi or 4G internet again: Map will start eating 1MB every 2 seconds again on the same buffered Map section.
What surprises me most that this bug seems to be there for more than a year and only 2 designers seem to have noticed the issue...
Until I stumbled over the data-usage issue I was super happy with IA2 and its Map features.
My app uses a lot of the Map features so I can't simply move to another way of addressing OSM or Google Maps.
Maybe because AppInventor is a learning platform for schools, it is being developed with this in mind. In the students' projects, such mistakes do not matter. These errors are mainly noticed by commercial app developers. However, these are bugs that do not interfere with the programming logic, do not crash the application, so I think the repair priority is not high.
Yup, sounds like a solid explanation to me.
Just to be clear: I am not a commercial developer, I just wanted to offer (for free) a highly specialized app to radio amateurs that specialize in Radio Direction Finding.
This was my very first AI2 project, but I managed to build a very nice app that gets data via Bluetooth from the radio direction finders I developed, puts bearing lines on the map, and can exchange bearing lines from and to other, remote RDF-stations via an internet server. And I had a great time building it.
With my lack of experience in coding, I can only give MIT AI2 massive credits for building such a fantastic tool.
I would be so happy if this data issue gets resolved...
Hey Wil,
your use case sounds very interesting to me! I had a short look on your website and it is inspiring! Although being a radio amateur myself, I haven't tried ARDF yet.
I am also very happy that AI2 provides the possibility to people like me who don't want to dive into the whole Android programming ecosystem, but "just" want to develop a working app.
Hi Leonard,
nice to hear you're a Ham as well.
Yes, I've been tweaking RDF-systems over the last 8 years or so.
Still find the technology very interesting, and a radio hunt is always good for a small dose of adrenaline.
Cheers, and happy easter to you!
Wil
Pa8w
