With Safari no longer supporting Sqlite in web apps I ventured in to indexedDB. What a mongrel that is. I couldn’t get my head around it, so I investigated wrappers and stumbled on JsStore.js. It seems fairly simple, although I haven’t done any complex database functions.
The attached Basic project creates, inserts or updates, reads and clears an indexedDB table using JsStore wrapper. I’m sure there is those on here who could do a lot better than I but this got me going and seems to work on iOS (Haven’t tried iOS15 but understand it is still supported. Although there may be a bug around the loading time when indexdb first starts in v14.6 IndexedDB is completely broken in latest Safari | Hacker News).
Yeah, indexedDB is a mess. I went that way and got it all working and then discovered that indexedDB is subject to “cleanup” just like other app data such as localStorage so I went to the SQLite plugin. Not sure what you PWA folks are supposed to do.
Does that mean clearing cache will delete an indexedDB database? That’s not such a big deal but do you know if it takes up the same ‘space’ as localstorage? More importantly, is this going to fill up the sandboxed limit as much as any localstorage?
When devices are low on storage, iOS specifically but Android as well, perform a set of “garbage collection” processes that free up space by deleting files. First to go is localStorage, indexedDB etc. Not all of these get deleted, they delete starting with the apps that have not been used in a long time and move forward from there until they reach the necessary threshold. If your app is used daily, odds are you’re OK. OTOH, if it’s an app that’s rarely used then you’ll get hammered.
At least that’s been my experience. I once had an old iPhone that I kept very full so I could test when this happened. It happened more than I wanted.
Sql data is cleared in the same manner? Data is uploaded to my server so I’m not too worried about data persistency on the device. It is for storage of data if user is offline when localstorage seemingly max out
Data persistence usually isn’t the issue, it’s the user experience that’s the problem. SQL tables depend on how you store the DB but ours always persisted.
Another possible solution is to the the sql.js library. It’s SQLite compiled to JavaScript. You then include that with your app.
Looking at it and creating a sample is on our To Do list. There doesn’t seem to be anything magic about it: most people here would be capable of making it work.
Incidentally, I hear that IndexDB is implemented using SQLite on all browsers except Chrome. That explains why it’s slower than SQLite, but doesn’t explain why the interface to SQLite should be removed.
My understanding of that option is that it is database in ram and is saved as a string in localstorage. All the sql commands are not exactly the same as sqlite so apps need to be modified fairly seriously too.
Hi there… I found out that the problem is connected to a specific internet provider (WindTre) … they are obscuring the site because their new (marvelous and foolproof ) protection service (unrequested) has decided that the jsstore site is unsafe
) protection service (unrequested) has decided that the jsstore site is unsafe