Realm Cocoa 0.91
We just pushed a Realm Objective-C update to this website and to CocoaPods. Here’s what’s new!
Sharing Realms Between Processes
The big news for this release is that we now support seamlessly sharing Realm files between multiple processes, which is necessary for most iOS 8 App Extensions including Apple Watch Extensions. Just put the Realm file in your app group container (on iOS or in sandboxed OS X applications) and everything works exactly the same as when you open a Realm file on multiple threads.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Get the shared directory for the application group
NSURL *container = [[NSFileManager defaultManager]
containerURLForSecurityApplicationGroupIdentifier:@"group.com.example.my-app"];
// Set the default realm path to a location in the shared container
// You can also pass a path in the container to +[RLMRealm realmWithPath:], of course
NSURL *realmURL = [containerURL URLByAppendingPathComponent:@"default.realm"];
[RLMRealm setDefaultRealmPath:realmURL.path];
// Just use the Realm as usual
ConfigurationObject *config = [[ConfigurationObject allObjects] firstObject];
...
return YES;
}
There are a few limitations at the moment:
- Encrypted Realms cannot be shared between processes.
- All processes must be running on a single machine, and must be the same architecture (so no sharing Realm files on a network drive, and opening a Realm in both an iOS simulator and an OS X application requires using a 64-bit simulator).
- All processes must be using the same version of Realm Cocoa, and must have identical object schemas.
Indexed Properties
We’ve changed how you declare indexed properties. Rather than overriding attributesForProperty:
, you now just override indexedProperties
and return an array with the names of the properties which should be indexed:
@interface MyModel : RLMObject
@property NSString *indexedProperty;
@property int otherProperty;
@end
@implementation MyModel
+ (NSArray *)indexedProperties {
return @[@"indexedProperty"];
}
Encryption
This release has a lot of fixes for our encryption functionality. The biggest change is that we now support using encrypted Realms with a debugger attached to the process, and we now play nicely with most third-party crash reporters. The only caveat there are that you need to install the crash reporter before you first open an encrypted Realm, or you may get spurious reports of errors when the app didn’t actually crash.
We’ve also fixed a number of bugs with encrypted Realms, including crashes on ARM64, -writeCopyToPath:encryptionKey:error:
sometimes not actually writing the entire file, and a crash after large commits.
The changes to support using encrypted Realms with a debugger attached also made it possible for us to run our entire test suite using encrypted Realms, which should greatly reduce future problems with them.
Improved Error Checking
We now throw exceptions in the following scenarios rather than crashing or behaving in confusing ways:
- Calling
-beginWriteTransaction
within a notification block which was triggered by another call to-beginWriteTransaction
. - Calling
setEncryptionKey:forRealmsAtPath:
,setSchemaVersion:forRealmAtPath:withMigrationBlock:
, andmigrateRealmAtPath:
when a Realm at the given path is already open. - Calling
-[RLMRealm deleteObject:]
or-[RLMRealm deleteObjects:]
on objects which are not persisted in the Realm. - Having
RLMObject *
orRLMArray<RLMObject> *
properties on anRLMObject
subclass, rather than pointers to the appropriateRLMObject
subclass. - Nesting
RLMObject
subclasses within functions in Swift.
Other Improvements
- The browser will no longer show objects that have no persisted properties.
-
RLMSchema
,RLMObjectSchema
, andRLMProperty
now have more useful descriptions. -
RLMArray
now exposes anisInvalidated
property to indicate if it can no longer be accessed due to the containing object being invalidated. - Fixed a crash when calling
createOrUpdate:inRealm:
with linked objects that are not already persisted in the destination Realm.
We shipped a bunch of point releases with bug fixes between 0.90.0 and 0.91, so here’s a quick rundown of things fixed in those versions:
- Fixed incorrect results when using aggregate functions on sorted RLMResults.
- Fixed some assorted assertion failures.
- Fixed columns sometimes being dropped and recreated during migrations.
- Fixed incorrect column type assertions when the first Realm file opened is a read-only file that is missing tables.
- Made calling
createInDefaultRealmWithObject:
,createInRealm:withObject:
,createOrUpdateInDefaultRealmWithObject:
orcreateOrUpdateInRealm:withObject:
a no-op if the argument is an RLMObject of the same type as the receiver and is already backed by the target realm. - Throw an exception when adding an invalidated or deleted object as a link rather than just crashing.
- Throw an exception when calling
createOrUpdateInRealm:withObject:
when the receiver has no primary key defined. - Fixed the browser treating
RLMObject
as a model object class. - Fixed a crash when calling
objectsWhere:
with grouping in the query onallObjects
.
Thanks for reading. Now go forth and build amazing apps with Realm! As always, we’re around on the mailing list, Stack Overflow, GitHub, or Twitter.