Tile caching not working

[android-coder]

Hi everyone,

I'm using the new 0.3.0 version and I can't seem to get tile caching to work.  Regardless of what I've tried, each time the map starts out blank and the tiles are slowly generated.  Here is the relatively simple code I'm using:

    @Override

    public void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        mapView = new MapView(this);

        mapView.setClickable(true);

        mapView.setBuiltInZoomControls(true);

        

        FileOpenResult fileOpenResult = mapView.setMapFile(new File("/sdcard/berlin.map"));

if (!fileOpenResult.isSuccess()) {

Toast.makeText(this, fileOpenResult.getErrorMessage(), Toast.LENGTH_LONG).show();

finish();

}

        TileCache fileSystemTileCache = mapView.getFileSystemTileCache();

        fileSystemTileCache.setPersistent(true);

        fileSystemTileCache.setCapacity(10000);

setContentView(mapView);

    }

Does anyone have an idea what I might be doing wrong?

[Thilo Mühlberg]

Just by staring at your code, i cannot find any obvious mistake. You can
support us in the debugging process by taking a look at the cache
directory on your device's SD card. Are there many *.tile files after
you have closed the application? There should also be a .ser file which
stores the serialized data of the internal cache map. If these files do
not exist, all tiles must be re-rendered at the next application start.

For the record: cache persistence is known to result in cut-off labels
on the map, see issue #20 for more details about this problem.

Greetings,
Thilo

[android-coder]

Hi Thilo,

Thanks very much for replying.  I've just checked the SD card, and I've had a look in:

/sdcard/Android/data/org.mapsforge.android.maps/cache

and regardless of whether I'm in the app or I've quit it, there is only one directory in there named "1" with nothing in it.  So I suspect that any caching that's going on while the app is running is simply in memory and it's not writing anything to disk.  

Do you know what might be causing this?

[android-coder]

Does anyone have an idea?  The SD card on the simulator (and on real devices for that matter) have plenty of room and are able to create the directory structure to the point I mentioned in the post below, so I don't think it's a permissions issue.  Could there be any other reason that the tiles are not being saved to disk?

[Thilo Mühlberg]

I just did a quick check using the latest development version from our
SVN repository but i could not find any errors. When i left the AMV
without explicitly closing it, i could find all the .tile files in the
cache directory as expected. After closing the AMV, all files were
deleted properly.

I even did a quick check with enabled cache persistence, that work also
normally. After closing the application, all tile files remained in the
cache directory and the map appeared immediately after i restarted the
AMV. Can you please retry by using the latest SVN version as well?

Greeetings,
Thilo

[android-coder]

Thanks again for your help Thilo.  

I did as you asked and checked out the source rather than just using the jar so I could debug it myself.  The following bit of code is what was killing me:

private static int getCapacity(int capacity) {

if (capacity < 0) {

throw new IllegalArgumentException("capacity must not be negative: " + capacity);

} else if (AndroidUtils.applicationRunsOnAndroidEmulator()) {

return 0;

}

return capacity;

}

Check out the "else if" part - caching cannot work on the simulator because of this!  Why was this added?  If I comment out the "return 0" everything works fine.  In my experience, it's never good to have switches that make the app work one way on a simulator/in debug mode/on a particular architecture and different on another.  If this behavior is required for the simulator, then it should be specified in a config file so it's clear what is happening. Also, if this is expected behavior, it should at very least be documented somewhere!

Anyway, after that bit was figured out the .tile files began to be generated, however every time I would launch the app, the cached files still weren't being displayed.  After a bit more investigation, I found that the SERIALIZATION_FILE_NAME (cache.ser in this case) is needed before the tiles can be written, and this file is only written once the object is destroyed, which for all intents and purposes means when the app quits.  However, while debugging, most users, on an emulator or the device, probably won't exit gracefully (they'll just kill the app in the debugger, or start a new debugging session) and as such this method would never be called and caching would not work.  This was the case for me anyway when I was running it on a real device and it seemed not to be working.

So anyway, by commenting out the "return 0" and ensuring a properly exit the app each time now I seem to have map caching going.  If you know why the clause disabling caching for the emulator was added, I'd be very interested to know.  

[Thilo Mühlberg]

Ahhh, now i understand the problem. When i read your first email, i
thought that you had this problem also on real devices, so i didn't even
think about that issue. The "emulator-hack" was added at some time in
the past to work around an issue with the emulator. Writing to the
emulated SD card caused it to freeze for longer time periods (up to
several minutes) and i couldn't find any better solution for that.

There is even a ticket in the Android issue tracker for that
(http://code.google.com/p/android/issues/detail?id=7327), unfortunately
it is still in the status NEW so i assume that the bug is present even
in the latest release. However, i haven't used the Emulator for quite
some time, maybe the situation has improved meanwhile ...

If you have any idea how the serialization of the cache map could be
improved, i am happy to discuss and implement it. The desired behavior
is that all tiles are re-generated when the cache.ser file could not be
found. Existing .tile files should be deleted when the application
exits, the cache should work normally even if such files are present.

Greetings,
Thilo

[vklein]

Am Sonntag, 17. Juni 2012 19:04:41 UTC+2 schrieb android-coder:

 

Hi,

I report a problem similar to the discussed problem here.

 

I loose all tiles in a preloaded cache if the app crashes cause the device is turned so the map avtivity is restarted.

 

I use the version 0.3.0 with a online nautical map of sweden generated from www.eniro.se and normally everything runs fine.

Thanks to the developers for this excellent piece of software.

 

I get the tiles via a 3g connection. If the signal is weak, sometimes I get the tiles , but sometimes they cannot retrieved, so I get blank parts in the map.

So I download all the tiles with the tile-cache enabled, that cover the expected route in the harbour where I have a good signal strength. . Normally this are 500-700 tiles.

Everthing is fine,

Now I start the trip and maybe there is a tile that I forgot to load in the cache, so the library tries to get it over a weak connection.

 

If the activity is now closed and this may happen when the device is turned, the app crashes.

 

I think, that the problem is a running thread, which handles a tile-download, that is not correctly terminated when the mapview is closed.

I cannot debug this problem, cause the situation depends on the signal qualitiy of the 3g connection.

 

The main problem is , that the cache looses all information about the "good" tiles I downloaded before, cause the cache.ser file is only written when the app is regular terminated.

 

It would help, if there would be a safety-copy of the cache.ser file, which could be retrieved is such cases.

 

Victor

[Stefan Tauner]

On Wed, 25 Jul 2012 02:09:23 -0700 (PDT)
vklein <vk49...@googlemail.com> wrote:

> I cannot debug this problem, cause the situation depends on the signal
> qualitiy of the 3g connection.

you can in the emulator, it allows to play with the available bandwidth
and you can trigger orientation changes as well.

--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner