If I use Realm in my SDK, when someone embed's my SDK in their app and they are also using Realm would there be any conflict? or am I better off just sticking to CoreData.
I'm looking at moving to Realm because I like the thread safety aspect of it and the number of queries it can perform per second.
If you ensure that you use a custom Realm database - not the default - then you should be okay to use Realm in your SDK. Projects can contain multiple Realm databases without a problem.
Related
I have iOS application with Realm mobile database. We've integrated Realm real-time synchronisation, and need to put into the app a switch for turning off synchronisation.
App should correctly work in offline mode. How we can do this? How can we create Realm without RLMSyncUser?
Realm files that are synchronized, and ones that are not are structured somewhat differently (Synchronized ones for example store more of the transaction history). As a result, it's not possible to convert a Realm file between being synchronized, and not.
At the moment, best practice for that sort of scenario would be to have a master local Realm file, on which the Realm bases its operations (even when offline), but to then have an auxiliary synchronized Realm which data can be copied to.
If you have any suggestions about how you think this feature should work, feel free to file an issue on the Realm Mobile Platform feedback repo!
There is a lot of confusion when it comes to ionic 2 storage. There was a lot of changes in the new ionic version as Storage was moved to #ionic/strage . I am new to Ionic so some of the things are confusing for me. I have web-development background. From the documentation,
A simple key-value Storage module for Ionic apps based on LocalForage,
with out-of-the-box support for SQLite. This utility makes it easy to
use the best storage engine available without having to interact with
it directly. Currently the ordering is SQLite, IndexedDB, WebSQL, and
LocalStorage.
Installation
npm install #ionic/storage
If you'd like to use SQLite as a storage engine, install a SQLite plugin (only works while running in a simulator or on device):
cordova plugin add cordova-sqlite-storage --save
What I would like to know is, what happens when I run this in browser ? Where does it store the data? What would happen if I dont use cordova-sqlite-storage ? Where does it store the data then?
Ionic also supports SQLite plugin natively to store data in SQLite database .
import { SQLite } from 'ionic-native'
How is it different from Storage other than the fact that there is a fallback to IndexedDB, WebSQL, and LocalStorage ?
I hope my thoughts are in the right direction. A clear answer on how these modules work would be really helpful.
Ionic Storage is the first module written with proper web fallback in mind.
One near-term goal we have with Ionic is enabling devs to build 99% of their app in the browser. It's a much faster workflow. This means support for native plugins that have web fallbacks, as well as better mocking for ones that don't. - Max Lynch on Twitter
By default when running, #ionic/storage will prioritize the storage methods this way:
When running in a native app context, Storage will prioritize using
SQLite, as it's one of the most stable and widely used file-based
databases, and avoids some of the pitfalls of things like localstorage
and IndexedDB, such as the OS deciding to clear out such data in low
disk-space situations.
When running in the web or as a Progressive Web App, Storage will attempt to use IndexedDB, WebSQL, and localstorage, in that order.
- Official Documentation
So when your app is running in the browser (or on a device without the SQLite plugin) it will detect that SQLite is not available and will use IndexedDB/WebSQL instead.
How is it different from Storage other than the fact that there is a fallback to IndexedDB, WebSQL, and LocalStorage?
The SQLite plugin gives you low-level access to an SQLite database, which means you have to care about creating/updating your schemas, and write queries.
#ionic/storage is a wrapper which abstract away the differences of LocalForge and SQLite and provide a simple, unified API to store key/value pairs.
Also it takes care of serializing/deserializing of your objects.
From my understanding of the Ionic 2 RC Storage module, when you are running in the browser you are now only able to store key-value pairs (LocalStorage). You are currently not able to store anything more than that, so you should check out other options like PouchDB and LocalForage if you need full SQL support. This definitely isn't ideal for progressive web apps.
I've been looking into the Phonegap and PouchDB docs for days but I don't seem to get a clear answer.
Is it correct that when I add the Cordova plugin Cordova-sqlite-storage and use PouchDB using the PouchDB API, I'll have unlimited storage in my iOS webview?
I'm actually confused since I thought PouchDB was based on CouchDB (which seems like NoSQL). SQLite is using SQL queries for data storage.
Thanks!
Yes, you don't have traditional storage limits when using cordova-sqlite-storage. I've worked on an app that's in the App Store and Google Play today that uses >100Mb of data in SQLite. Cordova documentation backs this up.
PouchDB has a SQLite adapter which you might be able to use but I have no direct experience here and the documentation notes you should only use it with SQLite unless you really need >50Mb storage as there can be performance issues.
LokiJS with persistence might also be an option for you.
I have an older project with Realms Objective-C database setup. I am working on converting most of the project to Swift. Can I use Realm the way I have it setup now. Or do I have to reconfigure the database to use the Realm Swift version as well? Does it not matter - simply use a bridging header like everything else or?...
If your app conversion means actually deleting Objective-C code and putting Swift code in its place, then from an architectural standpoint, the best option would be to abandon the Objective-C API and go full-Swift with the Realm Swift framework instead.
Unlike the Objective-C bridging header, interacting with Realm via Realm Swift was redesigned to align to the best practices and ideals of writing Swift code, and so moving forward, you definitely should embrace that one.
If you've got users with pre-existing Realm database files that were created with Realm Objective-C, as long as you re-implement the model classes in Swift, with the same names (sadly, that would mean including any Objective-C prefixes at this point) and same ordering of properties, Realm Swift should be able to read them straight away.
Good luck! :)
A rookie question. Can any one explain when it is better to go with SQLite storage in sencha touch and when to go with use data stores.
regards,
I don't think they are mutually exclusive.
Sencha Touch stores come into their own when you have any kind of data that needs displaying in the viewport (and that data might change)
Sencha have a sql proxy that will work on these stores with a browser's websql implementation or a native app's sqlite implementation (with the aid of a cordova/phonegap plugin)
The main reason why you'd use SQLite on a native app is to circumvent the 5mb localstorage limit. You can't get around this limit for webapps though.