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! :)
Related
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.
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 trying to figure out how to get a decent LINQ to something working for ORM database access in a Windows Store app.
All I've found is SQLite and the sqlite-net NuGet package. The latter sucks a bit, as I don't get any .dbml like structure which resolves relationships and provides navigation properties for easy querying (no manual joins needed then).
I was wondering:
Does dblinq in comnbination with SQLite offer this?
Will using this pass Windows Store validation?
Thank you !
Update: Some links I used in my research:
The famous Tim Heuer post on SQLite and Windows 8: http://timheuer.com/blog/archive/2012/08/07/updated-how-to-using-sqlite-from-windows-store-apps.aspx
DBlinq: http://code.google.com/p/dblinq2007/
sqlite-net: http://code.google.com/p/sqlite-net/
Interesting discussion stating ADO.NET is not possible: http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/e9cdd75d-03e4-4577-988e-4c02a52e3f50
I'm not familiar with dblinq but by looking at the sqlite tests in the project, it seems the library is offering what you're looking for, i.e. navigation properties for relationships between different tables.
Since dblinq is a .NET library, using it shouldn't make the store validation fail. There is another problem though: you can't use such a .NET library in a Windows Store application, only Windows Store class libraries and portable class libraries are allowed. Since the source for the library is available, you can try compiling it as a Windows Store class library, but I'm afraid there are going to be some classes missing that dblinq is depending on which might make it difficult to port.
I am creating a web service in ASP.NET that needs to be accessed from Android, iOS and BB. The big stickler here is that I do not want to use any libraries on these mobile platforms to read the transmitted data. I know that Android has a JSON parser built-in, but iOS does not. I also know that WCF-format is out, since none of them read that.
Is my only choice using a proprietary format for the transmitted data to be read by these devices? Has anyone found a good (native) format for the communication with the service across the platforms that doesn't involve creating a proprietary format?
Use JSON. It's built into Android and Blackberry, and there are Objective-C libraries to use it with iOS. It's light and compact and easy to create and parse.
What is "WCF-format"? ASP.NET web services use SOAP by default. WCF services can also be configured to use SOAP or to be RESTful. SOAP is just XML so any framework with an XML parser should do, and with WCF REST you can work with XML or JSON easily.
Your best bet is to use JSON. Although iPhone SDK doesn't have a built-in SDK library, you will easily find an inplematation (json-framework for example). The big benefit willbe that you could configure WCF to output bare JSON, which will be easily understood by all platforms.
REST has less overhead than SOAP, since it is just an HTTP GET/POST/PUT/DELETE. If you need something more than simple CRUD however, SOAP may be appropriate.
Blackberry doesn't have built-in support for JSON as far as I know, at least not for older models. iOS doesn't have built-in support for any of the web services so you have to parse the XML manually if you don't use any third party library. I would say you if you want, you can use JSON with some borrowed library. I chose SOAP because I can use it across platforms including some really old windows mobile phones and I want to use as less third party lib as possible.