Archive
Choosing NSDictionary Keys
Say you’re creating a dictionary in Objective-C. The idea is that you have two objects that you want to link, where whenever you reference the one (a key), you get in return the other (the value). For example, you’re car shopping, and you’re writing a little app to help you pick which car you want. So you create some Car objects, and then go about classifying them. You pick some criteria, like “fastest car” and “most cup holders”, and you want each to reference the appropriate car. And you want all of these together, in one place, so that you can pass this dictionary around and make some kind of checks.
What do you use as the keys for this? NSDictionary has some pretty strict requirements as to what object can be a key, so most of the time the easiest option is an NSString. I guess you can just create some string literals, and use something like @“fastestCar” and @“mostCupHolders”. But that just looks… messy. You could initialize a string like NSString *fastestCar = [NSString stringWithString:@“fastestCar”] , but again, that seems like overkill. It would be nice if you could use an enum, but NSDictionary requires an object.
I noticed that for Apple’s use of imagePickerController, you’re passed a dictionary when the user choses photo. That dictionary contains the image itself, as well as some metadata. What was interesting to me was the keys seem were clearly objects, but really the type was arbitrary. All we were concerned with were the names, which were characteristically descriptive (e.g. UIImagePickerControllerOriginalImage).
Looking at the declaration, it appears that it’s defined as an NSString * const. Is there a string built in there? Not as far as I can tell. And it wouldn’t matter if there was.
The object, I learned cannot be nil, but it doesn’t have to actually be some arbitrary string either. Simply declaring NSString *const fastestCar = [[NSString alloc] init]; is enough. You’ve got an initialized NSString that makes a valid key.
Why bother? It’s not going to make a huge difference to your code’s readability, but it can lessens the cognitive burden of having to figure out a placeholder string, and it just looks cleaner than throwing string literals in there every time you want to access a value. It’s boilerplate, but it can be worth it if you’re going to be reusing this key more than a handful of times.
Objection Oriented Programming
A while ago, I saw a blog post from an experienced programmer lament that younger guys use Object Oriented Programming for everything because, well, that’s how they’re taught now. Often that makes sense, he explained, but sometimes you just want a quick script to do a task and be done with it. What the younger programmer could do in 20 lines of code this guy could do in 10 by getting rid of the object boilerplate.
I haven’t been doing this long enough to form any habits, but I do have some scripts that I’ve been using for a while at work. They mostly do one thing, They’re not pretty, but they work.
Then, I found myself wishing one of them did something else too. Or maybe instead of. Maybe I could add a small flag to change a behavior. That seems like it’s within my skill set.
Except, since it is just a 100 line procedural script, there’s really no way to break it out into base parts and change its behavior under certain circumstances. So I basically started tearing the script apart and putting it back together as a class, which I can then add methods to and call as I need. It’s not only that this will let me get my desired outcome today, but that this will make it (kinda) easier on me down the road, when I get further grandiose ideas.
The lesson here isn’t, I think, that one should always use OOP (or Functional Programming, if that’s your bag) for everything. The lesson is to think about the future, even with something small. If you’re writing a script that you expect to keep using down the road, try to future proof it as much as you can. Your needs will change over time, and that’s okay.
Ooey-GUI
I saw someone on Reddit recently say that there are four stages to learning to program. I can’t find the link so I’m going from memory, but roughly, they are:
- The rush of excitement in learning something new – In this stage, you there are plenty of tutorials and hand holding.
- Venturing out – You are newly confident after having grasped the basic concepts. You can read (some) code and get an idea of what it means, and if you are not sure, you expect that you can look it up and figure it out. Sure, there are some areas of code that look impenetrable, but you are confident that you’re just missing a few more basic concepts and you’ll be able to understand them easily enough.
- The Wasteland – Now you want to do something non-trivial, and all the documentation still seems over your head. Everyone seems to know more than you do, and none of the tutorials are aimed at your level. They are either directed to newbies at stage 1, or they are directed to experienced programmers and assume that the reader has already worked with something similar, so they explain only what is unique about their implementation.
- Actually having some idea of what you’re doing – If you manage to somehow get pas the Wasteland, your confidence builds again, and one day you realize that you actually are able to build non-trivial systems.
I think the first three stages make a lot of sense. I’m not sure at this point if number four actually exists, or if it is just a cruel joke. I will say that there does seem to be a huge gap between the trivial (“Hello World!”) sort of programming and the more complex programming required to make what the average person on the street would recognize as software.
Modern software is complex. It does a lot, and everyone has expectations from years of using professionally created applications. This applies to mobile as well. It’s crazy to think that the iPhone launched 8 years ago. Everyone who’s been using a smart phone for even a fraction of that time has an idea of how an app on their preferred platform should look, act, and, more importantly, feel.
So what I’ve learned this week is that building GUI is really hard. Sure, you’re probably working with an SDK, so at least you’re not reinventing the wheel, but this is still hugely complex, with a lot of nuances. It’s hard to keep all of that in your brain at once.
Right now I’m working my way through the Big Nerd Ranch’s book on iOS Programming. They do a fairly good job of speaking in plain English–of helping you past the Wasteland. But it’s tough. I just finished the chapters on UITableView, a super common and relatively basic design. No bells and whistles here. Just a pretty standard list. And I’ve spent a good week trying to figure out a few challenges they give you. Move the items around the list. Create one item at the bottom that doesn’t move. You wouldn’t think this would be so hard. But because you’re not just dealing with variables and simple operations, but instead a whole mass of interconnected objects, things don’t behave the way they do in those first few tutorials. Intuition goes out the window. You’re basically left with trial and error.
Sometimes that’s good enough. And I get a feeling that more programming—real programming—is trial and error than anyone would ever admit. And through that method, I have almost completed the challenges. Now I have just one more simple method to master.
Nothing Was Delivered 
