The Leg Bone’s connected to the…???

No matter how many times I tell my four year old back, up she continues to play kiss the door knob. No matter how many times I warn my 9 year old to thumb-tack her book-bag to her spine in the morning, she continues to show up at school sans knapsack. I somehow believe my kids enjoy hard times, appreciate the torture of incinerating your appendages on the hot oven door, and outright live for the moment somebody will come crashing through the doorway embedding the door handle in a young forehead. Then I realize there are certain things that they won’t include in the text books… certain things they won’t teach in class or during an online tutorial. These are the things you have to find out by smashing your nose, breaking your arm, and making an absolute fool of yourself. It’s the first step in agile development is it not? It’s the red before the green-refactor, isn’t it? It is amazing to watch the test driven antics in somebody less than half your age.

Before I allow George Killian to seep deep enough into my blood stream to rip the original intention out of my cerebrum let me explain what I just learned. Apple’s Interface Builder != Springframework. Sure it tastes like apple pie but there are no apples in it. Here’s the deal. You would think (or you would if you wore an argyle sweater like me) that wiring a UIImageView to your controller would be sufficient enough to make that same UIImageView available when you loaded the controller from a nib file in the main bundle wouldn’t you? [Yes you would because you’re me in this hodge-podge example… just play along! I don’t care if you never heard of a nib file. Nod your head and say uh-huh…] Calling initFromNib on your controller will read in the nib file and eventually perform the internal connections/plumbing but your next statement will be in for a surprise if it attempts to inspect or dig values out of the controller that are connected to other things with Interface Builder’s connect the dots magic. Here’s what I mean. Create an arbitrary UIController named LegBone and give it a HipBone IBOutlet property. (Create a HipBone class in your project.) Create a nib file, open it in Interface Builder and set it’s FilesOwner to LegBone. Drag and drop an object from the library into the nib file’s main window and then connect the legbone to the hip bone. In your app delegate, instantiate the LegBone using the nib file and declare a local variable of type hip-bone while setting it equal to the property from LegBone on the following line. Run all of this in the debugger and watch as XCode reports 0x0 (or null, or is it nil? What’s the doggone difference and can we settle on a universal nomenclature for a value that doesn’t exist across all programming languages???!!!) when you step to and hover over the LegBone.hipbone property assignment. It should look roughly like this (not compiled or cross checked due to laziness):

@interface LegBone : UIViewController
   IBOutlet *HipBone hipbone;

@property (nonatomic, retain) IBOutlet *HipBone hipbone;

@implementation MyAppDelegate

- (void)applicationDidFinishLaunching:(UIApplication *)application {
	LegBone *myLeg  = [[LegBone alloc] 
								 initWithNibName:@"LegBone" bundle:[NSBundle mainBundle]];
        HipBone *hip = [myLeg.hipBone];
        NSLog(@"My hip is %@", hip);

Of course after catching the problem the obvious thing to do here is to instantiate the hip in your delegate and set it on the legbone since Cocoa is too lazy/slow/unwilling to do it for you. That brings me to my next surprise. I caught this immediately afterwards but it could have easily been one of those 2 day investigations that check everything but the obvious. Setting the hip bone programmatically without clearing the connect-the-dots magic in InYourFace Buildher will only be undone by the runtime when it finally gets around to connecting your dots during runtime. In other words, say you have this:

@implementation MyAppDelegate

- (void)applicationDidFinishLaunching:(UIApplication *)application {
	LegBone *myLeg  = [[LegBone alloc] 
								 initWithNibName:@"LegBone" bundle:[NSBundle mainBundle]];
        HipBone *hip = [[HipBone alloc] init];
        myLeg.hipBone = hip;
        NSLog(@"My hip is %@", hip);

And pretend you forgot to remove the HipBone object in Innerplace Biller. You’ll fix the nil pointer in the app delegate but then inside LegBone you will be talking to a different hip. For a beginner like myself, trial and error will likely never show the core problem. You have to know what to look for. You have to know that wiring is performed at runtime and possibly at a later stage or in an entirely different method. It’s like Dr. House says, “When something doesn’t make sense, one of your assumptions is wrong.” In this case you would assume that initializing a controller from a pre-wired nib will instantiate all of your nib file’s internal objects and prime all of the setters. You would assume that these things happen before control returns to the next statement as it would if you were loading a Spring beand factory and asking for a bean. That’s all for now. I’m going night-night.

Murder me!

I’m spending too much time trying to figure out how to assert that a string is properly URL encoded! I refuse to take the traditional approach of running code in the application and peeking through debugger goggles or some obscure log output. Unit tests are made for this sorta thing! I’e had some tips that suggest how to perform URL encoding but experience teaches me not to trust any particular tip unless I can confirm it in a learning unit test. That’s how I self-educated myself on Ruby over the weekend. I wrote a bunch of learning tests to confirm every code snippet I read online. So why is it that when I assert @”ab%%c” == @”ab c” the error message echoes back “ab != ab c”??? I’m using Google tools for Mac to run iPhone unit test suites.

One other thing… could somebody please invent/has somebody invented an “automatic add new files to svn” plugin for XCode? If I botch one more commit my team is going to cut off my water supply and replace my contact lens solution with Windsor’s clear hot sauce. I love the clear stuff because I can dump a whole bunch on my meal without my wife nagging me about my heartburn.

Objective C, Almost closures?

I’m about toe deep in ObjC and Cocoa and I’m starting to get that warm fuzzy feeling everytime I message and object without needing a type cast. I get really warm/fuzzy when I use @selector() to throw extra executable logic from a long running process back onto the main thread. Now I’m thinking about the @selector idea and wondering how close it is to closures. I’d like to be able to define a method on an interface… *ahem* …protocol that takes a selector as a form of callback. Though Cocoa makes extensive use of delegates I don’t want to haff to set a delegate instance variable and define another protocol for something as simple as an inlined callback operation. In other words I wanna say: “Mr. Object, do dis stuff when your data becomes available.” Back into the manuals to learn about @selectors.

The Backward Guide to Ruby Cocoa

First pretend you’re an Objective C professional and jump into iPhone development. (It helps to have absolutely no experience at this step.) Next, act over zealous about Test Driven Design and find the only unit testing framework that’ll half run against an iPhone project, one that just happens to be implemented in Ruby. Throw in a deadline just for fun You now have a recipe for achieve great feats in all things Ruby/Cocoa related and can now complain to your coworkers how stoopid Ruby is because it can only seem to intermittently find your method that is OBVIOUSLY defined on an objective C class you wrote moments ago.

Dumb Ruby programmers! How can anybody claim this technology is superior? Who cares that you didn’t read the documentation? Didn’t Joel say somewhere that users don’t read docs? Why can’t this stuff be easy enough to just pick up and use out of the box? After all if this were Java or Groovy you’d be finished by now!

Mumble a few more obscenities or discouraging words of condemnation toward the ultimately inferior platforms written by those who label themselves Rubyists or Cocoaists or whatever and then Google the thing you’re trying to do. What’s that towards the top of the page about how Ruby/Cocoa bridges work? Paraphrased:

The average idiot will note that RubyCocoa uses the Libffi library to call the Objective-C methods implementations. That means the first method call will go through the #method_missing mechanism, you moron, and then the Ruby method will be defined on the Ruby proxy class, thus allowing all (initial queries to Obj C classes to not know about the method while) further calls to be direct, and faster.

The best way to drive a developer nutz is to tell him something doesn’t exists when he/she is absolutely certain of the contrary. Go against logic. 1+1!=2, set a = b and (a == b) == false, function fooBar cannot be found because function fooBar is defined. There are plenty of other examples I’m sure.

Yes genius, you are attempting to learn Ruby Cocoa from the ass end. You know this but you are too arrogant to admit it, even to your significant other. Sure you’ll lie in bed and discuss things like how was work. The typical conversation leads you into a rambling session beginning with, “I had a bad day…” with you trying to explain to your incoherent loved one why things are getting you down. You can’t admit failure at this point as your loved one is lying, waiting for your to reveal weakness… any weakness that will serve as ammo in the next argument when you forget to cut the grass or have to run partially clad after the trash truck that powers away mercilessly from your residence because you had too many Bud Ice’s the prior night and passed out with that uncomfortable feeling that you knew you needed perform some important task but what the heck is it? No need to explain that you can’t perform your job because you skipped the fundamental steps required (actually learning the technology) to be productive in any capacity.

No worry, you can learn this stuff after you’ve used it. Learning is for sissies anyway, right? Who takes a class on starting an IV before declaring themselves a qualified Phd? That’s utter nonsense isn’t it? Just jam the damned needle somewhere close to the greenish looking line thing running down the arm and you’re all good! After the lawsuite begin you can enrol in Lincoln Tech and figure out why the deadly infection began in your first and only client. Yes we learn after we’ve trash talked the entire industry because it’s everyone else’s fault by now. The APIs should be written in a way that require no knowledge acquisition!

Disclaimer: The entirety of this article is meant tongue in cheek, while I appreciate all feedback positive and especially negative, don’t waste your time claiming Ruby and/or Cocoa is the best thing since Parish Smith got back with Eric Sermon. As a lover/consumer/advocate of anything programming related you’ll be preaching to the choir or buttering the tub of Land ‘o Lakes… you’ll be mowing the lawn mower… spray painting the brush, redundantly repeating the repetitive, repeatedly, or threading the thread spool. Save your keystrokes and don’t respond.

Titles, Strings, and Threads

I just got bit by a subtle Objective C bug. I’m writing a basic application that starts an asynchronous counter that updates an onscreen label. Common sense would suggest pseudo-code like this:

   if button title = "Start"
      set button title = "Stop"
      set button title = "Start"
end onButtonPress

The problem is this. The UIButton class in Cocoa has a read only currentTitle property. There’s no writing to this property however you can write to setTitleForState and pass a UIControlStateNormal enum. (Why do I hate enums?) So I’m thinking it’s enough to query the currentTitle property and then set the title for the normal state from “Start” to “Stop”, right? Wrong! Somehow the currentTitle property hangs onto the original value and instead I should be querying the titleForState: method instead! Can you tell I’m missing the JDK?