I'm currently finishing up a project for IOS in Swift in which I've used an SQLite database to store data with SQLite.swift.
At the time of coding I didn't know that SQLite files are stored locally on the device/simulator and I need a way to run the app and have the database synced between two devices, as soon as possible. I tried swapping over to Firebase since I heard that would be a solution but I'm not at all familiar with it and am worried it might be risky given all my functions are written for SQL tables. I also thought of keeping the SQL and adding on a firebase database to fetch the data from but I'm not sure how to execute that.
The solution doesn't have to be 100% reliable for all cases- I just need to simulate running the app on more than one device with synchronised data.
Does anyone have any suggestion for a way to do this? Or a way to store the data on a computer so that it can be accessed by both devices?
Any advice is appreciated!
There are no elegant solution with pure SQLite database. Just few offers:
Moving to CoreData (You will get all what you want with sharing data between devices)
Uploading database file to iCloud from one device and download it from another device
Build up classic client-server communication
Let iOS do the synchronisation via iCloud, e.g. use Core Data with CloudKit: https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/setting_up_core_data_with_cloudkit?changes=_1
Related
Let me get this out of the way right now: yes, it was almost certainly a mistake to not use Core Data. However, I was new to iOS development when I made these decisions, and I had no idea I'd be hamstrung like this. Moreover, the app is intended to also run on Android (eventually), so I avoided platform-specific APIs wherever possible.
I have an iOS app that stores data in a local SQLite database file. The data stored in the file is provided by the user, so it's important that it be kept safe. I had plans to "do this later", and later is now here. I am quickly coming to the realization that it won't be as straightforward as I had hoped...
I now understand that it won't be possible to seamlessly synchronize data across devices, and I'm willing to accept that limitation until I manage to migrate to Core Data. However, in the meantime I'd at least like the SQLite database to be backed up periodically so users can feel safe using the app on a single device. I was thinking I would do this:
periodically (e.g. once a week) copy the SQLite file from local storage into cloud storage, thus ensuring it is backed up
when the app starts, if the local store is missing or corrupted but the file exists in the cloud storage, ask the user if they would like to copy it over
The biggest problem with this approach is that the user could run the app on multiple devices and therefore the data stored in iCloud could be from any one of those devices, but only one. To combat that, I thought I could just use a per-device, unique name for the file in cloud storage. I would generate this using UIDevice.identifierForVendor.
So my startup logic would be:
Determine the unique name for the cloud file.
Is the local file missing or corrupted, and if so, does the cloud file exist?
2.1. Ask the user if they would like to restore from the cloud file. Make it really hard for them to say no because doing so will lose all their data.
2.2. If they say yes, copy the cloud file to the local file storage.
Open the local database file.
And running in the background I would occasionally copy the database file from local to cloud storage.
I would like to know whether this a sensible approach until I do Core Data integration. Also, are there any hidden "gotchas" that I'm perhaps missing?
UPDATE: as #TomHarrington pointed out in a comment, it turns out my database file is already sitting in /Documents, which is backed up to iTunes and any iCloud account. So my question morphs into this:
Should I simply ensure my database has a device-specific name so that it is not clobbered by the app running on another device connected to the same iCloud account?
I'm going to answer my question, since I ended up going down this path and finding a MASSIVE blocker. There is a bug in the UIDevice.identifierForVendor API that causes it to regenerate every time a new version of the app is installed! See here. This of course rules out using it as a device identifier. sigh
I think I'm SOL with that approach. Instead, I might generate a GUID on first execution and use that as my identifier. Problem is, I need to store that somewhere that isn't backed up to iCloud.
Ugh, I may just give up here and say my app can't be run on multiple devices until Core Data integration is done.
UPDATE: I ended up generating an identifier on first run and storing it in the keychain (as a local entry only so it isn't backed up to iCloud).
I have an iOS app that timestamps some events and loads them in UI. To persist the data I use CloudKit which is quite fine and fast enough for my use case.
1st problem is, when an event occures I save it instantly to cloudkit therefore if internet is not reachable I have to handle the situation. I had the idea of having a local sqlite db and sort of keep track of connectivity and deal with syncing manually. Here is where 2nd problem comes in in which any inconsistency of the data must be handled by me (e.g. if the user edits the data while offline).
I found YapDatabase library doing the exact things but I feel the learning curve is a little bit steep.
Another idea could be using sqlite db but saving the file in the icloud drive. This way it will be persisted automatically while I have access to the app sqlite. Any change in the db tables will change the file singnature and fire icloud drive sync.
What's the best choice?
We have a requirement to be able to store the data on device and make it available even when device is off network, and when device comes back to network it should be able to sync the stored data and be able to update the stored data with latest server data and so on. I understand that lots of this needs to be implemented using sync/notification/versioning stuff ourself.
However are there any recommended framework/API (other than vanilla Core Data) that people use to store large amount of data to be stored/cached on iOS devices? Any reliable and intelligent caching solution out there?
Any recommendation of this sort will be very helpful.
I have a lot of data present in the database present in my webserver. Each time I starts the ipad application after downloadiding, I want all these data to be copied into the sqlite database present in my application. Then using this data, the application should work.
We are now using xml's and sometimes on 3g it takes about 20minutes which is completely unacceptable. After the 1st time it syncs using time log and all. And it works without any problem.
Is there any other way I could get all the data and make it populated into my sqlite db?
If it is a large database it might be worth doingin the background. And even better if it was just over wifi (otherwise you'll be eating up your users data)
What I usually do is have a local copy of the database shipping with the app, so the user can use that, and update it in the background. It might be worth creating some pages where you just present the updated content, download that, then update your database accordingly. Rather than downloading everything all the time.
This would depend entirely on your implementation however.
On initial app launch you could download just enough data to make the app functional. Then download the rest of the data in the background.
This is a common strategy used by Sync Frameworks and works pretty well. I have personally tried with with synchronizing more than a thousand objects using OpenMobster's sync service.
Now what data to download initially is to be decided by the requirements of the App
Thanks
I want to make my app sync its SQLite Core Data store between devices using iCloud. Right now I let users manually sync their SQLite files using Dropbox, but that is cumbersome for users. I want it to be automatic.
What is the best practice to achieve this functionality? Do I need any special provisioning profiles?
I read somewhere that I need to set up my Core Data database to use UIManagedDocument but I haven't found anywhere that explains how to do this clearly. Any suggestions?
Turn on cloud syncing. That is step one. From there it depends on your application and its requirements.
Sorry for the short answer but your question is rather vague and you do not have any requirements for your app.
Assuming it is just a sqlite file all you need to do is turn on cloud syncing, change your Core Data stack to handle being async and Bob's your uncle.
Update
It is unlikely you will need to use UIManagedDocument. I would say that unless you have a kitchen sync type application you are fine using the Core Data ubiqutous store syncing at the NSPersistentStore level.
At this time, quite a few people are having issues with UIManagedDocument so I would avoid it unless you absolutely need to sync things that are not contained within the sqlite file.