Get in the Ring

Weekly Recap

So, I've had this post brewing for the past few days, mostly because of the irritation that it's caused me.

I've been torn between being overly technical in my blog or just giving the high level details of my progress during this venture. Unfortunately, I think I'm going to have to be really geeky in here. I wanted to stay pretty high level so most people could follow along, but some things that I've run across this week have vexed me pretty heavily and I feel the need to explain them in depth so that any .Net developer that does try and make this transition in the future has a good point of reference. So, in an attempt to stay at a fairly high level, I'll brush with wide strokes today and see if I can get a somewhat satisfactory post out on what I think is a pretty important topic.


So, This week's recap first and then the meat of the week.

• Lots of progress, although a lot of the stuff this week was Xcode interface related stuff.
• Tweaks to the IDE.
• Tweaks via command line to setup some auto commenting stuff. (if anyone is interested, comment and I'll post more on this one)
• Basic tour of the debugger
• Basic source file organization with multi-file projects (read, how to deal with REAL applications, not just 'hello world' apps)
• Creation and use of my first set of real live classes in Objective-C (lots of interesting cursing to do here ;) See rant to come. )
• First real nightmarish roadblock. Objective-C/Cocoa's Boxing and Un-boxing

Get in the Ring - Objective-C/Cocoa's Boxing and Un-boxing

A few definitions first from a .Net developer's perspective:

Primitive Type

- Any data types directly supported by the compiler. These map directly to types that exist in the base class library.

Value Type

- Value types are primitive types that are mapped directly to the Framework Class Library. From a memory management standpoint, all value types are stored on the stack.

Reference Type

- Any object type that is not a primitive type. These objects are created on the heap from a memory management standpoint using the new keyword and will return the memory address of the given object.

Boxing

- To be very brief, Boxing is nothing but converting a value type object to a reference type object. Sometimes the .Net compiler will allow implicit conversions for this.

Un-boxing

- Again, in brief, Un-boxing is a conversion of a reference object back into the appropriate value type object. This is typically an explicit conversion.

Auto-boxing

- a feature that some languages provide that will automatically convert primitive types to the corresponding wrapped types and back.

As I said before, I want to try and stay a bit more high level and out of the code examples and the like, but I'll add links to relevant sites if I think they are needed (and they are here.) This particular topic however, bothers me, a lot. See, I went into the Objective-C world from a C# mindset and had put my old C++ development mindset on the back burner. I had put aside things like pointers and memory management and garbage collection. I'd left that world behind and let the framework deal with it for me. I'd just code merrily away and magic would take care of those things for me from now on right? *shakes head* What? Really? I mean, I know better, but I guess I let myself get swept away in it and just didn't really bother with what was going on under the covers.

I left Microsoft do the heavy lifting and I just merrily went along my 'Business Applications Development' way. Most business apps don't need high scale performance tuning anyway. I have people that tell me that if an application runs in an hour that is an acceptable time frame, for a report. *shakes head* Anyway. I digress. So, this week, while going through the motions of learning the new language and creating my first real application in Objective-C, objects were finally needed. Real objects and collections of said objects, but wait. What's this? Boxing and Un-boxing? I... Have to write my own, surely you... really? No... really?

Suddenly, it hits me. I'm not in Microsoft's world anymore. Auto-boxing, doesn't exist here. Objective-C and Cocoa? Yeah. Don't do it. I'm writing real code, in real editors, on platforms that Microsoft doesn't control. I have to do things the old fashioned way. I have to work on writing it all. Not to say it's old fashioned, just to say that I became too self-reliant, or rather too Microsoft-reliant, in this case.

So, with all this in mind, here's what I ran into: primitive types cannot be stashed directly into NSArray or NSMutableArray, you first have to 'wrap' them. They have to be boxed into an appropriate wrapper class, either NSNumber, NSValue, or, I suppose, NSNull, but special cases and what not. There are some objects that will assist you, but mostly you are responsible for handling it all on your own. Anyway. Then, when you want to later use said values, you will have to un-box these values back into the appropriate primitive types.

In the .Net world, the use of value types over reference types is preferred. This is due largely in part to reference types coming off of the heap, which means more to manage in the ways of cleanup in memory management and garbage collection. Whereas with value types, there is less to worry about memory management concerns because it is all based on the stack.

Here, in Objective-C land, it would appear that it's kind of a harder call, you have full control of the memory, so you have the adage from Spiderman to keep in mind 'With great power, comes great responsibility'. I may have to reserve judgment around memory usage until I delve a bit further in on this but, so far, it would appear that the use of value types vs reference types is mostly moot and you just need to be especially careful on your conversion code.

Most .Net developers I know usually take memory management and garbage collection for granted unless they are hard core into performance tuning or are language freaks and want to know everything about the framework. I know about a dozen .net guys personally who wouldn't be able to tell me the answer to "Define [the term(s)] Boxing & Un-boxing as they relate to the languages in the .Net framework." To be honest, until about 4 years ago, I couldn't have cared one way or another myself. It wasn't until I got an application with what looked like a memory leak that I started looking into it.

So, with that said, C# and VB.Net folks, take it to heart: this stuff is important. Learn it now. It will make you more efficient in your current careers. It will make you think about things in more memory-efficient manners or should at least start you down that path. It will also prepare you better for the switch, if you plan on making one. You managed C++ folks doing .Net, you already know all this and I'm just preaching to the choir. Stop laughing at me. ;P

For .Net developers reading along that are interested in learning more about the underpinnings of Boxing and Un-boxing and how it affects you on a day-to-day basis, here are a few good resources. Please, please, please, go read them. It really is important to understand it and it really will help you get to that next level.

http://aspalliance.com/986_Boxing_and_Unboxing_in_NET.1
http://www.dnzone.com/go?377
http://msdn.microsoft.com/en-us/magazine/cc301569.aspx

Progress: Day 3

IDE Updates:
Okay, so a few of my complaints about the IDE over the past few days have been the multiple windows for everything, no real good way to manage them, no persistence for where windows stay, etc. It's been driving me crazy, like to the point that I've complained to my wife, who also codes occasionally. She's laughed at me. A lot.

Anyway. Since I've complained about this I've done a little bit of research and found that there is a way to get an interface a little closer to what I'm used to. This article on 'Reducing Xcode's Window Clutter' was the answer I was looking for. There is an 'All in One' mode that basically consolidates all of them into a single window IDE with a set of toggle buttons to change your viewpoint. This was a wonderful thing for me. Might not be as big of a deal for non Microsoft developers, but it's made the transition less painful, as the interface seems more similar at this point.

Language Updates:
Now that that barrier is out of the way I've gotten down to some real development. Wow. Talk about some serious differences in syntax. Now that I've moved into looking into more Object oriented programming in Objective-C, we're starting to see the differences appear fast and furiously compared to before.

Some basic differences so far:

• Definitions of Enumerations and Structures.
• Declarations of Objects
• Instantiation of Objects
• Use of Objects, Properties, & Methods
• Inheritance, Composition and Overloading differences

Later, I'll go into detail about some of these differences.

Overall Updates:
So, overall, I've gotten a pretty good feel for the IDE. I've gotten a pretty good feel for the basic language constructs. I've gotten a pretty good overall feel for the basics. Now, it's onto the intermediate concepts.

IDE Woes

The first thing I've noticed with the transition to working with Cocoa and Objective C has been the massive difference in the working environments. Visual Studio felt like home. Where Xcode feels like a foreign country to me. It is very much the same lost feeling I had when I fist made the transition from Windows XP to the OS X world. Nothing was familiar. I didn't know my way around. If it hadn't been for prior *nix experience I'd have been totally lost and a complete 'Stranger in a strange land' if you will.

Okay, so I've got this project started, no issues there. Pretty small potatos to get that going, great. Now what? I mean, I'm looking at this crazy IDE that is totally new to me. No solution explorer, no property panes, no intermediate or watch windows as I am used to them. What's a Microsoft developer to do at this point?

Yeah, I googled it - "learning objective-c"

This lead me to a few things.

• Thing 1 - Apple's Developers reference For all of us Microsoft guys, this is Apple's answer to the MSDN Help Library

• Thing 2 - Learn Objective–C on the Mac by Mark Dalrymple & Scott Knaster This has been a great book so far. It feels a bit rudamentary for anyone who's been doing development for a while, but when switching platforms, languages and enviornments, it is moving exactly the speed that I need. I think I would be overwhelmed otherwise.

So where does that leave me now? It leaves me with a lot of reading while I figure out the interface and how the tools work. I'll hopefully have a few small trial apps written tonight and tomorrow as i get more familiar with the toolset and will post a little more about the trials and tribulations. ;)

Stay Tuned.