Cocoa Crunch (Day 3)

I’m getting faster

Every day around lunch it feels almost impossible to finish all five chapters for the day, yet every day I finish earlier and earlier. I feel my confidence returning rapidly and having such a short period of time between lessons makes it easier to understand relationships between concepts, and to see how ideas may be combined in my own software. Everything still feels fresh in my mind and coding experiences are building upon one another, rather than being a mere sequence of experiments. I am enjoying this “Cocoa Crunch” immensely. After this, I am considering going through the Stanford iPhone classes in similar fashion; maybe three classes a day for a week.

Core Data, NSImage, and Bindings

Doing the Core Data lesson, Chapter 11, resulted in an error that binding an Image Well to the “Data” of an object is deprecated in 10.6. As my definition of “done” for this crash refresher course means that my code compiles with no warnings, I need to address this point. Apple says we are to bind to “Value”, which Aaron explicitly addresses as the field NOT to bind to. “Value” expects an NSImage, where “Data” expects an NSData object; Core Data only lets us define an NSData attribute for image storage purposes. So, what to do?

The solution seems to be in “Value Transformers”. Create a new class and implement “transformerValue:” and “reverseTransformedValue” to accept NSData objects and return NSImages (and vice-versa). Register this transformer through the “initialize:” function of your AppController (although, I think we could do this with the standard template “App Delegate”, or in any of the XIB-instantiated custom objects). Once registered, you can choose it as a Value Transformer in the Bindings panel to handle NSData<–>NSImage conversions. I will post my solution in the Codeshare.

Core Data is awesome (but I don’t get it)

Chapter 11, “Basic Core Data”, has proven to be the least useful lesson thus far. What is difficult to understand how to use Core Data in my own application as a driving data source. In the past I used frameworks like MySQL-Cocoa and had great success. I’m unclear where Core Data supplants or complements this process.

One of the things that Core Data and Bindings (in particular) makes frustrating is how the wiring is very hidden from developers. I find it too secretive and too “Just let Apple take care of it for you.” At this level, I really don’t need the handholding and the truth of the matter is I’m often overriding the basic functions anyway to add hooks and triggers to more interesting events.

In the long run, I’m not sure I’m saving myself very much time and code and am instead obfuscating just enough functionality to make my own code harder to understand. The bindings don’t help me capture intent the way well-written/documented code does. I’ve bound this text field to turn red when this other object’s value is negative. OK, great, but WHY did I want it to be red? If the app has “no code”, where do we document these things?

So as far as I can tell, I can’t bind to a .h file with extern consts and #defines and enums that describe an internal nomenclature for my app. Things must bind to other, instantiated THINGS, which means creating ivars in an IB object just for binding purposes. Is this saving me time and work?

Unless you want to build a Core Data application with no code and have a program that functions exactly like the Core Data examples, I fail to see the utility of the Core Data + Bindings examples.

NSBundles and dynamic class loading

From page 195 of Cocoa Programming for Mac OS X, 3rd Edition, the idea of dynamically loading in classes from other bundles in my app is an awesome power that I know will be used heavily in file_wrangler_2. I have a bit of a “plug-in” approach in mind and this seems to fit the bill nicely.

Leave a Reply

Your email address will not be published. Required fields are marked *