Storage API inconsistency between mobile apps

[Jiminy Panoz]

Unless I’m missing something, it looks like the Storage API (sessionStorage, localStorage) is not enabled in the Android app, while it is in the iOS app.

As far as I can remember, it has to be set (opt-in) for Android web views while it is automatically enabled (opt-out) for iOS web views, and the method which should be used is webSettings.setDatabaseEnabled(true) (cf. the Android Reference).

Problem is, the Storage API is quite a MUST if you have quizzes or more general stuff for which you must store and retrieve values at a later time, and this inconsistency may create compatibility issues between the 2 apps.

So it would be great to have some consistency there, the alternative being IndexedDB, which can be very slow and tricky to deal with on less capable Android devices.

Or maybe it is already and I’m missing something? But even simple tests are failing for me right now.

[bdugas]

@JayPanoz thanks, you are correct and we've added a story to our backlog. This use case hadn't been considered recently until now. We already have examples of files that would benefit but any information you have on how widely used this is will be attached to the story.

[Jiminy Panoz]

Well, it’s hard to get a precise idea but it is one of those small and simple APIs that you end up using a lot in some cases, and can eventually help when building widgets, libraries, etc. and improve the UX.

Off the top of my head:

• storing a list of quizzes/games which have already been done so that it doesn’t reset every time you open the publication;
• storing a list of values for a checklist so that you can automatically save the progress;
• saving a drawing in a canvas – although this is a little bit of a hack as it can only store strings and you must base64-encode it on the fly… but when you’ve got nothing else, it does the job;
• saving the current position in an overflowing element since mishandling can happen (turning the page accidentally, which loads a new resource and resets the state of the current one);
• saving the origin of a redirection to easily get back to the previous page if needed – yeah I know there’s a “previous button” in the bottom left corner but sometimes it takes years for users to discover it;
• more generally saving any information you’ll retrieve later, which can go from practical things like the examples above, to technical things like storing the results of a feature detect requiring to create an element, test its styles and remove it, which will cause a repaint (there are obviously different strategies to deal with upgrades or invalidate those results whenever needed there).

[mrbbp]

The storage API does not work on eink kobo too. Software 4.20... kepub extension