Ionic 3: Migrate data from localStorage to indexedDB on app update - ionic-framework

I am creating a hybrid application using Ionic 3. Earlier i was using localStorage to store auth token and other data. Due to performance issues and storage limit, now i am using ionic storage to store data on devices.
Now I have to release latest version of application in stores and I want to move data from localStorage to ionic storage so that users won't face any issue. If I'll now migrate my data then new app will check token using ionic storage but my data is in localStorage.

We actually just did something similar in our app. We adjusted our app to use our new storage, and added a fallback to check the old storage if we found nothing in our preferred storage. If the fallback did find data in the old storage, then we moved it to the new storage (so that it would be found on the first try the next go-round).
It was a little clumsy, but not bad. Then in our next release we removed the fallback check since the majority of our users would have moved their storage from old to new by that time.

Related

What happens for hive local database in flutter after updating app in app store?

I'm new i flutter. I'm developing an offline money management app. I used hive as local database of my app for storing data locally. I have one important question: if I release new update after publishing my app in the app store,
what happens for hive local database in flutter after update? Does my users will lost their registered data or not?
Updating the app does not change or delete it's data on a device.
However, you are responsible to ensure the new version of the app can read and update the database successfully if you add or remove fields, type, tables, etc.
The is best ensured by suitable test cases that can be run before each release.

Firebase Connection Killed

I have integrated Firebase into my iOS project. I have been using Firebase for years across many projects. This specifically is using the Firestore. I can authenticate fine and write to the database. However, after the write is complete, even though it's successful, I receive the following message:
Firebase Database connection was forcefully killed by the server. Will not attempt reconnect. Reason: Firebase error. Please ensure that you spelled the name of your Firebase correctly
The bundleID was copied and pasted directly from the app to the Firebase setup. I even deleted the app from Firebase and created it again. I have downloaded the GoogleService-Info.plist and I checked that the bundle there matches the bundle of the app. I can see nothing wrong here and again functionality is working fine.
The only instance I saw of this message browsing around was with a non-US based developer and it was suggested that additional config was required. However, that is not the situation for me. What else might cause this error to be generated?
The error message seems to point towards Realtime Database, despite your interest in Cloud Firestore.
I recommend:
Making sure you're using the latest SDK. Old SDK versions (before mid 2020) might require the Realtime Database URL to be present in the plist file, which isn't always the case anymore.
If step 1 doesn't solve the problem, you can:
Force the creation of a Realtime Database instance in the Firebase console.
Download the updated plist file and add it to your project.
If you end up with the second solution, can you comment with the SDK version you're using, so that I can check for issues in that?

BB10 Android App updates clearing user data

I am porting an Android app for BlackBerry and during tests I see my saved user data (properties and a list of activities) disapearing each time I upload my newly build BAR to the device.
Will this happen on every update of the app?
On Android, my local data stays permanently on uploading and installing new versions.
I do not want to use shared storage for this data to avoid too many permissions, since the user won't understand why I need this shared storage (user could wonder about if I want to steal his other data).
This seems to be an issue of the Android VM version used at that specific time. In the meantime, the behaviour is as one would expect it, and all user data stays even after app update.

Phonegap (1.4.1) Storage not working anymore with iOS 5.1

I developed an App for Android and iOS using Phonegap. Both Apps are already running successfully and available on the stores. Now I added some changes for an Update. If I have data stored (using the SQLite database) in the previous version and updating to the new one, the Storage Api on IOs 5.1 is not working anymore.
If I call
var db = window.openDatabase("mydb", "1.0", "", 5000000);
nothing happens.
It's working fine for Android, it's also working if I do a new install or if I do not have data already stored in the database from the previous version of my app. I'm using other Phonegap functions like Notification or localStorage, which are working perfectly fine.
Any help would be much appreciated, since I'm really running out of ideas :)
There is a fix for both issues with Webkit storage and iOS 5.1
Storage moved from /Webkit to /Cache
Storage is not adjusted to updated folder structure on an App update under iOS 5.1 (WebKit Bug)
https://issues.apache.org/jira/browse/CB-330
This solution seems to be more safe than just changing the location of Webkit data calling a private API. While the App is running the Webkit storage locations are used. On resuming or terminating all data is backuped to the documents folder. Timestamps ensure that ab old backup cannot overwrite newer storage data (if the app crashes...).
The best: Users that are on an older iOS Version using an App with that fix in it, will not suffer damage lost in case of any iOS updates. Thats why one should not wait...
It's strange, it should be working... By the way, in iOS5.1, WebSQL is considered tempory data that can be deleted at any time...
It's possible to change the location of WebKit data calling a private API. You should be able to set the location to a secure folder like Documents. I did not test this solution yet, but look at this post :http://stackoverflow.com/questions/4527905/how-do-i-enable-local-storage-in-my-webkit-based-application
I think the safer way is to use SQLite (same as WebSQL) with a phonegap plugin. That plugin save the database in the Document folder, that mean that the DB is not deleted and is saved by iCloud.
Here is the Native SQLite phonegap plugin : https://github.com/davibe/Phonegap-SQLitePlugin
Regarding this plugin, there are some differences between the WebSQL API, here is an adaptor:
https://gist.github.com/2009518
You should also migrate the old WebSQL db file (stored in Library/WebKit or Caches directory) to the Document folder. Here is a code to do that :
https://gist.github.com/2009491
There is also a fix implemented in the latest version of Cordova : https://issues.apache.org/jira/browse/CB-330 (it makes a backup of the DB files in the Document folder)
And if the data are important, you should save it to a server. I wrote a small lib to synchronize the SQlite DB to a server :
https://github.com/orbitaloop/WebSqlSync
There has been a Jira issue created on this: localStorage / SQLDatabase Error after App update

Does a TestFlight upgrade break Core Data schemes in an app?

I've got an app that I'd like to send to beta testers using TestFlight.
We won't be changing the Core Data model, but I'm curious about two things:
When I send out an updated beta, is there any risk that the Core Data will be corrupted with the update?
When the app goes to the App Store, will our beta testers have to start fresh from the App Store version, or will their Core Data still appear in the App Store version?
The user's data is stored in their own documents directory. If you haven't changed the scheme (or if you have and you have a proper migration set up) then just updating the app will not affect their own data - unless they delete and install the application again.
If you haven't changed the bundle identifier - and they don't delete and re-install their app - the data will still exist in the Document directory.