Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Handling Device Low Disk Storage #435
This is actually kind of a feature request. I am observing below exception on an emulator, but it could well be on a real world device and I wonder, if osmdroid could do some checking of free memory or at least cleanup, when below the exception occurs:
#448 related issue
and roger this. Great idea. What should the expected behavior be then?
Maybe on start up, set the cache max size to the current size + free disk space. This should force the trim mechanism however this is only triggered on application startup. As such, we should probably do some trickery to have the vacuum functions run periodically. It should be quick enough to attach to every tile insert event.
added a commit
Oct 21, 2016
referenced this issue
Oct 21, 2016
changed the title from
Handling Device Low Storage Memory
Handling Device Low Disk Storage
Oct 22, 2016
I had a glance at the code and it seems, that it is trying to do some async database cleaning on startup and on exception?! Vacuum still commented out. But looks like a step in the right direction.
I need to merge this into my (local) branch for unclear fixes of #411 and then build it into my product. I will keep you posted.
The vacuum command apparently isn;t supported by sqlite. But basically on start up, it will purge expired tiles, which may or may not be desirable. The old tile system writer did the same task on startup so i just mirrored the logic. Now i'm thinking the logic may be wrong.
On low disk space it will trim, also on every insert, it will check the database size and trim if needed. I also added a bit of code to auto resize the max database size based on the available free space on the storage media.
From what I've seen, yes. But it may vary by android version
On Oct 29, 2016 6:04 AM, "InI4" firstname.lastname@example.org wrote:
Spontaneous question: Does a trim without vaccum shrink the database file
Reply to this email directly, view it on GitHub