Chapters 26-30 of Cocoa Programming for Mac OS X, 3rd Edition revealed unto me three truths!
Signing Amazon requests is hard
Chapter 28 is pretty much defunct as Amazon now requires that all REST requests be signed with a secret, private ID. I thought, “Aha, a challenge!” and set to work building a protocol for NSURL that takes and NSURL and a private key and returns the signed NSURL for Amazon’s services. My word was that hard!
In fact, so hard I never could get it to work, mostly because I don’t have much experience with REST, base64 encoding, nor SHA256 HMACs. In fact, it may even be safe to say I had ZERO experience with those technologies, and it is difficult to build something you don’t understand. (ahem)
But, Amazon lays out a step-by-step on how to sign the URL and for the most part it was straightforward and seemed to work properly. However, when it came time to generate the HMAC and encode that in base 64, I quickly learned what a troublesome process that is. At least if we consider it from a “pure Cocoa” perspective.
After referring to various online forums and postings about the problem, a CCHmac (a non-Cocoa system call) seemed to finally work for me. Oddly enough, getting the base 64 version of the returned string was the troublesome, and yet unresolved, issue.
After much digging around, it seems that the very smart Marc Liyange was struggling with the same issue and wrote a nice Cocoa wrapper class for the whole shebang, leveraging Google code to get the job done. I was really hoping I could just use NSTask to make a command line call to something built into the OS. OpenSSL with “enc -base64″ flag, I’m looking at you…
Which leads me to…
A retrospectively obvious point about NSTask
I had chained up two NSTasks with an NSPipe to get the standard output from TaskA to flow into TaskB, the same as piping the two commands in terminal. But nothing would flow from TaskA to TaskB. Every example for NSTask I could find only showed a single task and retrieving the basic output stream from that. That was easy enough. Any samples that showed TWO tasks in a chain said something like, “Just make two NSTasks and pipe them together, or better yet do this completely other workaround.”
Today it finally hit me that after building an NSTask / NSPipe / NSFileHandle chain, then kicking off the first NSTask with [task launch], that that is not enough. I thought this would launch the whole kit-and-kaboodle, but each individual task must be launched individually. It just never occurred to me that every link of the task chain needed separate kickstarting.
Today’s work on chapter 34 led me to reattack this NSTask conundrum I had encountered the other day, and finally the light went off. I may have hope yet for getting my homegrown Amazon wrapper protocol wrapped up tomorrow, which would be a great ego boost to know I solved an issue that also stumped people I respect.
I still don’t get Core Data
Maybe it is because I rarely write applications that need something like Core Data? Chapter 30 has us building a more involved Core Data application, and the number of bindings is bewildering. Knowing whether to bind an object to the Model Object Context, the model’s Content, the model’s Content Set, the model’s Content Values, or the model’s Value is an utter mystery to me. What was most frustrating about this chapter is that I have no clearer understanding of why certain things are bound to other things and why we chose certain settings in Interface Builder. The chapter does a (frankly) poor job of illuminating Core Data.
To my mind, if Aaron Hillegass has trouble getting Core Date across to his readers, then that really means that Apple has made it difficult to get across to developers. I haven’t given up on Core Data by any stretch of the imagination, but I do feel a little bit that it will be a HUGE amount of study and understanding for very little payoff. I’d rather dig into Core Animation or Core Graphics (or OpenGL) if I’m going to invest so much time.