61–70 of 105 posts
Is there a Mac OS X support planned? Or perhaps the iOS version works as is?
The framework in our release zip only works for iOS but if you build from source[0] it will actually generate an OSX framework as well! [0] https://github.com/realm/realm-cocoa#building-realm
Has any succeeded building this in rubymotion?
Earlier quoted context omitted.
You can do the same thing with Realm. We actually have a couple of key benefits over SQLite there, which are that our file size is much smaller (usually about 50%), and we don’t require deserialization to get objects out of the file (Realm data can be streamed directly into memory as native objects in your language). On the minus side, We don’t work from everywhere yet, but we have internal bindings for Python, Ruby,…
Does this mean Realm would be usable for Xamarin-based apps in the near future?
LOVE this. I've dealt with the pain of multiple CoreData contexts in different threads and ugggh. This was easily the longest part of our Streak app development, as we needed it to be fast, offline, and fully synced. This is definitely a way better API that accomplishes the same thing as CoreData. If its actually faster too, wow, just amazing. One question - CoreData works really well with built in UIViewControllers…
Thanks for the kind words! Regarding wiring this to a TableViewController, we have some code samples already for Swift[0] and Objective-C[1]. Right now you get notified of changes and refresh, but we’re very interested in exposing a reactive-style binding mechanism as well. The storage engine underneath supports that very well actually, so stay tuned… [0] https://github.com/realm/realm-cocoa/tree/master/examples/swif…
Earlier quoted context omitted.
Thanks for the kind words! Regarding wiring this to a TableViewController, we have some code samples already for Swift[0] and Objective-C[1]. Right now you get notified of changes and refresh, but we’re very interested in exposing a reactive-style binding mechanism as well. The storage engine underneath supports that very well actually, so stay tuned… [0] https://github.com/realm/realm-cocoa/tree/master/examples/swif…
What about support for Windows Store and Windows Phone? Those platforms need something like this too.
Earlier quoted context omitted.
The big thing is really ease of use. Our blog post has a few more details on that point [0] but basically what we heard over and over and saw ourselves, is that Core Data quickly gets in your way if your app grows [1][2][3]. In essence, we tried with this initial release to offer a rich feature set with a simple API, less side-effects (especially for multi-threaded apps), and a performance that’s even better than usi…
Core Data has been improved and stabilized by Apple for over a decade, is used internally by many first party apps in iOS, is well documented and fully integrated into Xcode, and heavily "marketed" by Apple at WWDC. Any perceived performance issues can be eliminated or reduced by using faults, indexes and improving queries through NSPredicates. Even one of the blog posts you quote above [3] states that if he was star…
http://developer.couchbase.com/mobile/#couchbase-lite
I see a lot of comments here about wanting a CoreData replacement that's better at sync, which is exactly the use case CouchbaseLite is meant to solve.
LOVE this. I've dealt with the pain of multiple CoreData contexts in different threads and ugggh. This was easily the longest part of our Streak app development, as we needed it to be fast, offline, and fully synced. This is definitely a way better API that accomplishes the same thing as CoreData. If its actually faster too, wow, just amazing. One question - CoreData works really well with built in UIViewControllers…
Thanks for the kind words! Regarding wiring this to a TableViewController, we have some code samples already for Swift[0] and Objective-C[1]. Right now you get notified of changes and refresh, but we’re very interested in exposing a reactive-style binding mechanism as well. The storage engine underneath supports that very well actually, so stay tuned… [0] https://github.com/realm/realm-cocoa/tree/master/examples/swif…
Has any succeeded building this in rubymotion?
I don’t think anyone at Realm has ever tried, but I doubt it would work at this point. We do a lot of things specific to each language in the implementation, so we’d have to support RubyMotion explicitly for it work.
The API approach vs. SQLite, etc. is interesting - particularly that it does not look to have very many moving parts. I'm curious about transactional semantics though. Are they 'always on' or is there API control (still haven't gone through docs completely yet, so I may answer my own question later).
Alexander from Realm here, all interactions with the database is through full ACID transactions, but it is a bit untraditional in that the interaction model is build specifically to mobile apps. The transactions interact with the runloop, so that you are always in an up-to-date read transaction (which always give you a consistent view and never blocks, even when other threads modify the same data). To write, you have…
Earlier quoted context omitted.
I don’t think anyone at Realm has ever tried, but I doubt it would work at this point. We do a lot of things specific to each language in the implementation, so we’d have to support RubyMotion explicitly for it work.
RubyMotion is Objective-C under some thin covers so it seems like it would be relatively straightforward to have it work with Realm without a lot of extra trouble.