store tiles on SD card

Bug #579377 reported by Kieran Fleming
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenSatNav
Fix Released
Medium
Unassigned

Bug Description

Space is very limited in device memory, we should use the SD card if available

Revision history for this message
chris_debian (cjhandrew) wrote :

Chris asked the OSN-Team list for thoughts about SD card storage. It was suggested that we need to ask the user how much space they are prepared to use.

Guillaume summarised by saying:

I share your opinion, a slidebar from 0 to max size of SD card is the
way to go. We need a prefs screen for these settings.

Revision history for this message
chris_debian (cjhandrew) wrote :

Guillaume,

Following your good work with the _About_ screen, would it be possible for you to re-use that code and possibly prepare an initial offering for this new screen? I don't mean for you to address the whole Issue, but the prefs screen if possible.

What do you think?

Chris.

Revision history for this message
Guillaume Rosaire (zerog) wrote :

My part is done, can be reassigned

Revision history for this message
chris_debian (cjhandrew) wrote :

Kizza,

If you get a minute, would it be possible for you to look at this? We really could do with more coders, to help share the load.

Chris.

Revision history for this message
Kieran Fleming (kieran-fleming) wrote :

Rev 46: Working now, except for the preferences

Revision history for this message
chris_debian (cjhandrew) wrote :

ZeroG,

As per

http://www.opensatnav.org/issues/show/8#note-3

Could you possibly help with the Preferences? If you can't, just say.

Thanks,

Chris.

Revision history for this message
Guillaume Rosaire (zerog) wrote :

kizza wrote:
> Rev 46: Working now, except for the preferences

Could you (Kizza) please tell me what you need to have the preferences working?

If the tiles path is defined on the SD Card, I can have the Clear button work.

The chosen size in the preferences screen is in
<pre><code class="java">
  // Restore preferences
  SharedPreferences settings = getSharedPreferences(OpenSatNavConstants.PREFS_FILE, 0);
  int maxSize = settings.getInt("maxSdCardUsageMb", 0); // 0: default value if unset
</code></pre>
I think that would be easier for kizza to do the work on this max SD usage thing. If he can't, I could have a look at it.

Revision history for this message
Guillaume Rosaire (zerog) wrote :

Well, I'm not sure that the value is really saved to a prefs file whene using the preference SD usage slider, I'll have a look at my preferences implementation to understand where it's saved (not sure it is at the moment)

Revision history for this message
Guillaume Rosaire (zerog) wrote :

ZeroG wrote:
> Well, I'm not sure that the value is really saved to a prefs file whene using the preference SD usage slider, I'll have a look at my preferences implementation to understand where it's saved (not sure it is at the moment)

To retrieve the value set in the preferences screen, you must do :
<pre><code class="java">
   PreferencesManager.getDefaultSharedPreferences();
   int maxSize = settings.getInt("maxSdCardUsageMb", 0); // 0: default value if unset, must be changed to whatever you want
</code></pre>

Revision history for this message
Guillaume Rosaire (zerog) wrote :

Well, it was already done in the project code by Kizza. So could you please tell me what's not working ?

Revision history for this message
chris_debian (cjhandrew) wrote :

My understanding is that the Preferences need some help

http://www.opensatnav.org/issues/show/8#note-9

If this isn't the case, please ignore me.

Not sure what else needs to be done here.

Chris.

Revision history for this message
Kieran Fleming (kieran-fleming) wrote :

Got some more bits working. The code in SDCardUsagePreference.java to work out the default value was never being run because the default was always set beforehand by the code mentioned above.

Revision history for this message
chris_debian (cjhandrew) wrote :

kizza wrote:
> Got some more bits working. The code in SDCardUsagePreference.java to work out the default value was never being run because the default was always set beforehand by the code mentioned above.

That should help :-)

Revision history for this message
chris_debian (cjhandrew) wrote :

Guys,

Looks like you've done a lot of work on this. Do we know what needs to be done next?

Cheers,

Chris.

Revision history for this message
chris_debian (cjhandrew) wrote :

ZeroG,

I think Kizza has got quite a lot of work assigned to him at the moment. Would it be possible to see if you can do anything to help with this issue?

Cheers,

Chris.

Revision history for this message
Kieran Fleming (kieran-fleming) wrote :

I'm happy doing this, it's just taking a bit linger than I thought. It seems like in order to tell the Tile Provider about the new size setting I have to send an explicit Intent for it. Can anyone tell me if this is the right idea?

Revision history for this message
chris_debian (cjhandrew) wrote :

Wulli,

As a new pair of eyes, do you have any thoughts about Kieran's last comment?

Chris.

Revision history for this message
chris_debian (cjhandrew) wrote :

*Wulli should read Willu. Sorry, Willu! I had a colleague called Wulli and I got confused :-)

Cheers,

Chris.

Revision history for this message
Will Uther (willu-mailinglists) wrote :

I haven't looked at the code that deals with the prefs. The code that deletes tiles when the high-water mark of usage is reached looked the same as the OSMdroid code, so that should be ok.

I'm a bit suspicious of the code that empties the cache, but I wasn't sure that there was actually a way to trigger that anyway.

I'm new to Android, so I don't know the best way to achieve this. My thought would be that you'd have a database on the phone that you'd write the prefs into. Then you'd have have the tile caching code re-read that preference each time it stores a tile. That would then wait until you'd moved the map before trimming the data stored though.

Oh, there are a few other issues here. My understanding of the data size stored in the database by the FSTileProvider is that it is the size of the tile in bytes. But the sdcard is going to be formatted with some block size and all sizes are going to have be to rounded up to the nearest multiple of blocksize when stored on the sdcard. This means that the sizes selected in the prefs will be quite different to the amount of space taken up on the sdcard.

One more thing.... I have a 16G sd card. I want to allocate about 1G of space to the cache (including wasted formatting space - so about 2-300M on the slider). That is really hard to select on the slider. I think I'd prefer a different widget. Even text entry would be better.

Revision history for this message
chris_debian (cjhandrew) wrote :

Hi, Kieran.

Just noticed that this Issue is assigned to you. Is this still the best course of action?

Cheers,

Chris.

Revision history for this message
Kieran Fleming (kieran-fleming) wrote :

OK, revision 91 gets pretty good preference support working. Here are some notes:
* Requires a new translation - the line is, "Are you sure you want to clear the map tile cache?"
* Only clears files, not folders. Even after you clear the cache there will be traces of where you have been.
* There was a bug where the formatted file name was stored in the DB even if the SD card was used. The bug has been fixed but tiles that have been stored in this way need to be deleted manually. To start from scratch delete the files on the SD card then use the 'Delete Data' option in the Application preferences.
* If you change the MB allocation using the text field you have to press enter to update the preference.
* Moving the slider changes the allocation immediately. This has always happened, I have just changed the buttons from OK/Cancel to Close so the user knows.

I think the only problem that needs fixing for version 0.9 is the text field one. Willu, can you see if you can fix this?

Of course, if anyone wants to fix any of the other problems they are more than welcome ;)

Revision history for this message
chris_debian (cjhandrew) wrote :

kizza wrote:
> OK, revision 91 gets pretty good preference support working. Here are some notes:
> * Requires a new translation - the line is, "Are you sure you want to clear the map tile cache?"
> * Only clears files, not folders. Even after you clear the cache there will be traces of where you have been.
> * There was a bug where the formatted file name was stored in the DB even if the SD card was used. The bug has been fixed but tiles that have been stored in this way need to be deleted manually. To start from scratch delete the files on the SD card then use the 'Delete Data' option in the Application preferences.
> * If you change the MB allocation using the text field you have to press enter to update the preference.
> * Moving the slider changes the allocation immediately. This has always happened, I have just changed the buttons from OK/Cancel to Close so the user knows.
>
> I think the only problem that needs fixing for version 0.9 is the text field one. Willu, can you see if you can fix this?
>
> Of course, if anyone wants to fix any of the other problems they are more than welcome ;)

Nice progress Kieran. Thanks very much.

Chris.

Revision history for this message
Kieran Fleming (kieran-fleming) wrote :

Fixed the 4th bullet point from above in revision 95.

Is everyone happy about closing this bug for 0.9 and moving the remaining issues to later releases? Remember that 0.9 is still a beta release ;)

Revision history for this message
chris_debian (cjhandrew) wrote :

kizza wrote:
> Fixed the 4th bullet point from above in revision 95.
>
> Is everyone happy about closing this bug for 0.9 and moving the remaining issues to later releases? Remember that 0.9 is still a beta release ;)

Kizza,

I'm happy with that. Sound like good ideas. Anyone got preferences for revised releases for the extant issues?

Chris.

Revision history for this message
Guillaume Rosaire (zerog) wrote :

kizza wrote:
> Fixed the 4th bullet point from above in revision 95.
>
> Is everyone happy about closing this bug for 0.9 and moving the remaining issues to later releases? Remember that 0.9 is still a beta release ;)

Can this bug be closed after the last commit (95) ?

Revision history for this message
Kieran Fleming (kieran-fleming) wrote :

Yep, closing this one

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.