4 Things I’ve Learned Teaching Objective-C

Recently, here at PMG, we hired a new developer, Hector Matos, who only took his first few steps into software development barely more than a month ago. He started out by tackling one of the most difficult of the basic programming languages, C. As, the only developer on almost all of the native mobile projects here, I was given the privilege of being the one to work with him, and teach him how to develop for the iPhone. Seeing as I’ve never taught anyone before, ever! This is a completely new experience for me. Funny enough, it’s been almost as much of a learning experience for me as it has been for Hector. In realizing this, I figured I should write a list of the different things I’ve learned (or in some cases been reminded about the importance of) about Objective-C, and programming in general, while doing my best to teach it all to our newest team member.

Now, I’ll admit, I actually knew how to use a modulo prior to beginning my teaching.  But, I had no idea what it was called or anything. Of course, this probably seems extremely basic to most of you, but I never actually made it past Geometry in High School, so, for me, this is something clever and new.

If you don’t know how to use the modulo operator, or what it’s even for, it’s really quite simple:

bool isOdd(int a) {     return (a % 2 != 0); }

Above is just a simple function that checks if the integer passed in as an odd number or not. Basically, if you think of the first number as the dividend and the second as the divisor, what a modulo will leave you with is the remainder. So, in the case of our function, it will return false if the integer passed in does not have any remainder when divided by 2, thereby meaning it’s an even number.

Now, technically speaking, Objective-C doesn’t have true private methods. This is partly due to the fact that C itself doesn’t actually have true private methods. It is also because Objective-C is still largely in development as a language, and so far there hasn’t been a lot of demand from the developer community for a way to create truly private methods.

Fortunately, if you ever find you have want for a private-like method in Objective-C. One way is to actually write your “private” methods as static C methods within your Implementation file:

@implementation MyViewController

static void doSomethingPrivate();

// Implementation of public methods

static void doSomethingPrivate() {
NSLog(@”This is a “private” method”);
}

@end

You have to put both the declaration and implementation of any “private” method inside of the implementation file. By doing this no other files can actually see the declaration of your method. Just remember that these are static methods, if you want your “private” methods to be able to perform any logic on your instance, you’ll have to pass the instance to them as a parameter.

Another way, this is what I prefer to use, is to use a Category. By creating the interface for a Category of your Class inside of your implementation file, you make it so that the only code that can see that Category is the code inside of your classes implementation.

@interface MyViewController (private) // You could actually make it empty between 

// these parens if you prefer it that way

 - (void)doSomethingPrivate;

@end

@implementation MyViewController
– (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
if (self) {
[self doSomethingPrivate];
}
return self;
}

– (void)doSomethingPrivate
{
NSLog(@”This is a “private” method”);
}

@end

This works better than static C methods in two ways. First, it doesn’t litter your code with random C methods that create random lines of almost completely different syntax, and also, the methods are actually specific to an instance, so you still have a reference to the current instance via “self”.

Another thing, some code you can find out there will show you that you have to create a second @implementation along with the @interface for your “private” Category. That’s actually not necessary, and in my opinion, there’s just no need to have two separate implementations for your “public” and “private” methods. It works perfectly with only one; it doesn’t really add anything to the readability of your code to have two. So, I say one is perfect.

These are a really cool feature of iOS that were added in version 3.2. Funny enough, I didn’t even know they existed until one day, when working with Hector on a UIScrollView that we were trying to add some special tap functionality to. He decided to drag a Tap Gesture Recognizer out of the objects and place it on the Scroll View. They’re easy enough to implement. You can set the requirements for the gesture, as well as the selector to be called when the gesture occurs on the view it is assigned to. Here’s how to implement one programmatically:

- (void)viewDidLoad

 { 

[super viewDidLoad];

UITapGestureRecognizer *doubleTapGesture;
doubleTapGesture = [[UITapGestureRecognizer alloc]
initWithTarget:self
action:@selector(doubleTapOnGestureView:)];
[doubleTapGesture setNumberOfTapsRequired:2];
[doubleTapGesture setNumberOfTouchesRequired:1];
[self.view addGestureRecognizer:doubleTapGesture];
[doubleTapGesture release];
}

– (void)doubleTapOnGestureView:(UITapGestureRecognizer *)sender
{
NSLog(@”You just double tapped the view!”);
}

That will create a Tap Gesture Recognizer, that will call its selector whenever a double tap is performed on the main view. Simple enough, right? You can also make Gesture Recognizers for a Pinch, Rotation, Swipe, Pan, or even Long Press Gesture with pretty much the same logic.

Lastly, I’ve been reminded on a number of occasions how important it is to always be careful about properly managing the memory of your objects. You see, in my current project I decided to try using ARC. So, I’ve ended up getting a little too used to not needing to watch my releases. Personally, I don’t see any real benefit to continuing development using ARC. You still have to understand reference counts, and in my opinion, it just starts turning you into a lazy programmer. Due to this, I’ve been caught on a number of occasions, leaving out releases, and entire dealloc methods, when working with Hector on something. Causing him to have to go back in to clean up after me.

One thing I’ve realized lately is how helpful it is to understand what kind of reference the Cocoa framework is actually holding to an object you pass it. For instance, we were working with adding Annotations to an MKMapView. Being one of the times I remembered to properly manage memory, I actually told the Annotation to be released after passing it to the Map View. Unfortunately, I didn’t realize that the Map View only keeps a weak reference to the Annotations passed to it. So, when I released the Annotation, I left the Map View with a reference to a released object, thereby causing the entire application to crash.

In the end, I created a simple NSMutableArray, held by the Controller. Whenever I created the Annotations I added them to both the Array as well as the Map View. That way I could release the Annotation in that method, and the Array would hold on to the reference, until I was ready to release the Array in the dealloc method.

It just goes to show that teaching can be just as much of a learning experience as being taught. It’s always a good idea to share your knowledge with people, you never know what you could learn by teaching.