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.
An Index In Your Head
It’s been a month since I said that this blog would have a new direction and I haven’t posted anything meaningful on the subject. Let that not reflect on the subject matter, since there has been plenty that I meant to write about. I just… got side tracked.
So what have I been doing? Well, summer is never the most productive time of the year, but I have found some time to sit myself down and try to figure this thing out.
My main study guide has been Aaron Hillegass and Mikey Ward’s Objective-C Programming (2nd Edition). I found this to be a good place to start due to what it is not. It is not a book on how to make iPhone apps. The arcane incantations that get Xcode to work are only touched on briefly. Mostly this book aims lower. Start at the language. How does Objective-C work? What is Object Oriented Programming, and how does Apple want you to use it? What is going on in memory while your code is doing its thing? How the fuck do blocks work?
It remains to be seen whether this detour was worth it. There’s still plenty I don’t quite grok, but I’m betting that once I’m done with the text books and sample code, just having read these books and having a rough index in my head will be helpful.
Parlez-vous Swift?
So here I am ready to make an iOS app from scratch, except that I have no idea how make iOS apps (or apps of any other kind, for that matter). But I do know that you need to program in Objective-C, a language developed largely by NeXT in the late 80’s, adopted by Apple in the early 2000s, and used today mostly to make apps for the iPhone. So I bought a couple of books and set to work learning the basics.
Every year, just as summer is getting under way, Apple hosts their World Wide Developers Conference, where they lay out their current thinking on the best way to make apps. There are new technologies introduced, lessons available, and for those of us who can’t take a week off to fly to San Francisco, they put videos of everything up on line. Knowing this was coming up, I thought I could focus on learning the basics of the Objective-C language, as the higher level elements were likely to change.
Then Apple upended everything. Objective-C, they said, is no longer the only way to make apps for their devices. Swift was a brand new language created in secret by small team inside Apple. It was modern, they said, and apps built using it would be less likely to crash.
That’s all well and good, but I was just starting to get a hang on the old way! Did I now need to start from scratch? How would I even do that? Swift was brand new, and the only way to learn it was an ebook that Apple released that was clearly aimed at people with a better understanding of how computing worked.
After spending roughly a week paralyzed with indecision about which path to take, I picked back up the book I had been working on. For the time being, I’m making this app the old fashioned way. A couple of points factored in to this decision.
- Swift is really new, and was created by a very small (though I’m sure very smart) team inside Apple. Now that there are hundreds of thousands of developers poking around through it, I’m sure they’re going to find bugs. And I’m sure that Apple is going to fix some of those bugs, meaning that the language is going to change quickly. Behaviors you can expect today might not apply a year or two down the road. That could cause problems that I’m not confident I’d be able to detect.
- Objective-C is old. In some sense, that means it’s creaky, and there are some difficult concepts to grok that are papered over in newer languages like Swift. But it also means that it is well tested, and that it’s peculiarities are well documented. If I have questions, it’s pretty easy to google the method names I’m working with and find explainers, and other people who have had the same issues. Answers are abundant, and if I can’t find them already existing online there are tons of people with experience working with these technologies that I can ask.
- I already have the books.
- Swift and Objective-C code can live side by side. Apps are written as smaller files that are compiled and combined into that neat little icon on your phone. You will be able to Objective-C and Swift files together in the same app to solve different problems. That is exciting because it means I can start today in Objective-C, and then start adding Swift files in the future once I see that it is starting to mature, and I won’t have to go back and redo everything I had already built.
- Swift is clearly the future, but Objective-C is not yet the past. It’s still being used by Apple itself for most everything, and likely will be for years to come. That means it’s not going to go away any time soon. I don’t think we have to be afraid of Apple coming in next year and saying that all submissions must be Swift-only. This is going to be a slow transition, and the end state is going to be a world where Swift is the preferred, but not only language.
So on a beautiful Saturday like today, I am hashing this around in my head, and I think I’ve finally convinced myself. Now that I’ve gotten this off my chest, I can go enjoy the day.
Nothing Was Delivered 