Thoughtful Pixel

Bitwise operations and bitmasks are frequently employed in Cocoa. For instance, most methods that have an options: parameter require a bitmask.

But what are they and how do they work?

Integers in C/ Objective-C are encoded as Two’s Complement, allowing the processor to perform arithmetic calculations directly in binary.

1 = 00000001
2 = 00000010
4 = 00000100

By treating each bit as a “column” indicating an on (1) or off (0) position, an integer can be used to indicate multiple options simultaneously. When used like this, the integer is called a bitmask.

More usefully, bit masks can be combined and compared using operators. For instance, the bitwise OR operator creates a new bit mask by creating a 1 in all positions where either component number contains a 1:

// (decimal)    (binary)
     3            00011
   | 5          | 00101
   => 7        => 00111

Meanwhile, bitwise AND creates a bit mask with 1s where both numbers have a 1:

// (decimal)    (binary)
       3          00011
     & 5        | 00101
    => 1       => 00001

Bitshift operators << and >> simply mean “shift everything n bits left or right”:

// (decimal)       (binary)
    1 >> 2         00001 >> 2
 => 8           => 00100

To put this all together take a look at UIView. Apple’s documentation defines an enumerated property for the way a view should be automatically resized:

enum {
   UIViewAutoresizingNone                 = 0,
   UIViewAutoresizingFlexibleLeftMargin   = 1 << 0,
   UIViewAutoresizingFlexibleWidth        = 1 << 1,
   UIViewAutoresizingFlexibleRightMargin  = 1 << 2,
   UIViewAutoresizingFlexibleTopMargin    = 1 << 3,
   UIViewAutoresizingFlexibleHeight       = 1 << 4,
   UIViewAutoresizingFlexibleBottomMargin = 1 << 5
};
typedef NSUInteger UIViewAutoresizing;

Because they’ve defined this enum using a bitshift, these options can be combined using a bitwise OR to define how a view should automatically resize:

myLabel.autoresizingMask = (UIViewAutoresizingFlexibleLeftMargin |
UIViewAutoresizingFlexibleRightMargin);

Moreover, the bitwise AND operator can be used to check the state of the autoresizingMask:

if ((myLabel.autoresizingMask & UIViewAutoresizingFlexibleLeftMargin ) ==
UIViewAutoresizingFlexibleLeftMargin) {
   // do stuff
}

Should you use enums and bit masks in your own code? Some advise against it. However, Apple makes extensive use of them in Cocoa Touch. At the very least, it helps to understand what’s going on.

Cocoa Touch development often requires the use of Core Foundation (CF), a plain C API originally conceived to ease the transition between Mac OS9 and OSX. This is because Cocoa Touch classes make use of CF types rather than their Objective-C (NS) equivalent in Cocoa’s Foundation framework.

Take the Address Book. It stores a Person as a structured type called ABRecord which is derived from Core Foundation. To retrieve a person’s first name from an ABRecord you need to do something like:

CFStringRef string = ABRecordCopyValue(person, kABPersonFirstNameProperty);

However to do anything useful with that string (like displaying it in UITextField), you’ll usually want an NSString rather than a CFStringRef.

Fortunately Apple has made this relatively painless by allowing many (but not all) types in Core Foundation to be cast to their Objective-C counterparts and vice-versa. This is commonly known as toll-free bridging. For instance NSString, NSDictionary and NSArray are bridged to CFStringRef, CFDictionary and CFArray respectively. So with ABRecord, we can do something like:

// where firstName is an Objective-C property pointing to a UITextField
CFStringRef name = ABRecordCopyValue(person, kABPersonFirstNameProperty);
self.firstName.text = (NSString *)name;

Toll-free bridged types and objects actually employ the same data structures, and Apple has ensured each API has the requisite logic to act like the other. If you want to know how this works under the hood, Mike Ash has a good explanation.

If you find yourself working with Core Foundation, take a look at the documentation to see if your type is toll-free bridged to it’s equivalent Foundation class.

Rather than casting directly, consider using a helper like Uli Kusterer’s UKTypecastMacros. This makes your code safer and easier to maintain.

Happy bridging.

Last weekend I attended the London iPhone Boot Camp in South Kensington. Billed as “a three day intensive workshop, over 24 hours of training” covering both fundamental and advanced features of the SDK, it aims to equip participants with enough skills to develop their own app and upload it to the App Store.

Developed in New York and initially delivered by the likes of Stephan Kochan and Jeff LaMarche, the London course is run by Charles Gamble who has rewritten the materials from the ground up. The venue comfortably accomodated the ten of us, a motley mix of beginner and experienced developers with a common desire to build iPhone apps.

I suppose boot camps are supposed to be ’intensive’, but it’s definitely an apt description. The course covers everything from patterns, memory management and UIKit fundamentals to MapKit, web services, archiving and threading.

By the end of the three days we’d built a simple but non-trivial location-based application, which I must say is more presentable and useful than many apps on the App Store.

Charles has done a good job with his material: it’s comprehensive, presentable and well-written. However, with only 24 classroom hours to cover it all, the schedule is very agressive. As it was we worked into the evening on the second and third day and there were still times we’d walk through sample code rather than writing it ourselves.

I felt tired but very comfortable with all the concepts and exercises. Charles is a great teacher. He’s patient and has a talent for explaining abstract or difficult concepts clearly and concisely without condescension.

Anyone unfamiliar with basic programming constructs including patterns and OO would struggle. Before turning up I’d worked my way through a good portion of Aaron Hillegass and Joe Conway’s book which, along with a few years tinkering in Java, Ruby and Javascript, definitely helped.

With varying skill levels in the class, Charles was always going to have trouble pleasing everyone. The first half of the course was a too slow for my liking. I was disappointed we spent so long on fundamentals while more advanced topics like Core Data and Core Animation were just skimmed on the third day. Performance optimisation, build and distribution weren’t addressed until the last hour or two, so coverage there was also cursory. The syllabus doesn’t extend to topics like UX best practices or OpenGL, but there’s no way it could given the time allotted.

I’m not sure I walked away with the skills required to build an iPhone app I’d be proud of. However that sort of confidence comes from experience, not seminars or workshops.

The main benefit of the London iPhone Book Camp is the opportunity to develop something under the tutelage of an experienced practicioner.

In my day job, I’m surrounded by smart and learned folks from whom I regularly learn and bounce ideas off. In contrast, learning iOS development after hours can be a fairly solitary pursuit.

If like me you’re struggling to consume a mountain of books you bought off Amazon or work your way through Apple’s documentation, set aside a long weekend and sign up for the London iPhone Boot Camp.

It’s a worthwhile investment.

For a long time, I thought I sucked at programming.

I’ve no formal training. After a Psychology degree and a few misspent years, I got my start training others to use a well-known piece of corporate software. I was acutely aware of my limitations and I was certain I couldn’t build the stuff. I hacked a little HTML and VBScript where I could, but I had no hope of being a Real Programmer.

Shortly afterward, I joined a company that made software tools. Suddenly I was working alongside folks who dreamt in code. Armed with a compiler and a text editor, they could create anything. It was magical. I was in awe.

With an affinity for people, I carved a niche interpreting customer requirements and using our proprietary tools to build systems. I was pretty good at it too. But when a problem required a real programming, I’d demure. That was a job for someone who knew what they were doing, not a pretender like me.

Over the years I got comfortable with those proprietary tools.

It was hard at first and I made a lot of mistakes. When they didn’t work as expected, I tracked down the problem. I spent many hours discovering bugs and learning their idiosyncrasies. I mastered them. Few people understood them and they ended up fuelling a well-paid consulting career.

But I still couldn’t code.

One day, my hand was forced. With a looming deadline and nobody to help, I had no choice: I had to learn. So I did.

It was hard at first and I made mistakes. When it didn’t work as expected, I tracked down the problem. I spent many hours discovering bugs and learning language idiosyncrasies. I haven’t mastered it, not by a long shot. But there was nothing magical about it. It’s just code.

I had the capacity to do it all along; I just wouldn’t allow myself to believe it.

All I needed was to give myself permission. Permission to try.