Persist IndexedDB in cordova app when app updates - javascript

I have an Android app built using Cordova. Version 1, which has been released for a while, stores some data using IndexedDB. I’m ready to release the next version but updating the app wipes all the data stored in IndexedDB.
What I noticed is that on Version 1, it uses cordova-android#^7.0.0 which uses file:// as the security origin (I knew this from the debug tool). Then, on the next version, I upgrade the cordova to cordova-android#^9.0.0. Now, it is using http://localhost as the security origin.
is there a way to migrate all the existing data when the app upgraded?

The only way would have been, in the previous version, to dump JSON data into a local file as a back up, then on the next upgrade, check if the local file is present and load/inject it back to IndexedDB. But it's probably too late now...
I don't see a solution as you are set up right now...

I just upgraded from cordova-android#^8.1.0 to cordova-android#^11.0.0 and had the same issue you described.
I didn't find any solution or question besides this thread.
Just before giving up, I looked at cordova source and logic, and saw that there is a parameter called "AndroidInsecureFileModeEnabled".
I set it to true on the config.xml and it worked!
The app came back to use "file://" as the security origin, so after upgrade the app still logged in.
Later I searched about this param and found some docs about it so it's important to know the insecure impact of setting it to true. For now I don't have any choice but to use it. I hope that it doesn't affect or can break anything else...
Let me know if it helps.
https://cordova.apache.org/docs/en/dev/config_ref/
https://cordova.apache.org/announcements/2021/07/20/cordova-android-10.0.0.html

Related

Are service workers ever removed automatically by the browser?

I've been trying to make PWAs that reliably work offline on and off for the past year, but every time I write a new service worker, it works as expected for a week or two and then just breaks (until reconnecting). I thought it was due to the site's data getting evicted, but the local storage is often intact when I reconnect to the internet so it can load. Recently I also had one of the service workers remain active, but its cache storage was deleted, as well as the other service workers (I've got multiple different sites on the same origin, some of which have service workers. It's my GitHub Pages).
According to the spec, it sounds like service workers should always remain registered unless the data for the whole origin is evicted. I also don't think my service workers are accidentally deleting their caches or unregistering themselves as the issue only happens after not using them for a while, in which case they aren't running. Clearing Chrome for Android's cache also doesn't break the PWAs when offline, so I don't think I'm manually doing anything that's breaking them. Clearing an individual PWA's storage and cache also doesn't break it.
The relevant sentence in the spec:
"A user agent must persistently keep a list of registered service worker registrations unless otherwise they are explicitly unregistered."
(the unregistered service workers also don't show up in chrome://serviceworker-internals/ )
Any ideas? Do you think this is a bug? I've mostly seen this in Chrome for Android, but I think I'll try some other browsers as well to check. Unfortunately I can't test any of this very well as it's quite unpredictable and takes weeks.
These are the 2 main sites to try, as I use the same template for a few, although I don't think it'll be that helpful:
https://hedgehog125.github.io/Bagel-PWA/
https://hedgehog125.github.io/Bagel-V2/ see https://github.com/hedgehog125/SvelteKit-Plugin-Versioned-Worker/blob/main/src/worker.js for the proper service worker template
Thanks for any input
Edit: I thought it would be worth a try to see if that first site still works in Firefox while offline. It does, despite not visiting it in Firefox for maybe 6 months. I guess this is a Chrome bug/feature then?
Edit: Updated the title

Fleek.co image upload not generating hash and hashV0

I was uploading an image using the safari browser, it does not return any ipfs hash.
While on the other hand, it returns the ipfs hash if I am using a desktop web browser.
Can anyone help me with this, or at least explain the process?
EDIT: we noticed you’re using iOS simulator. Based on that, we released 1.0.4 version for #fleekhq/fleek-storage-js that adds a fallback for case sensitive headers https://github.com/FleekHQ/fleek-storage-js/pull/6. Can you try this version to see if it works for you?
Please note that this service is based on Minio and the current authentication is only setup for calls from a server (not a browser for example). This is because it uses API secrets and we don't want to expose them in the browser. Having said that, will take a look at why our Minio fork is not sending the header in those cases (it just hasn't been a priority to replicate because it is not advised to use from browser like that).

Will my apps lose localStorage data if Crosswalk updates it's internal browser?

Recently I adopted cordova's crosswalk plugin to ensure a uniform and performant HTML5 environment across android devices. Everything was working fine until I deploy the application. That's when I noticed that all existing settings from the native browser, which was being used by the cordova webview were gone! Our localStorage was now in a different browser - the chromium browser which is served by crosswalk project.
Now I'm asking myself what will happen if the crosswalk project updates it's internal browser to a new chromium browser version? Will I lose the localStorage data once again?
Here are some references that I had look at while researching into the subject:
Crosswalk storage limits
Scope of sessionStorage and localStorage
Where the sessionStorage and localStorage stored?
Probably yes, you will lose the data. Also updating the device SO can cause the loss of data. I had the same problem. You should consider to use sqlite database to persist permanently your data.
The issue that was concerning this subject was closed last week. "Not able to migrate the existing webview data (localstorage/websql) to crosswalk"
Check it out here: https://crosswalk-project.org/jira/browse/XWALK-7368

Is IndexedDb dependent on cookie?

I am working on a prototype where we need to support offline data modification of web application, the application is expected to sync back the data when an internet connection is restored. I have taken a look at various HTML5 in-browser storage option and indexeddb looked like the one I wanted. But I am not sure if the data will be persisted between browser close. Is that possible? One more question if I delete the cookie of the browser, will data in indexedDb will be wiped out? My initial tests shows data gets deleted on cookie clear of browser.
If indexeddb is not a viable option, are there any other alternatives to it which can persist data when internet connection is not available?
As per specification database created with indexedDB should be persistent acrross navigation and browser session.
But current implementation is like persistent cookies. So removal of cookies might remove your database too.
As per google chrome indexedDB is a type of temporary storage.
Chrome: https://developer.chrome.com/apps/offline_storage
For microsoft & firefox it is persitent :
Microsoft: https://msdn.microsoft.com/en-in/hh563494.aspx
Firefox: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
Check supported browsers before use.
http://caniuse.com/#search=indexeddb
It isn't dependent on a cookie, though if you need to know who the user is (likely) you'll probably end up using a cookie of some variety...
As for offline sychronization... I thought about this a lot previously and created a project... The documentation for it is detailed and explains why and how... It may help, or at least give you things to think about. It has very recently been updated to support IndexedDB!
http://forbesmyester.github.io/SyncIt/index.html
In this space there is also RemoteStorage ( they were/are looking at using SyncIt + other bits in the project going forward ), Hood.ie and the commercial FireBase in this field.

A crazy but elegant solution to seamlessly update a hybrid app

I am using Phonegap to develop an mobile app.
Unlike web application, an mobile app is a static client which is updated less frequently than expected. Moreover, version management is required to maintain the dependency between server and client end.
I am thinking about a way to make the mobile app more like a pure browser. And here is a potential solution.
The initial index.html in Phonegap app gets the latest version from server and compares the version number cached in the browser/WebView;
If the current version is behind the latest, it fetches the remote homepage and replaces the whole html document and caches the latest version number;
Pros:
No more need to publish new version of mobile apps;
All platforms (mobile and web) use the latest version, no more manual update is required;
Cons:
Obvious delay when updating to new version, including the first launch;
All scripts and styles must be cached in localStorage to prevent browser from reloading these files unexpectedly.
I am sure some of you must have the same problem or idea. I will really appreciate if you share your thoughts here.
If the app is a tool, such as finding nearby restaurants or calling for a delivery service, I believe some pages with fixed layout and styling will do. The functions should rarely be changed, right?
For example, you can have a page showing a Google Map with markers attached to it, indicating all the nearby restaurants. Whenever there are changes to the list of restaurants saved on the server, the client does not require any modifications, as long as the functionality of this page is kept the same as usual.
Think of the homepage of Google. There is always a toolbar at the top, a Google Doodle and a search bar underneath. The layout is almost always the same. What differs is the Doodle which is dynamically loaded. Having a fixed layout should save you from updating your app client too frequently.
By the way, I usually don't update the apps on my mobile phone, as I am too lazy to do so. Therefore, I agree with you that it is better to publish new versions as few as possible.
I created a 1-way sync that updates my local web storage (SQLite) which is on just about every device these days. My sync updates my apps login/users it gets new updates from the db an updates my apps web storage.
You can use regular SQLite to write to your devices web storage that will only update when online.

Categories

Resources