-
Improvement
-
Resolution: Fixed
-
Minor
-
3.9.2
-
-
MOODLE_39_STABLE
-
MOODLE_39_STABLE
-
Moodle App 3.9.3
When you view or download an activity, this results in two types of data being stored in the device:
- Files (these are stored in the filepool_files/filepool_files_links SQLite tables)
- Web service responses (these are stored in the wscache SQLite tables)
The 'Manage storage' screen and associated infrastructure for deleting downloaded content only includes files.
So for example if you view a Forum and some posts and this contains 10 KB of messages, mainly HTML code (retrieved using a web service), and also has a 10 KB image file in one of the posts, this will show as 10 KB in the manage storage screen.
Also if you view a Forum which contains 50 KB of HTML code and no images, even though this is actually bigger, it will not show up at all in the manage storage screen.
It is even more confusing if you click the download cloud icon next to the Forum with no images. In this case, you will see a progress bar, and the cloud icon will change to the 'Downloaded' icon. So you will reasonably assume that it should now show up on the manage storage screen, but it still doesn't.
The key points of confusion are:
- If this doesn't take up any storage space, does this mean I can't use it offline?
- I can use this offline - it must be stored somewhere - how come I can't delete it?
I propose we extend the current APIs so that some web service requests can be marked as 'belonging to' a particular activity, and can be counted in with the total size and also deleted if you delete data for that activity. This will not be a perfect solution as there are obviously going to be web service requests that do not relate to a single activity (for example, maybe some requests get data for everything in the course rather than the single activity) and these would still not be counted, but I hope we can at least make it behave a bit more like users would expect.
Limitations
These limitations relate to existing code (also see MOBILE-3134):
1 For the context menu within an activity, the download size (including the new cache size) is computed when you go into an activity page and is not recomputed if you go into and out of a child page.
For example, if you go into a forum, then open the menu, it might show 2 KB (size of discussion list). If you then go into a discussion, and back out into the forum main page, it will still show 2KB even though you have also loaded the discussion now. However, if you go all the way back to the course page, then re-enter the forum, it will update (e.g. to 3KB or whatever).
It already did this only with images and even worse (see next point) so I don't think it necessarily needs fixing as part of this change.
2 For downloaded files, sometimes if you download a file the size does not update until you refresh the activity/course.
This can be seen using the test script here and is true with the existing app, so I don't think it needs fixing as part of this improvement. The same problem doesn't apply to the newly-added cache size (I didn't make it cache that number).
- blocks
-
MOBILE-3338 Apply component and componentId to WS calls
-
- Closed
-