Another Microsoft Developer Falls Victim to Framework Myopia

I'm not going to link to the blog post because you guys have probably already read it. What I will do is take a quote-by-quote look at some of the misconceptions this guy has about iPhone programming and programming on the Mac using Xcode in general. First, let's take a look at this quote:

You have to get on a waiting list and be approved first. That takes about 6 months or so, after which you still don't have any promise that your app can get loaded on any iPhones. After you finish your app, you then have to submit it to Apple, who decides whether or not they want it on their iPhones. That's a hell of a lot of work to do before getting a yes / no answer (not to mention that even if you do get the app in the store, a cut of every sale goes to Apple).

I don't even know where to begin in countering this. First, the waiting list doesn't take 6 months or so,  as the SDK hasn't even been publicly available for six months and there were more than 4,000 accepted device-developers at the time of the WWDC. And if you want to run on a simulator until you get accepted, that is free of charge. Obviously this guy has never developed for a closed-phone system like RIM before because the "hell of a lot of work" is 0 work. You apply, you write your app (which you'd have to do regardless of platform), and you upload your app when you're accepted. The snide remark about the cut going to Apple means this guy has never developed a true mobile application before. What do you do with Windows Mobile apps? Hunt through the sea of ass that comprises the WM ShareWare site community, upload your app 5,000 times to 5,000 sites and then hope some end user stumbles upon your app, downloads it, likes it, then registers it by sending you money. If you're lucky, you can hook into a distro pipeline but that'll cost you a damn sight more than Apple takes from its iTunes distribution story.

I'm not going to refute his comment about naming conventions. The naming convention vs. namespace war is one Jihad of which I want no part, thankyouverymuch.

Back to the SDK itself... The SDK uses Objective C, which is quite a bit different than C++ and has a fairly steep learning curve IMO. Definitely not like jumping to C# from C++ or Java from C++

This is a pretty bad assumption, and a true sign that this guy only spent a few minutes looking at the iPhone as a viable platform. Objective-C IS ANSI C, it isn't some weird hybrid. Anything you can do in C, you can do in Objective-C. If you want the object-oriented features heavily used by Cocoa, it'll take you about 3 days to master the Objective-C syntax. Don't confuse mastery of language syntax with memorizing an entire framework of UI widgets, they are entirely different things. Plus, he neglected to mention Objective-C++, which allows you to intermingle Objective-C and raw, cross-platform C++ code in the same file without any bridging toll or marshalling penalty. That, my friends, is some serious power. I've used this and I think its a very underrated feature. If you're serious about developing for the iPhone and you have any C# experience, the transition to Objective-C is actually pretty easy. In fact, the verbose parameter naming convention in the message syntax of Objective-C is so blissfully self-documenting that I find myself missing that feature when calling C# methods!

The IDE itself doesn't have intellisense. It will autocomplete, but only when you've typed enough of the method to narrow it down to a single method. It really makes you miss Visual Studio, where you can just hit "." and browse for the exact method you are looking for [...]

Again, when you're jumping into Xcode for the first time, you need to give it more than five minutes. As I've said before, to do real justice to a look at iPhone/Cocoa programming from a Microsoft point of view, you really should give it a week solid. Go through Aaron H's Cocoa Programming for Mac OS X book page by page and hand-type all of the samples. By the time you're done, you will be able to "think in Cocoa" when on the Mac, and "think in .NET" when on the PC and realize that there is a big difference in thought patterns there. The trick is to respect these differences rather than just bash the Mac platform for being "not Microsoft". As for intellisense, no, Xcode doesn't have it. It has Code Sense, which works the same way as Intellisense. If you want to bring up an auto-complete list, no you can't use period. You use ESCAPE. Wow, such harsh environmental changes!! Also, something that I like about Xcode is the Research Assistant. While you type, the Research Assistant is automatically sifting through the entire SDK documentation and pulling up things that are relevant to what you type. This way, if you're mildly familiar with what you're doing, you need go no further than the RA. But, if you're a newbie to the platform, you can click the links provided by the RA and be presented with huge amounts of really well-written documentation (there are exceptions of course... I've seen a few docs that are nearly as empty as the MSDN docs).

The UI libraries are strictly MVC. You have no other good option. Either you write MVC, or you go home

Damn straight. It's about time someone put their foot down and said, "No we have decided not to allow you to screw your code completely to hell with the code-behind nonsense." Code-behind, as I have said many, many, MANY times (including twice at WWDC) encourages people to create tightly-coupled code that is not easily re-used and is difficult to debug and violates separation of concerns rules. By enforcing MVC, the DEFAULT way to write code is clean, separated, and loosely coupled on the Mac. As a result, once people get over the culture shock (which this poster obviously didn't get past) they realize that there is a really good reason for MVC enforcement. In fact, the MVC enforcement of Cocoa programming has actually made me a better .NET programmer - I am now more disciplined and see places where my code is leaning towards tight coupling where I didn't before. Some change is good, people. Some change is good.

As far as I could tell, the interface builder doesn't really store the interface in a useful form. Early on, I tried to drag some buttons around and then go look at what it generated; but, as far as I could tell, the IDE appears to put the UI in some kind of resource file instead of generating something you can hand modify later.

This is one of the most common irritations for MS/Visual Studio developers. We assume that a visual designer is a front-end for code generation. Interface Builder is NOT that kind of tool. This is classic apologist behavior. The fact that we have to hand-modify the generated code later in order to get some intended result means that our design tool FAILED TO DO THE JOB RIGHT THE FIRST TIME. If you need to tweak something at run-time in Cocoa, then tweak it at runtime. IB does store the interface in a useful form - as an interface. If you need to tweak the persistence medium of your design tool, your design tool is deficient. This is why the vast majority of us Microsoft developers code all our ASP.NET pages without once glancing at the designer, why we write our WPF XAML using the XML view instead of the designer view, and why every single one of us thinks that WinForms is the froo-it of the dev-il (bonus points for that movie reference).

If it helps Visual Studio programmers at all, think of Interface Builder this way: 

Interface Builder is a design tool that designs program STATE. It is the job of your Objective-C code, the Cocoa framework, and the end user to manipulate that state at runtime. You don't need to care about how that state is stored, only that you, as a programmer, have the ability to suck that state off disk at runtime on-demand, or you can allow your Application to pull it out when it deems appropriate (usually at launch when you operate this way). If you want your interface to talk to your code, you create connections. If you want your code to manipulate your interface, you use outlets. Having this perspective keeps a lot of VS developers from getting discouraged and walking away, or worse, blogging negatively about the experience.

In short, the point I'm trying to make here is not that I'm bashing the author of the blog I'm quoting. The point is that it is extremely easy for Microsoft developers to be put off by their first impression of Cocoa, iPhone programming, and Xcode and Interface Builder. What you need to keep in mind is that there is a really, really good reason why things are the way they are in Cocoa-land.. and if you give Xcode/IB/Cocoa a week of your time, you will come out of that week knowing those reasons, and more importantly, respecting them.

tags: mac  apple  iphone  cocoa  dotnet  wpf  xaml  visualstudio  microsoft  editorial  

links: digg this    del.icio.us    technorati    reddit