Go native with iPhone development
Baby steps
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Hands on I'll admit it. I'm an unashamed fan of the iPhone. I had an unlocked device in the UK running on my cheapskate Vodafone tariff before November's official launch.
From a developer perspective my real interest is in being able to create native iPhone applications. I emphasize native. There's plenty of information around on how to build web-based applications, but I'm talking about native-code executables.
Apple is expected to release an iPhone SDK after this week's Macworld, San Francisco, California, but until then, we have to resort to experimentation that's not officially sanctioned by Apple and relying on knowledge you've gleaned from iPhone-related sites.
In lieu of the full SDK and an open environment, I've taken a look at the first steps you can take building and deploying a native iPhone application.
Under the hood
The Mac has two principal class libraries - Foundation and AppKit. Authored in Objective-C (for the most part) these provide the architectural bedrock on which Cocoa programming is done. On the iPhone, the counterpart libraries are called CoreFoundation and UIKit. There are, in fact, a whole slew of other frameworks present on both platforms. This includes the recently introduced LayerKit.framework, also known as Core Animation on Leopard. In fact the UIView class - the equivalent of NSView - has layer support built right into it.
Before you can start creating iPhone applications, you need an appropriate toolchain. If you're not familiar with the concept, suffice to say that a toolchain encompasses the compiler, linker, assembler, header files, and the static and shared libraries needed to build an executable for a particular platform. The unofficial iPhone toolchain is based around the GNU tools, and it's a certainty that whatever Apple come ups with, the same will be true there. This is because Apple's development tools already use the GNU stuff.
You can configure xCode for iPhone development but I decided against that. Instead, I used the Cygwin tools; a Linux-style environment, based around the GNU toolset, but running under Windows. This might seem an eclectic way of doing things, but there's method in my madness.
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
RE: The Cocoa Name
Firstly, yes you're right about CoreFoundation / Foundation. That was a typo: I was thinking about the layer kit and Core Animation while writing Foundation! As you say, iPhone apps primarily use Foundation and UIKit, although CoreFoundation is present, at least on 1.1.2.
The NIB thing is more interesting. I've pulled apart several iPhone apps, and not found a NIB yet. As far as I can tell, most apps hard-code the position of each UI element. Calculator, for example, has a method called [CalculatorController init] which laboriously lays out all the buttons used by the calculator in their hard-wired positions. This, I suspect, is the reason you can't just rotate your iPhone and get a landscape-oriented calculator. It's just a major hassle doing this once, let alone twice! Hopefully, the official SDK will have some sort of GUI design tool which lets you lay out a window graphically, and then at least spit out a chunk of Objective-C which you can then paste into your app. But then again, maybe we won't have that, at least initially....
So why no NIBs? I guess the short answer is reducing the code footprint. The business of bringing in a NIB, parsing it, auto-generating the various controls and then linking up the actions, etc, is a lot of code. Maybe in iPhone 2.0 ?
Dave
The cocoa name
"Cocoa is indeed an odd name for a development framework - nothing to do with chocolate. But then, I guess Java hasn't got much to do with coffee... ;-)"
Though oddly enough Cocoa has a lot to do with Java. Cocoa is only named as such due to the Java bridge that existed from 10.0 to 10.4 (you can still write new apps but they don't offer any new features, though why you'd want to code in Java when you can use Obj-C I don't know). Though I don't really see how the name Cocoa is stupid for a development environment when you also have names like Swing, Rails etc. Half of names for products are a bit silly, the other half are boring ;)
I'm also interested to know how the GUI development will work. It would be pretty bad if Apple expected you to write code to generate your UIs. Do existing iPod/iPhone apps have NIB files? This could point to the use of Interface Builder for creating the UIs. Also, are you sure that they're using CoreFoundation, as that is the C based API. I was under the impression the iPod/iPhone used the bog standard Foundation.framework (which is the Obj-C layer built upon CoreFoundation) and replaced AppKit with UIKit on the GUI side
RE: Thanks
Hi Stu - thanks for the comment: I'm glad you liked the piece.
I'm planning a follow-on article which looks at how to build a small app using the classes in the UIKit framework. Just waiting for Apple to bring out the official SDK in case there are any huge changes.
ps: Cocoa is indeed an odd name for a development framework - nothing to do with chocolate. But then, I guess Java hasn't got much to do with coffee... ;-)
Dave
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
