So, on watchOS, I know you can schedule (and reschedule) a WKRefreshBackgroundTask to do work for you in the background. This is great for my app to make sure that data is current and up-to-date on watchOS - especially since it doesn't receive updates like iOS and macOS.
Except, my data uses CloudKit to store a user's data.
I want to use something like the URLSession scenario, where you schedule a WKApplicationRefreshBackgroundTask where you create a background URLSession task and hand it to the system. The system in turn hands you a WKURLSessionRefreshBackgroundTask where you check if your data completed its URLSession (by checking if the downloaded data exists).
My question is, how do you do something like this with CloudKit?
I could just do the downloading of my user's data in the WKApplicationRefreshBackgroundTask, but I don't think I'm guaranteed it will finish in the time the system gives to my app. This is why (it seems) Apple recommends you split this into two Background Tasks:
WKApplicationRefreshBackgroundTask - to create the URLSession and hand it to the system.
WKURLSessionRefreshBackgroundTask - to act upon the data downloaded from step 1.
I am not sure you can do this with CloudKit? Or, at least I can't seem to find something of the sort.
If you want to use WKURLSessionRefreshBackgroundTask you have to access the iCloud database via URLSession. This is possible from an app but much more complicated.
iCloud web service documentation
send a web request to iCloud from a swift app
Don't forget to get your API request token for your database on the iCloud dashboard if you want to try it out.
Related
If I get a push notification on iOS, I want to pull some related data from the Firebase database in the background, so my user can read their articles on the train.
I'm getting the appropriate onDisplayNotification event, and it's reliably triggering, but when I query the database, it doesn't load the relevant data until the app is foregrounded, by which time the user may be offline.
As I understand it, this is a deliberate aspect of react-native-firebase to prevent the app from consuming a potentially huge amount of resources in the background of the application.
So how can I retrieve entries from firebase.database() when my app is backgrounded?
Turns out this is a bug in version 4, which causes the OS to smack firebase down for being greedy.
Follow https://github.com/invertase/react-native-firebase/issues/971 for progress.
I need to store information in the mongoDB database on the phone to be used while off-line. The app will download the data while online, and store it in the DB, to be used while off-line. Then when the user is online again, I will send the mongoDB info collected, using my API.
I don't want the mongoDB to be synced with the server while online, either. I want to keep the data on the individual phone. I want to use the data in mongoDB while offline. I need the app to be able to quit/restart, without losing the data on the phone locally.
What is the best way to go about doing this?
There are some options to consider.
1) Create a local mongo database - this is client only storage with no server publication (not sure if it persists between app invocations)
2) sqlite can do the job, but only on Android (not IOS)
3) LokiJS is a fast JS only database that promises to be useful - haven't explored it, but it would be good to hear some feedback
4) If the data is small, you could use LocalStorage, it's pretty simple, you just need to look after serialising and de-serialising it yourself
i was wondering if there is a way to enable cloud features for a SQLite database application.
Should i save the whole database to the cloud each time ? For example when i quit the application is it required to save the whole database to the cloud.
What do you suggest ?
Should i drop SQLite and use another database for cloud programming .
iCloud supports SQLite databases.
When properly setup it will only sync change logs instead of the entire database. In theory it's pretty nice. I haven't however had the best of luck using it yet, it seems to be a little too buggy to actually use in ios 5, hopefully it's better in 6.
To be most efficient you could manage a changelog of objects that are modified by the app. Then when its time to sync (while closing the app for instance), you can make operational requests to the Cloud. For add and update you can send the entire object, while for delete just the oid should suffice.
This is a very simple sync scenario. Things can get complicated fast if you are looking to send changes that happen in the Cloud down to the device. That is a scenario for a different thread.
Based on your question, you just need to sync from the device to the Cloud.
I've build a library-style SQLite iOS app using the code in the Recipes sample app, and it works - updates on one device are (eventually) reliably propagated to all other devices running the same app. I've been testing it with multiple events per hour all day long, and all the log transactions do get to every device. However, the time for the updates to propagate is highly variable. If I bring the app up and let it sit, it could be a relatively long time before the cloud sends update transactions to the app, and so what's on-screen remains old data for that same long time. Worse, there's no indication the data is out of date.
If I cause the app to post a change to the cloud, though, updates from the cloud propagate down relatively soon. That suggests that I could put in a hack that periodically posts pointless changes to the database, but even then I won't know if I've received all the changes.
First question: Do methods that will force transactions to propagate exist? a This thread suggests not.
Second question: Is there a way to detect if the local database is out of date? I don't want to tickle the cloud copy incessantly, but doing so now and then until the database is current might not be such a bad idea.
1) if you find such methods, please let me know.
2) same stuff here. I didn't even find any reliable way to detect whether the currently running instance of the iCloud app is not the first instance i.e. other instances have already sent updates to the iCloud until the first push received (which can take some unknown time)
I am working on an AIR app which should work in both online and offline model. The user can do various actions, while offline and the results would get saved in a local DB. The same needs to get synced up with the global DB once the user goes online. I googled a bit on it, and it seems that Adobe LCDS (lifecycle data services) is the only available option to do it. However, it is an enterprise solution, and way too costly.
Is there any other implementation for this? Has anyone used CouchDB for online/offline synchronization?
Thanks and Regards,
Kapil Kaushik
For doing a DB sync with your server when the Air app is only, you do not have any requirements as for which backend technology you use. LCDS makes it simpler, but it's not your only option. Heck, you could use just a normal PHP script to do the sync for you if you'd like.
The hard part of it all is that you need to figure out your syncing algorithm so that you don't lose any information. Normally what I do is that when the app is connected online again, it sends all the information that was modified/create (with timestamps on when it was modified) while offline to the server, then the server has an algorithm that checks if the offline information is newer than what was done previous (or does some other business rule depending on your situation). When the server decides which data is good, it then sends the updated data to the client and effectively syncs everything.
This can be done through a normal HTTP request, polling or pushing.