Learn Objective-C on the Mac - Mark Dalrymple [165]
Many of the fundamentals of UIKit are similar to AppKit, with a few twists to make it work easily on a small, accelerometer-enabled, touch-screen device. Each application has a single UIWindow where all drawing occurs, and that UIWindow contains a hierarchy of UIView subclasses (such as UIButton, UITextField, and the like). Although AppKit’s only native user input methods are mouse and keyboard, UIKit also provides similar event-based input for handling multiple onscreen touches as well as movement of the device.
In some other ways, UIKit is sort of “AppKit 2.0.” Apple took the opportunity to toss out some baggage in the form of APIs and classes that may have seemed like a good idea a decade or two ago, but now seem unnecessary. For instance, the whole concept of cell classes, distinct from views (as exhibited by the NSCell classes) is now gone. The only UIKit class with Cell in its name is UITableViewCell, which is really an NSView subclass used to draw a chunk of a table view (hence the name). Also, UIKit embraces Objective-C 2.0’s properties in a way that AppKit never has, providing declared properties for most of the configurable attributes.
Apart from that, there are some important parts of Cocoa that aren’t available in Cocoa Touch (at least, not as of this writing). First of all, there’s no garbage collection on the iPhone, so any code meant for iPhone needs to use the retain/release/autorelease reference-counting system that we’ve mostly been avoiding in this book. Second, there are no Cocoa Bindings in Cocoa Touch, though KVC and KVO are there, so, if you’re feeling ambitious, the underpinnings for building your own bindings-like technology are there. Finally, there are no blocks on iPhone. It’s entirely possible that Apple will port these technologies to iPhone on its own at some point, but don’t hold your breath!
GNUstep and Cocotron
Another platform that can run Cocoa-like apps is GNUstep, and its more recent brother-in-arms Cocotron. The GNUstep project has been around for a long time, and its original goals were centered on providing a desktop application programming environment for Linux and other Unix machines. The development libraries were based around the
OpenStep API, a published standard which lists classes and APIs that are a subset of today’s Foundation and AppKit frameworks. That, in turn, came from a collaboration between NeXT and Sun in the mid-1990s, when Sun wanted help providing an application development environment for their Solaris OS, all of which preceded Apple’s later acquisition of NeXT, whose OS and software later morphed into Mac OS X.
So here we are today, and GNUstep is still out there in the wild. GNUstep continues to grow, acquiring new APIs as volunteers re-implement the latest things that Apple adds to Mac OS X, but its main goal has always been to implement the old OpenStep APIs, with the new additions being just a bonus. So far, there’s not much for GNUstep to shout about in terms of big-name projects, but if you are looking for a way to port your Cocoa app to another Unix variant or to Windows, GNUstep is worth looking into.
A few years ago, a new alternative called Cocotron turned up. Cocotron has a slightly different focus (trying to keep on top of all of Apple’s latest classes and API changes) and a different deployment target (it’s focused primarily on Windows instead of Unix), but it may also be worth thinking about if you’re looking for a way to port your app to Windows. It also has a less stringent license than GNUstep, which means you’re free to build Cocotron into your own closed-source applications. You’ll find more about GNUstep at www.gnustep.org, and