So, as my blog has indicated, I have been trying to tackle many advanced technologies all at once, and I’m sure I will look back on this blog one day and shake my head at the silliness of the issues I’m having currently, but well, you can’t make an omelette without breaking some eggs.
I really wish I had a mentor, some guru, someone where I could just ask “am I on the right track? Is this the right approach?” I don’t need much supervision or direction, but just a point in the right direction would be IMMENSELY helpful. So, without that, taking the brute force approach, I thought I’d post a few things that you, as the beginner may want to keep in mind until you are more advanced yourself.
This list will be periodically updated.
* KVO and Bindings are deep and powerful technologies (as is Core Data). Apple has tried to hide a lot of this from you so you can get up and running quickly. That said, it’s still a steep learning curve and it’s difficult to just ‘jump into’ KVO, Bindings, and Core Data all at once.
* Errors and exceptions relating to KVO, CoreData, and Bindings are difficult to debug as the console output of such errors is seldom descriptive enough so to help you track down the problem.
* Core Data entities should have properties that are ‘one thing’, and not a compound property. (else you have to write a bunch of custom code) i.e., if you for example use a Value Transformer to restore a custom object, changes to those objects’ properties will not mark the Core Data entity as dirty, and thus any changes you make to that will not get saved. (unless you are setting these properties after just having added that object to the array, because by definition that object will be dirty.) In slightly more programmer speak, your custom properties (transformable attributes) should be IMMUTABLE, meaning, only changes are registered if you make a call that’s something like
myEntity.myCustomProperty = someValue
NOT,
myEntity.myCustomProperty.maxValue = someMaxValue
* All the tutorials and intros to Cocoa Bindings tout it as this magic thing that will result in you never having to write glue code again! Wrong. F•cking wrong wrong wrong. (At least until you get your head around it!!) I’m actually quite surprised at how terrible some of Apple’s documentation can be on the topic of KVO, Core Data, and Bindings. iOS Developers (which I am, 2 weeks into Cocoa…) won’t have to worry as most of this stuff doesn’t work on iOS. For example, the easiest way to make a NSView subclass that is backed by a Core Data model. I spent AGES trying to figure this out the KVO way, whereas the solution’s approach was briefly mentioned in ONE sentence in a KVO programmer’s guide. (will write a post about this soon)
False Assumptions I have made along the way and what WASN’T true:
– changes to an object in a to-many relationship will notify its parent. (i.e. I change an Employee’s name, the Department will not receive a KVO notification about this. Only if you add/remove employees, will the Department receive an update about this. This isn’t such an issue, but what if your object was a TimeLine with many TimeSteps, who each have a duration property? The Timeline won’t update. Yes yes, this is all in the KVO Documentation, and implementing such updates are non-trivial)