The iPhone SDK, from a Windows developer’s perspective
I'm a PC. And now I'm trying to write software for the iPhone. Nothing serious, mind you, just some little toy apps. I did some Carbon development a few years back, but these days Cocoa is hot, Carbon is not. So I'm trying to grok Cocoa. Here are a few fun facts I've learned along the way.
1. iPhone Developers Need to Know Objective-C
Objective-C is basically C with some OO glue. It's about halfway between C and C++, but uses its own unique syntax for some of the OO things that C++ does. Here's a snippet:
// C++ code
foo.bar(42);
// Equivalent Objective-C code
[foo bar:42];
Objective-C is a dynamic language, and supports COM style AddRef/Release management of objects (although the actual methods are called retain and release).
2. Method names include parameter names.
This is related to #1, but combined with the verboseness of Apple's API names, this makes for some interesting method names. For example:
// Objective-C method
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
// method body
}
// Roughly equivalent C++ method
id MyClass::initWithNibName(NSString *nibNameOrNil, NSBundle *nibBundleOrNil) {
// method body
}
The documentation for this method would refer to it as:
initWithNibName:bundle:
3. Interface Builder builds objects
Windows developers typically use Visual Studio to create resources, like dialogs or menus, and then in code, instantiate the dialog and hook things up. MFC, Microsoft's Foundation Classes C++ class library, supports some macro-based hookup of buttons to handlers, but the resource format is just the resources.
When creating resources for the iPhone, developers use Interface Builder to create xib files, which are the iPhone version of nib files, the standard Mac resource format.
The xib file isn't just a description of some resources; it's a serialization of a graph of objects. When your app causes the xib file to be read, those objects are instantiated and available to use. And Interface Builder lets you define connections between objects, like what happens when you click a button, or what value in what model is used as the data source for what control. This lets you do a lot of the wiring up of the UI right in Interface Builder, and it's got some great UI metaphors for this wiring up.
4. AppKit, the iPhone UI toolkit, is very focused
Windows Mobile gives you basically a somewhat stripped down version of the desktop API; AppKit is much more focused on delivering only the capabilities that the iPhone supports. The best example of this is that there's no way to handle a keyboard event - because no iPhone has a keyboard. You can add a text input field, which, when it receives focus, automatically scrolls up a keyboard, but that's it.
5. Navigation is part of the toolkit
That's a Navigation Bar. It's got a title, can have a button on the left and a button on the right. The view below it can have controls that take you to child views. It's a fundamental part of building an iPhone application, and if you've used an iPhone you know what I'm talking about.
The other navigation control is a tab bar, which goes at the bottom of the main window.
One or both of these navigation paradigms are used by almost every iPhone application, and they're supported in Interface Builder. Once you figure out how it works, you can use Interface Builder to build not only individual views, but the whole application including how you navigate from place to place.
6. The Simulator is great
The iPhone simulator launches quickly, communicates well with Xcode, and also with the debugger. I don't think I'd go so far as to say Xcode is better than Visual Studio, but I think the combination of Xcode and the iPhone Simulator is better than the equivalent combination for Windows Mobile.
---
I've only been playing with the SDK for a few days, and just wanted to post a few initial thoughts. Any other Windows developers digging into the iPhone?