As I mentioned last week, I’ve been taking some time recently to teach myself how to program the iPhone, and while I can’t say I’ve completely wrapped my mind around Cocoa Touch and the Xcode IDE yet, I can say that I’ve made a ton of progress. I may not always be sure why it works, but I’m at the point where I can reliably build functional UI without banging my head against the wall, and I’m pretty sure I’ve got a good enough grasp of Core Data to build the innards as well. Not that this terminology means anything to most of you, but oddly enough, it means something to me now. I guess I’m a geek.
So my status hasn’t changed. Expect fits of light posting as I continue to obsess on teaching myself how to build a functional app.
One word, my friend:
iDork.
Sad. It seems you can’t use other programming languages without jailbreaking the phone.
Arecent search on the ApppStore for “democrat” was surprisingly without meanful results. Lots of forward thinking people carry these devices and an app for those of us in the democratic wing of the democratic party would be a good thing. But Goldy needs a cash cow first to support time spent on such good things, so good luck luck on your projects sir. OTOH, a small firm able to turn out apps for volunteering for campaigns might have a nice market. Especial good luck on such an enterprise, Goldy!
Have fun!
iProgramed the iPhone once and it was an iDisaster. iObjective-C iSucks. iObjective-C was iWritten by iMorons.
Dan @5,
Well, now that I’ve gotten into it, I can appreciate the power of the whole Cocoa Touch environment. I mean, it does so much for you.
The problem is, it’s incredibly abstract, creating a steep learning curve. And of course, the code I write in Cocoa and Cocoa Touch, won’t translate well to any other environment. If I decide to port to Android, for example, I’ll basically be starting from scratch.
You’d think, that with such a scarce interface, there would be room for a real RAD environment for iPhone. And I wonder if this insistence on Cocoa/Xcode as the only development environment won’t put Apple at a disadvantage in time.
@ 6
If I decide to port to Android, for example, I’ll basically be starting from scratch.
Probably not much of a consolation, but you can write the business logic in C++. Just don’t use the language features of Objective C in the C++ code. Keep the implementation separate.
With regard to porting iPhone (Objective-C) to Android (Jalvik/Java), you could probably write a PERL script to do the translation, or get you more than halfway there.
Or, you could use m4 to define macros to be expanded into either Objective-C or Java.
Heh.
Don @7,
For this first app, there’s virtually no business logic performed outside of the CocoaTouch framework. Apart from operating the UI, I’m mostly just pulling stuff out of a database and throwing it into UI, and Core Data does all the heavy lifting.
The breadth of the framework is as impressive as its learning curve.
Dan @ 8
Both of those ideas will quickly run into some fundamental language differences, not the least of which is that Objective-C resolves the message receiver at run-time, not compile time. And, I’m not talking about instances of pre-defined classes that are all known at compile time. Objective-C doesn’t care about the type of the receiver. Objective-C only cares that the receiver understands the message you’re sending to it at run-time.
The amount of work you’d have to do in order to get Java to do the same based on some abstract language definition of your own would be more than just rewriting the app from scratch.
Goldy @ 9,
Ah. So, the bulk of your work is writing the controller, which you’d have to rewrite anyway in order to move the code to another platform.
It might be good, however, to decouple the controller implementation from the fact that it’s running on an iPhone. Always remember, smart controllers are ignorant.