*** Update: Paul Taylor (@guyinthechair) has a more recent post on the same subject. ***

*** NOTE: I’m a n00b at Cocoa and Objective C. Unlike Python, I don’t like learning it, either. If you perceive something below is inaccurate, please comment, and I’ll update. ***

Preface

I was having a lot of fun using the iPhone packager. Then Apple changed their licensing to prevent people like me from using ActionScript for iPhone/iPad, and instead being forced to use their toolsets, or those unofficially approved. At first I was furious. Then I tried to get a simple list to scroll in AS3. Even using a fake mask, device fonts, and cacheAsBitmap for all items + container, it just wasn’t smooth, even with just 30 items, regardless of frame rate. If you use an out of the box UITableView in Cocoa, it “just works”.

I built my career on Flash Player because “it just works”. It doesn’t “just work” on the iPhone, and now it’s effectively illegal to use. That, and Adobe has apparently abandoned ship on the iPhone/iPad/iTouch portion, and instead are focusing on Android.

I was amazed at what I could do using Flash Lite 2 on my Nokia 6680 3 years ago. AS3 was all the rage, and yet I took the time to build a component framework in AS2 for use on devices because I felt it was “good enough” to build experiences for consumers. That market never materialized unless you targeted Japan (which I didn’t).

After finally getting my simple SWF to compile to the iPhone, I was estatic at how easy it was to design & code in what I knew, it just worked, and looked like I expected it to. Once I started moving things via TweenLite, though, it all went downhill. I don’t have these problems in Flex. If I use a List control in Flex, it just works; I don’t have to be an AS3 game developer to theorize on GPU acceleration possibilities to get the best list scrolling performance. I don’t have these problems, at least from what I’m initially seeing in my early learnings, with Cocoa.

So, I’m learning Objective C so I can execute the ideas I have for iPhone and iPad. Unlike PHP, Ruby on Rails, and Python & Django, this has been a pretty miserable experience. Python and Django are my choices for back-ends currently… but I don’t really have a “choice” for front ends on iPhone/iPad.

In an effort to reduce the pain for others as well as help myself retain this knowledge, I’m writing it down.

I understand it might seem strange since Android is a lot easier to develop for, and Flash Player 10.1 actually runs natively on the phone… and well, I might add. For me, there are 3 reasons. First, there is no market right now. Yes, I understand we help create it, but I own an iPhone and iPad. I love them, and so do others. I have a gateway to others right now via the app store, and want to empower them to use my apps. Secondly, if you’ve ever used an iPad, the additional screen real estate just fills you with ideas. Third, everyone wants an app right now. While the consumer data shows it’s hard to make money, it’s REALLY easy to make money for services; aka, a company hires you to build an app for them. This is especially true with the OS4 announcement of Enterprises having more control over deploying their own applications.

Another good primer for me, Objective C for the ActionScript Developer, is Keith Peter’s five tutorials. He doesn’t really cover the UIKit, just Objective C in general which is a great first start.

1. AS3 to iPhone Tutorial 1
2. AS3 to iPhone Tutorial 2
3. AS3 to iPhone Tutorial 3
4. AS3 to iPhone Tutorial 4
5. AS3 to iPhone Tutorial 5

Introduction: Nomenclature

There are a lot of new terms to learn. I just want my code to run on the iPhone, yet I have to learn a bunch of new terminology to ensure I understand what it entails, as well as their “meaning”. For example, MVC means something different to Objective C guys than it does to us. Yes, it’s subtle, but when they say it, it’s assumed you mean “their” version. It helps to know what the nomenclature of the Cocoa community is to learn, so first up, here’s some common terms.

Cocoa: The API you code in for the Mac. It’s like saying “Flex”; it’s all the things that fall under “Flex” like the compiler, the sdk, the ide, the runtime, etc. However, it’s a lot more than that. For example, there are Human Interface Guidelines that Apple puts out that Cocoa apps need to comply with (I don’t currently know how this is enforced, excluding iPhone/iPad). For the sake of this article, all you care about is “Foundation” and “UIKit”, 2 libraries that make up a lot of what people know of as Cocoa for iPhone. It’s also built on the MVC concepts we’re used to. The main difference is Cocoa is huge; it is a layer atop an OS, whereas Flex is a layer atop the Flash Player.

Objective C: C like programming language you code in that borrows some cool things from Smalltalk, similar to how we code in ActionScript. It’s from the 1980’s, and boy does it feel like it. Anytime I start coding, I have Megadeth on in the background, my Pontiac Firebird Trans Am in the driveway does a turbo boost, and Fletch watches over me, commenting how it’s all ball bearings these days.

Foundation: Provides all the low level stuff you need and shouldn’t have to write yourself. This includes data types like NSNumber (vs using int/float yourself), sockets, etc. Basically, if you can’t see it in a GUI, the class is here. Everything is prefixed with “NS” for NextStep, one of the companies responsible for the early development.

UIKit: All your GUI controls including support classes. Things like UIButton, UIAcceleration, etc. The UI prefix stands for User Interface (duh). You’ll hear about references to Application Kit; that’s the desktop version.

Core Data: Basically the model layer of your apps. This is actually kind of cool, and what we should have in Flex (I know of 2 people who have tried to create an open source one, and then shortly thereafter abandoned the project… too bad too). Right now, there are things like it in LiveCycle, I believe, but only Enterprises can afford that, so its’ not for “everyday use”. Basically, you create ValueObject’s, and they can be persisted in local XML or SQL databases automatically, vs. you having to manually write Factories, parsers, and versioning. Pimp.

Xcode: The IDE that you code Objective C in. You can build & debug your iPhone/iPad applications directly from here.

Interface Builder: The IDE that you use to visually build your GUI apps. You can actually create variable & method definitions here, wire them up visually, and then have it code gen the classes for you. It can also read your header files (imagine if every ActionScript class had an interface class associated with it that defined what it did). As a n00b, I’ve found it really easy to confuse this program and make it explode. Also, someone forgot to add tab order when they made it.

Objective C

Objective C is the programming language you write your applications in. It is effectively an extension to ANSI C with Object Oriented syntax. In Flash and Flex, you utilize ActionScript 3. Objective C has a lot in common with C and C++, and some of the lamesauce as well, namely pointers. Objective C also has multiple environs it can run on while ActionScript runs in just the Flash Player.

If you know ActionScript 3, you can read C, and thus Objective C. Like Java, the type definitions are on the left instead of right, but other than that, they are extremely similar. Like another article mentioned, if C didn’t have pointers, PHP and C would be nearly the exact same. Since Objective C has a lot in common with C, they too are similar.

If you’re coding Objective C for the iPhone/iPad, you don’t get Garbage Collection, and have to manually get rid of your variables/objects. Once you get used to the syntax, it’s almost the exact same as cleaning up your mess in ActionScript. In ActionScript, you set your Object references to null; in Objective C it’s called nil. More on that insanity later.

You can read more here about here.

Yes, you code in Objective C 2, not 1. 1 is even more lame than 2 (thankfully?).

Objective C Syntax: Methods

Objective C has a lot of the same things that ActionScript 3 has. They both use the same bracket syntax, and have the same cuddled vs. not wars. They both end lines with semi-colons. There isn’t as much dot syntax. They both have methods. Here’s how you invoke one in ActionScript:

mySound.setVolume();

Here’s how you invoke it in Objective C:

[mySound setVolume];

Notice in Objective C, they use brackets to indicate the containment of a method call. You can nest these as well, but they recommend you only go 2 deep since it becomes un-readable after that.

Here’s ActionScript storing a return value:

volume = mySound.getVolume();

Here’s Objective C doing the same:

volume = [mySound getVolume];

Passing in parameters is a little different and takes some getting used to. This, to me, is the same thing that threw me off in Ruby, and where Objective C totally ignores how C does it. Here’s ActionScript:

mySound.setVolume(value);

And here’s Objective C:

[mySound setVolume:value];

Ok, not so bad… except, the 1st parameter is always the only one WITHOUT a named parameter. Observe the following ActionScript 3 function with 2 parameters:

mySound.setLeftAndRightPan(left, right);

…and Objective C:

[mySound setLeftAndRightPan:left, rightValue:right]

Notice there is no “leftValue:left” here, just left. The first parameter is always nameless, yet every one after it has one. I guess they wanted more obvious parameters during function invocations… except forgot to build in one for the 1st parameter. *face palm*

For example, here’s an ActionScript 3 function definition:

private function setLeftAndRightPan(left:Number=0, right:Number=0):void

Here’s the equivalent Objective C:

- (void)setLeftAndRightPan:(NSNumber*)left, right:(NSNumber*)rightValue

Notice 4 important things. First, the return type is in the beginning and wrapped in paranethesis (void in this case). Second, notice that Objective C doesn’t allow for default values for function parameters like ActionScript. Third, notice the type definitions for the function parameters are in the left side vs. the right (in this case NSNumber). We’ll get to the asterisk later. Fourth, notice the dash in the very beginning. That signifies that this is an instance method on the class. If you want ActionScript’s static, use + instead.

Objective C Syntax: Variables

Variables are slightly different because Objective C has pointers as well of built-in helper methods to make memory management easier.

Here’s a variable in ActionScript, first defined using a String literal (pimp syntax) and the old school way:

private var name:String = "";
private var name:String = new String();

And here’s one in Objective C:

NSString* name = [NSString string];

There are a ton of caveats here. Notice we’re calling the string method on NSString; it’s basically a factory method to give us a string; similar to going new String(). When I did “” above, it’s called a String literal; the same as going {} vs. new Object(), or [] vs. new Array(). In ActionScript, each of those constructors has nice features, the effect is the same; you get a variable of that type back.

Notice the asterisk in the Objective C example. This means it’s a pointer to the String, not the actual String. Also notice since we’re calling the string method on the NSString class, it’s autoreleasing (similar to the Doom spell in Final Fantasy; it’ll die soon; ie he’ll get ejected from the Pool soon, more on that later). If you want the guy be like Number 1 and live forever instead of a Rico’s Roughneck, go:

NSString* name = [[NSString alloc] init]

Just keep in mind you have to manually call release on him later whereas the former, you don’t.

Objective C Syntax: Pointers & Memory Management

Variables are different because of a couple reasons. First, since Objective C is based on C, it has all the pointer baggage. We ActionScript Developers are spoiled because we don’t have do deal with this… or if we do, it requires little thought.

For example, in ActionScript, there are only 3 variable types that are by value, and thus don’t have pointers: Strings, Numbers, and Booleans. Yes, I’m including int and uint as Numbers here. Every other construct is an Object, and thus is passed by val. If you wish for an Object based variable to be removed from memory eventually, you need to ensure no more references exist, or in the case of circular references, that no one else knows about the circular relationship (the Mark and Sweeper from the Garbage Collector will get those mofos). For Numbers, Strings, and Booleans who aren’t local variables, you just remove their parent Object, and they’re toast. For local variables, they go away at the end of the function (usually… depends on how aggressive the Garbage Collector is at that moment in time).

For Objects, you just remove all references, usually by setting them to null, or in the case of dynamic Objects like Dictionary or Object hash maps, using the delete keyword.

Objective C’s iPhone runtime, and ActionScript’s Flash Player both operate using reference counting. This means, for Objects, an internal number is incremented for every person who “knows” about an Object. When that person later set’s his reference to null, that reference count goes down. When that reference count reaches 0, it’s eligible for Garbage Collection. The Flash Player also has a Mark and Sweep part to take care of circular references in the case where 2 Objects know about each other, yet no one knows in your app knows about them, and thus their reference count will never reach zero. If you’re running on the iPhone, you don’t have Garbage Collection, so need to call release yourself (which calls dealloc internally). In ActionScript, you’d either null the reference out, or call your own destroy method, THEN null reference out.

Objective C has this built in as a method called dealloc. You don’t call, it gets called for you when you (or someone else) calls release. In ActionScript, people will either use a convention of public function destroy, or those fu@#(* IDestroy marker interfaces that people NEVER implement fully (did I mention that’s annoying?).

In ActionScript, for a complex class, it may look something like this:

public function destroy():void
{
	if(timer)
	{
		timer.removeEventListener(TimerEvent.TIMER, onTick);
		timer.stop();
		timer = null;
	}

	if(icon)
		icon.bitmapData.dispose();
}

In Objective C, this is built-in to NSObject, one of the main classes you often extend. The Objective C version of the above would look like:

-(void)dealloc
{
   [timer release]
   [icon release]
   [super dealloc]
}

As learn about how getter/setters are built into Objective C, you’ll see there is a better, and more common way to do the above (article I link to at the bottom describes this), but I need to get the point across here that you’re expected to clean up your own mess since Garbage Collection doesn’t exist, and everything can’t be an autorelease variable.

No Local Variables, Hence Autorelease & T3h Pool

In ActionScript, we have local variables. Basically, instead of storing it in memory, it’s stored in temporary memory that the stack is using (the stack of functions currently running). When one stack item is done (your function is done), those variables are removed. In ActionScript’s case, this isn’t immediate, but basically ensures that no one has references to those variables anymore. Later, Garbage Collection will come along and eat’ em.

Objective C doesn’t have local variables. Yes, I know, I’m face palming as well.

*deep breath* There IS a common way to deal with it. Your first thought may be to create a bunch of member variables; basically what game developers do for simple Object Pooling. That’s ghetto, though. You may think you could just create variables on the fly… the problem with that is you have to manually release them, and for return values, they’ll die before they get returned.

This is where autorelease comes in. Remember before when I talked about the 2 ways to create variables? Let’s revisit it, and show again how you kill things.

This creates a variable you must manually remove:

NSString* name = [[NSString alloc] init];
[name release];

… and she’s dead. However, here’s one that’ll be added to a pool, or rather “a Pool”:

NSString* name = [NSString string];

This is the same as doing:

NSString* name = [[NSString alloc] init];
[name autorelease];

You can then safely return these variables from functions, knowing that the caller will get it. It’s also considered good practice to do, specifically for encapsulation. There isn’t really a language construct to say “Hey dude, this guy is going to send you a variable it also has a pointer to, so please make sure you call his release first”. Crap like that is insane; it’s just easier to get either copy’s of variables so you don’t inherit their pointer baggage, or use autorelease so you don’t piss off people getting variables from you, and causing leaks if they forget to kill you first.

Yes, all of that above is a shortened version of what you have to do because there are no local variables. Yes, I’m face palming again.

If you’re curious about what this Pool is, imagine if a static class was created every time you ran some code.. and Garbage Collection ran immediately when you null’ed out your variables. The first thing it did was keep a reference to any variable that has autorelease on it. Then, 1 frame after the stack has been complete (all your code has run, and the next enter frame runs), it kills all the variables it has stored. That’s the AS version of what an Objective C Pool is.

Conclusions

This sucks. I blame Adobe AND Macromedia for my suffering.

BTW, if you’re looking for some pimp tutorials to learn this stuff, my compadre Brian linked me to it, called “Cocoa Dev Central“, specifically this article.