Custom initializers for Object subclasses: When creating your model Object subclasses, you may sometimes want to add your own custom initialization methods for added convenience.
Due to some present limitations with Swift introspection, these methods cannot be designated initializers for the class. Instead, they need to be marked as convenience initializers using the Swift keyword of the same name:
MyModel: Object { @objc dynamic var myValue = “”
convenience init(myValue: String) {
self.init() //Please note this says 'self' and not 'super'
self.myValue = myValue
}
I’ve only done it it in Swift, but I added a convenience init to create a new Object instance by copying over the attributes. If the object contains embedded objects then you need similar convenience inits for those too:
A Realm Object class can contain primitive such as strings and ints, but it can also contain other Realm objectc. In my example, the User class includes the userPreferences attribute which is UserPreferences object. Because UserPreferences is embedded within an Object rather than being a top-level Realm Object, it inherits from EmbeddedObject rather than Object
Remember that Realm is backed by ObjC code and not Swift. For example Realm (objects) do not directly support computed properties (to be managed/handled by Realm), which is very common in Swift objects.
So when you create a Realm Object class UserClass: Object you are creating a UserClass of type Object, which is itself an NSObject (I am being loose here)
A designated initializer must ensure that the properties introduced by its class are initialized before it delegates up to a superclass initializer. Properties cannot be left in an intermediate state which super.init could cause (depending on how the vars are defined within the object)
The memory for an object is fully initialized once the initial state of all of its stored properties is known. To satisfy that requirement, a designated initializer must make sure that all of its own properties are initialized (self.init) before it hands off up the chain.
Without the initial value, the compiler won’t synthesize initializers for the class - which would be a version of init that calls through to the base class.
Side effects? objects that don’t behave as expected, ‘lose’ data and and generally mis-behave - and those issues are very hard to track down. Been there, done that.
I was under the assumption that a Object instance init() is merely calling 'super.init()` if my other variables are either optional or already had a default value. Looks like I’m wrong.