Posts Tagged ‘Cocoa’

Cocoa/Objective C development tips for .Net Folks: Part I

No, this isn’t about using .Net to make iPhone apps!  It’s just a set of observations that might make it easier for people like me who currently use .Net (specifically, ASP.Net) at work, but want to start fiddling around with some Objective C, Cocoa, etc.

Keep in mind that this is from the perspective of someone who got into web development without traveling down the formal education route (when some of my buddies were learning C, COBOL and PASCAL in CompSci 101, I was sucking sand through a gasmask, patrolling some godforsaken ammo dump or airfield in the middle of nowhere).  I have no pure C language knowledge or insight, so all of this stuff is new to me.  I know many web developers in the same situation, so maybe this will help some people make the connections between Obj C and the types of languages they’re used to.

– “Actions” are event handlers.
– “Outlets” are properties that can be bound to your user interface widgets.  They are objects of the same type as the given widget. So if you have a RoundedButton on your UI, you’ll probably have a RoundedButton in your .h/.m code if you want it to actually do something.

From what I can tell, you don’t need to name the specific buttons in the UI part…you associate the button with its corresponding outlet via a drag-and-drop in the UI editor (“Interface Builder”).  I’m pretty sure you can do it manually/dynamically via code, too.  In the .Net world, you’d set the name of the button in the UI editor or in your HTML code, and Visual Studio would automatically make the corresponding code additions.  I haven’t seen that ability in XCode/Interface Builder, but I’m totally new to this so don’t take it to mean that it doesn’t happen.

You can think of the .xib file (known as a “nib” file by Cocoa vets to honor the former file extension) as needing a code-behind page.  The nib is your UI, and the .h and .m files need to be told “Hey, I have these do-dads on the UI.”  After all, if you dig through the code that ASP.Net automatically generates, you’ll find the same kind of definitions for each UI item in the code-behinds.  Same-same.  Don’t let the EXTREMELY WEIRD BRACKET-HEAVY SYNTAX scare you.

Speaking of which, here’s a brief bit of learnin’ about the syntax.  Let’s take apart this function…

-(IBAction) openThing: (id) sender
// code that does stuff

The hyphen is there on purpose.  (Don’t ask me why.)  (IBAction) is the return type, openThing is the name of the function.  (id) is the type of the argument and sender is the argument itself.  To call a function, use brackets like this:
[myObject doSomething:5];
myObject being the object, doSomething is the function being called, and 5 is the argument.

By the way, the “id” type in Obj C corresponds to Object in our world.  It could be anything.  You’ll need to cast it to whatever type actually sent the event if you want to use it.

If you ask me, the brackets clutter up things, and dot notation isn’t supported enough in Objective C.  They added it to 2.0, but I think it could be used more than it is.  You still need to use brackets for functions if I’m not mistaken.  Of course, you can’t just change the entire syntax of a language without peeving your developer base!

On a side note, I’ve found XCode to be a sweet IDE to work in.  At first I found it a little annoying to have to switch between two completely separate programs to do coding vs. UI work, but then I realized some benefits to it.  Unlike Visual Studio, you can open up just the stuff you want to work on.  VS gets more bloated and resource-hoggy with every iteration, and it would be nice if you could completely rip out the Design mode when you’re working on ASP stuff.  You know it’s lurking in memory somewhere, ready to reformat your clean, hand-written tags the moment that you accidentally summon it.

Another advantage to having two separate programs is that it reinforces the separation of concerns between code and UI.  This premise lies at the very heart of how iPhone programming works – it uses the Model-View-Controller pattern!  I have used this pattern extensively, and although I’m not a design patterns guy, I have to say that it makes for fairly clean distinctions between the various pieces in an app.  If you haven’t used it yet and you’re an ASP.Net developer, you’re in luck.  ASP.Net has an official MVC implementation!  Grab it, build some stuff with it.  Understand it. It’ll help you see how things work in the iPhone (“Cocoa Touch”) world.

The books I’m reading on the subject are Beginning iPhone 3 Development by Dave Mark and Jeff LaMarche, and Programming in Objective C 2.0 (2nd Ed.) by Stephen G. Kochan.  I’ve found both of them to be very, very good books.  I will say that getting about halfway through the Objective C book first will make your life a lot easier.  I’m currently switching back and forth between them.

I’ll be posting more stuff as I wrap my head around this.