Posts Tagged ‘tips’

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.


Flash Builder Quirk #184912 – The Fake Compile

The other day I had to merge some code (we’re using SVN with Tortoise).  Sometimes that doesn’t work out too well.  This is especially true with Flex code, for some reason.  The merge left a few files conflicted and otherwise wonky, and after untangling that mess Flex Builder still wasn’t compiling the project.

Or should I say, Flex Builder wasn’t compiling it, but it appeared as though it was.  It turns out that there was a huge chunk of “<<<< mine” and “<<<< theirs” code sticking out of one of the files, but FB wasn’t reporting any compile errors.

Long story short: any time you suspect that FB isn’t really compiling the latest version of your code, try running the project straight out of the IDE (hit the big green Play button) instead of running it via your web page.  That should knock it in the head and let it show you the compile error.

Run multiple instances of Second Life for easier scripting

When I’m programming, I love it when I enter “the zone” and the code just flows from brain to computer.  In Second Life, nothing breaks that flow like having to minimize my script windows and Edit dialog, and then having to fiddle with my camera to get a look at how my script is affecting the object I’m working on.

Here’s a little tip for anybody who, like me, has about twenty LSL script windows open in Second Life at any given moment.  If you want to grab a quick peek at the object you’re working on try this:

Run two instances of SL!  Keep your alt’s screen tidy and centered on the object you’re fiddling with.  When you want to take a look at your scripting handiwork, just Alt-Tab to switch between your scripter and your alt.  This is really handy for folks with multiple monitors.

To run multiple instances of SL, you’ll need to modify your Second Life shortcut. Right-click on the shortcut and go to Properties.  In the Target textbox, just add “-multiple” to the end (no quotes).  Make sure there’s a space between whatever is already there and the hyphen.

I advise you to rename the shortcut to “Second Life – Multi” or something like that, because subsequent installations of SL will overwrite your icon if you leave it just “Second Life”.

Happy scripting!

* PS: A word of warning…I ran two instances of the Release Candidate so I can compile scripts in Mono, and I encountered a really strange permissions/ownership glitch wherein my alt got permission/ownership of an object, while my main toon lost permission/ownership.  I suggest running the alt toon with the standard client instead of the Release Candidate.  I’m reporting the issue to the proper authorities.