Stackoverflow DevDays London
Friday, October 30, 2009 at 8:43AM
Phil Nash

Yesterday I attended, and presented at, the Stackoverflow London DevDays event.

For various reasons I missed a chunk of the conference, and as my mind was on my own presentation I wasn't quite as attentive to the rest as I would normally like to be.

Nonetheless the highlight for me, and I think most attendees, was Jon Skeet's entertaining, yet thought-provoking, foray into how we can't even get the most fundamental aspects of software right: numbers, text and dates - all accompanied by a sock puppet called Tony. I also enjoyed Christian Heilmann's coverage of the Yahoo YUI web toolkit, and especially the little known YQL. From the twitter back-chat it seems I am not alone in both being blown away by YQL and not having heard of it before!

Divided Opinions

As for my own presentation, one of the points I brought out was that people tend to either love or hate Objective-C.

Objective-C as Marmite

It seems this dichotomy extended to my presentation as well, so I feel it's worthwhile to fill in here some of the things I had to leave out of the talk. Trying to fit an introduction to an "alien" language, a sampling of the SDK, and a coding demo into a 50 minute presentation was always going to be a challenge. Some things had to go. A lot had to go! In the end it was a case of following the adage, adopted by the iPhone community, of do just one thing but do it well. At least the first part worked out.

Why the focus on Objective-C?

There is more to iPhone development than Objective-C. Even if you leave Monotouch out, the bulk of what you need to learn is actually the libraries and platform. Then there's the IDE, Interface Builder (more on that in a moment), the headache of submitting your application to Apple, the review process etc etc.

However, these are all things you can readily read about on the internet or in books. In the case of the libraries learning them is actually pretty easy - it just takes the time to read the docs. Knowing what to look for takes a bit more effort, but even that is usually just a case of googling around. So the value of trying to cover just a fraction of that in the time allotted is questionable. I did try to show a little of XCode and the APIs in my code demo - just enough, I hope, to show that you can get a lot done with a few lines of descriptive code.

But here's the bigger problem: just to be able to demo those few lines of code I needed to explain enough the syntax of Objective-C for the demo to make sense. Learning Objective-C for the first time is not easy right at the start, but that's exactly where I needed to be!

So for my 10 minute code demo to make sense, all the slides preceding that were the minimum that seemed necessary just to get to that point. Just writing the code and hoping people will follow it wouldn't cut it!

But why use Objective-C at all? With Monotouch gaining traction - and just the day before the presentation getting full debugger support - isn't it easier to just use that? Well, I'm not entirely qualified to answer that as I have yet to try it for myself - but it certainly looks very good. In the U.S. my counterpart for the iPhone sessions was Rory Blyth and he seems to be all over Monotouch.

In my presentation I brought out a few points that I believe show that at least a basic understanding of Objective-C is necessary to be an effective iPhone developer - for now, anyway. From what I have heard Rory made similar points in his presentations. They are:

Of course all of these will change, although - as with Mono itself - there will always be a certain amount of catch-up as the raw APIs evolve.

Another potential obstacle is that Monotouch has a price associated with it. It's not an unreasonable price, but it may put off those just looking to casually tinker with it. One point that I forgot to mention in the talk (there were a few - due to technical difficulties I did not have access to my notes) was that, even with Monotouch you still need to be running on a Mac! One or two Twitter comments seemed to imply otherwise so it's worth clearing that up. Also, to run on the device or submit to the app store you still need to join Apple's developer programmer at the same cost ($99/ year for a non enterprise membership). Therefore the cost of Monotouch really is an additional cost.

So the premise of my presentation was that, if you still want to pursue iPhone development, whether or not you plan to use Monotouch at some point, you'll need some Objective-C fundamentals and that has a steep initial learning curve. I attempted to temper that by observing that the curve flattens out quite quickly the other side, and that the iPhone APIs are quite sensible, easy to use, and fairly self-documenting (even if this leads to quite a verbose naming style at times).

What I wasn't saying

As often happens when you put yourself out there, some of my motivations appear to have been misconstrued. I did not give this presentation to try and convince anyone to take up iPhone development, nor to dissuade them from doing so. If some have decided that, having seen Objective-C, they want nothing to with it, then hopefully that just means that I saved them some time, rather than doing them any injustice.

My objective (pun partly intended) was really to say that, if you have already decided that you want to have a go at developing for the iPhone, don't be too put off by the initial difficulty - it gets much easier. Beyond that I hope that I clarified some things. If you never intended to do it in the first place I believe it's always beneficial to look at other ways of doing things - regardless of whether you consider them to be better or worse. That was the theme of the conference, after all.

Why didn't I show Interface Builder

This was probably the number one question posed to me directly, or on Twitter. For this I have two answers. Whether they are good answers I make no claim to:

  1. My focus, as I've said, was on Objective-C. Having gone to some lengths to try to give an accessible crash course in the language basics in a small amount of time it didn't seem logical to then almost completely ignore it and use a GUI builder tool. Several people posted on twitter that my demo would have been simpler if I'd used Interface Builder to do it That may or may not be true but that wouldn't have supported what I was trying to do. I do concede that I should have pointed out, at least, that it could have been done using IB.
  2. Not everyone thinks that Interface Builder is worth using for building iPhone apps. Personally I think it's fine for some things, if you're already familiar with it. For many tasks, especially if you'll have to customise the controls a lot anyway, it can add as much complexity as it removes. That is all IMHO, of course, and others are welcome to disagree with it - as they will. My purpose here is just to explain my own motivation in largely excluding it from the presentation

Was it really that bad?

Krusty.jpg

If you didn't see my presentation you may conclude from the above that the whole thing was a disaster! Actually I was pleasantly surprised at the volume of positive chatter on the Twitter back-channel, as well as from people who approached me personally. Obviously I was pleased that they enjoyed the session and that I didn't completely suck, but more than that I was pleased that what I set out to do did reach a good number of people. Thanks to everyone that gave me feedback, good and bad, directly and indirectly. This has certainly been a challenge and I've enjoyed the opportunity of helping people to think along new lines.

Onwards

I know that I'll have picked up a few extra readers of this blog as a result of the conference, and that they will largely be reading it for iPhone related material. I'm not a prolific blogger, but I have been posting a little more frequently of late, and intend to keep the momentum going. I don't just blog about iPhone development, however. I also cover C# and C++ as well as more general themes. See the archive links on the side for more.

Technorati Tags: , , , ,

Article originally appeared on level of indirection (http://www.levelofindirection.com/).
See website for complete article licensing information.