Sync .sqlite file through iCloud [duplicate] - sqlite

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.

Related

Storing big data on a mobile device, iOS and Android, with react native and expo SQLite

I am working on a mobile app with react native and expo. The critical point of the app is that it needs to store big data on a device because it will work in offline and online modes both. I'm thinking to try expo SQLite for this and I have few questions regarding this:
Is it appropriate for storing large data on the local device, both Android and iOS?
When deleting data, does the database file size decrease, or stay as is?
Are there any limitations to TEXT type?
Can you suggest any good documentation, because on expo.io is too short (i think )?
Thanks in advance!
1) Storing large data on a react native app
Redux-persist and SQLite are not ideal ways to store large data on mobile devices. You can store your data on the application storage managed by the relevant OS. You can use Documents or /Library/Caches or tmp directories on iOS and external storage or external sd card on Android. You will need read-write permissions on Android, you can use react-native-permissions to handle it. react-native-fs is a good library to save, read or delete files.
2) Deleting data
If you store a binary or text in your database when you delete that record, it will reduce your database size. But if you store your file in the documents folder and add a reference to your database, deleting this reference won't remove the actual file from the device. You need to do this yourself.
3) SQLite limitations
I assume you are storing binaries. Regardless of the data type, there is a limit for SQLite Text type which is 2 GB. You can see more info here
4) Suggestions
I would prefer storing data in local storage as explained above and keep the references in Async Storage managed by redux-persist or a local SQLite database.
I just use expo-file-system as all my data is stored in a single tree so it's easy to async write it to file after every update and load it when the app opens.

Making sqlite3_open() fail if the file already exists

I'm developing an application that uses SQLite for its data files. I'm just linking in the SQLite amalgamation source, using it directly.
If the user chooses to create a new file, I check to see if the file already exists, ask the user if they want to overwrite the file, and delete it if they say yes. Then I call sqlite3_open_v2() with flags set to SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE to create and open the new data file.
Which is fine, except, what happens if a malicious user recreates the file I'm trying to open in between the file being deleted and SQLite opening it? As far as I'm aware, SQLite will just open the existing file.
My program doesn't involve passwords or any kind of security function whatsoever. It's a pretty simple app, all things considered. However, I've read plenty of stories where someone uses a simple app with an obscure bug in it to bypass the security of some system.
So, bottom line, is there a way to make sqlite3_open() fail if the file already exists?
You might be able to patch in support for the O_EXCL option flag of open(2). If you are using SQLite on a platform that supports that.

SQLite or PouchDB+SQLite. Professional advice needed

I am developing a vocabulary + quizzes app. For every word, I need to store an image and multiple audio files. I need some professional advice on:
1.Use SQLite directly or PouchDB with SQLite adapter. The app is completely offline. No DB sync.
2.Save image and audio files directly as binaries into the DB or save names only into the DB and the actual files to the local file system. I know it’s never been a good idea saving binaries into DB. PouchDB has sort of “attachments”. If the answer to my question 1 is PouchDB, should I use it to save binaries or not?
Thx.

How enable iCloud support for sqlite?

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.

Reading a local sqlite file from phonegap

I can create a sqlite DB in phonegap/html5 via window.openDatabase. I am going to have a large amount of data, so I want to ship it with the app.
So can I store a sqlite DB somewhere, within the app (It needs to work on both iOS and Android). I particular where is the shortName.db stored when I call
var db = openDatabase(shortName, version, displayName, maxSize);
And can I pre-populate this sqlite file. (In the phonegap environment)
Listed here are some solutions for iphone and android:
http://groups.google.com/group/phonegap/browse_thread/thread/5e57a728dc66a2a1?pli=1
I've not used PhoneGap, only created HTML5 apps that use Web SQL. However, if you're asking whether you can ship an app with a pre-populated SQLite database, then yes you can. Probably the simplest approach would be to provide the table creation scripts as part of the app. When it's first fired up, you can have the scripts run, and your database will then be fully initialised.
An alternative approach for deploying bulk data I came up is simply serialize it into text files and deploy the files together with the app.
You can use the File API provided by PhoneGap to load these files as strings, and parse them with Ext.util.JSON.decode().
Finally, use the MemoryProxy to integrate the decoded data with the rest of Sencha Touch and you are golden.

Resources