I'm using realm with iCloud document, so question:
How can I change realm file without restarting app when iCloud document changes?
You should never change a Realm file while it is opened by a Realm object. This could end in unknown side effects.
So I would recommend to export the realm file whenever it makes sense. This file could be synced via iCloud and also be monitored for changes - to import the changes.
Exporting method explained the docs: https://realm.io/docs/swift/latest/api/Classes/Realm.html#/s:FC10RealmSwift5Realm15writeCopyToPathFS0_FTSS13encryptionKeyGSqCSo6NSData__GSqCSo7NSError_
If the realm file is larger there is another disadvantage: iCloud would always sync the whole file even for smaller changes.
In short: It feels complicated to implement a clean, conflict free syncing solution using Realm and iCloud. Maybe you should think about using CloudKit or any similar backend service to realize your data syncing:
https://developer.apple.com/library/ios/documentation/DataManagement/Conceptual/CloudKitQuickStart/Introduction/Introduction.html
Related
I have an application which is already on app store and it use Sqlite Database. Now i want to make another version, which include iCloud sync, now ,the question is ,IS there any tutorial or third party code of syncing sqlite database with iCloud ,as i searched a lot but didn't get any useable answer??
Thanks in advance.
SQLite and iCloud do not mix well. Although it's possible to use the iCloud file APIs to put a SQLite file in iCloud, doing so is almost guaranteed to corrupt the file. SQLite wasn't designed with this kind of use in mind, and between external journal files, uncommitted transactions, etc, it's not even a question of whether the file gets corrupted, only of when (and the answer is "very soon").
Although Core Data can use both SQLite files and iCloud, it doesn't sync the SQLite file. Instead it has a scheme that uses transaction logs to send changes back and forth.
If you want to use your existing data with iCloud, you'll probably have to do something similar. I don't know of any good reference implementations. Basically, you'll need to export your data to some other format, and detect and import changes from other devices.
I want to control background sync of google-firebase's firestore db with persistance mode (PersistenceEnabled to true).
I'm afraid the old version client, works offline and don't know the app's version-up (with some destructive updates), may upload local-data to server when change to online.
In this case, I want to check current app versions and allow/not allow before sync.
Is there any solution?
Data in the cache is only updated when you attach a listener/observer to it. There is no automatic synchronization happening for the data in the offline cache.
This means that you can add a version check to your application startup code, before you attach any observers. Simply store a database-version field in a global document, and check against that upon application startup. If the version is greater than what the app was made to handle, show an upgrade prompt.
I have a firebase function that makes use of a SQLite database (read-only) which is currently uploaded along with the function.
The problem is that the db file is quite large and gets uploaded every time the function is changed. Is there a way to fetch this file from cloud storage during the installation process (during firebase deploy) - without hard-coding the URL in the source files?
What you're trying to do is problematic because your code running in Cloud Functions may actually be running on any number of server instances, determined by the load on your project. As such, downloading a file once at the time of deployment isn't going to naturally affect all the instances that maybe created or destroyed at any given moment.
It's far better to keep doing what you're doing, and include your extra data during deployment. When a new instance is spun up to handle events for your function, the file will be immediately ready to help service requests.
Is there anyway to open and read a SQLite database file on GAE?
I am currently uploading dbs to blobstore as admin and serving them publicly to user clients. I just can't read them in the GAE admin interface.
You can use SQLITE on Google App Engine. The problem has nothing to do with the support of certain libraries. It has to do with read-only file system. There is, however, a writable /tmp directory. If your app on startup first copies the db.sqlite3 file to /tmp/db.sqlite3 and references this path as database path, it will work.
There are, however, drawbacks.
1. This is not a "real" directory i.e. it's stored im memory. If database is too large, one will get problems.
2. Each instance has its own copy of db.sqlite3 file. Does not scale well.
Here is a django example:
Using SQLITE for local Django development for Google App Engine?
Short answer, no it is not possible to use a SQLite database on a standard Google App Engine application as it is not currently supported. However, you can give a try at implementing your own configuration with the App Engine Flexible Environment that allows to take advantage of custom libraries through Infrastructure Customization.
In case you would want to experiment, here is a sample Django application designed to be run with its default SQLite database on the App Engine Flexible Environment. Still, make sure to read the database notice providing alternative data storage options and explaining that SQLite data does not persist upon instance restart.
I want to provide iCloud support for my wrapper around sqlite. Is not using coredata.
I wonder how enable iCloud for it. The database content is changed all the time (is for invoicing). Also, if is possible to have some kind of versioning will be great.
Exist any sample I can use to do this?
The short answer is no, you would need to use Core Data as you suspected. Apple has stated that sqlite is unsupported.
Edit: Check out the section on iCloud that's now in the iOS Application Programming Guide under Using iCloud in Conjunction with Databases
Using iCloud with a SQLite database is possible only if your app uses
Core Data to manage that database. Accessing live database files in
iCloud using the SQLite interfaces is not supported and will likely
corrupt your database. However, you can create a Core Data store based
on SQLite as long as you follow a few extra steps when setting up your
Core Data structures. You can also continue to use other types of Core
Data stores—that is, stores not based on SQLite—without any special
modifications.
You can't just put the SQLite database in the iCloud container, because it might get corrupted. (As you modify an SQLite DB, temporary files are created and renamed, so if the sync process starts copying those files, you'll get a corrupt database.)
If you don't want to move to Core Data, you can do what Core Data does: store your database in your document folder, and store a transaction log in the iCould container. Every time you change the database, you add those changes to a log file, so you can play them back and make equivalent changes on other devices.
This gets pretty complicated: aside from getting the log/reply logic right, you'll want to coalesce redundant changes and periodically collapse the log into a complete copy of the database.
You might have an easier time developing a solution if you can exploit knowledge of your application (Core Data has to solve the problem in the general case). For example, you could save invoices as separate files in the cloud container (text, Property List, XML, JSON, whatever), writing them out as the database changes and only importing ones if the system tells you they were created or changed.
In summary, your choice is either to migrate to Core Data or write a sync solution yourself. Which one is best depends on the particulars of your application.