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 …
I've been looking for a starting point for developing for my iPod Touch. AFAIK its a totally identical platform except for the phone and SMS elements of course - you can even run most iPhone applications on the iTouch including Maps which is awesome!
All I find when googling are a bunch of pages like that Wiki page you linked to, where there aren't any straight forward instructions, rather just a whole lot of wiki discussions from the multitude of people trying to get the toolchain working initially on their setups. Frustrating to say the least.
Now it would be great if you could do a 'part 2' covering the basics of GUI development. Given a lot of people will have no clue as to Macintosh style development at all. I come from a Windows API + Visual Basic + Visual C++ and lately the .NET environment, and this is totally foreign to me (Cocoa is a stupid name for a development kit!), it would be great to see some GUI basics, even if its only for the simplest of controls.
sektah - Thanks for the heads-up. I've checked the website and it does indeed look very cool. Will be interesting to see how much of this stuff survives the 1.1.3 update.... <nervous laugh>
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... ;-)
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: 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 ?
- iPad? More like iFAD: Now we know why Apple ran off to IBM
- +Analysis Microsoft: We're building ONE TRUE WINDOWS to rule us all
- Climate: 'An excuse for tax hikes', scientists 'don't know what they're talking about'
- Analysis Nadella: Apps must run on ALL WINDOWS – on PCs, slabs and mobes
- Major problems beset UK ISP filth filters: But it's OK, nobody uses them