Progress Report

So, over the past few evenings, I've been slamming into a brick wall of sorts.

I'm working on the iPhone app pretty much non-stop, and over the past few nights I've been messing with the UITableView and a custom UITableViewCell. This, this has proved interesting. The first evening, the data loaded into my UITableView, but the UITableViewCell never rendered it's contents. I could select a row, I could scroll the table, but you couldn't see what was in them. Night two, was more of the same in a difference manner. Night three was more fruitful. After rewriting the implementation of my UITableViewCell, I ended up getting a background color to at least display for each cell! Woo! Progress. It might now seem like much, but trust me, after two days of fighting with rendering code and having nothing make a difference, it was huge!

So, for those of you following along going, "okay, so, what did you do differently?" Let me try and explain.

In my TableViewController, I have something like the following:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    
    static NSString *CellIdentifier = @"myTask"; 
    
    myTaskCell *cell = (myTaskCell *)[tableView dequeueReusableCellWithIdentifier:CellIdentifier]; 
  
    if (cell == nil) { 
        cell = [[[myTaskCell alloc] initWithFrame:CGRectZero reuseIdentifier:CellIdentifier] autorelease];  
    } 
    
    // Set up the cell... 
 myTaskDetail *task = (myTaskDetail *)[self.Tasks objectAtIndex:indexPath.row]; 
 
 [cell setTask:task]; 
     
 return cell; 
} 

Well, the first issue I had was that I forgot the cast of (myTaskCell *) on the tableView for the dequeueReusableCellWithIdentifier. That threw off a few things in regards to the call to [cell setTask:task] a little further in.

The next issue was in the myTaskCell code itself. Originally, I was just overriding layoutSubviews and crossing my fingers that everything played nicely. That didn't actually didn't go so well. So I did a little research and found this article at the atebits site. So, with a little bit of modification to the myTaskCell code, I switched to using the overriding drawContentView method and low and behold, I now have a blank cell, which is better than the transparent ones I had 20 minutes prior.

Why is my data not displaying? Well it turns out that the font string that I was using was larger than the cell content and when i reduced it from 20 to 14 it seemed to correct the issue. Wallah, text.

- (void)drawContentView:(CGRect)r  {

...

    normalTextFont = [[UIFont systemFontOfSize:14] retain]; 
    [task.TaskText drawAtPoint:p withFont:normalTextFont];

... 
}

So, mostly just putting this out there in hopes that if I run across it again, I have a quick point of reference, or that someone else is able to find it a little more quickly than I was.



Happy Coding!

 

Tomorrow Comes a Day Too Soon

"The pessimist complains about the wind; the optimist expects it to change; the realist adjusts the sails." Wm. Arthur Ward.

Today, I had to adjust the sails.

My work on the iPhone / iPod Touch App still moves forward and it will continue to into the future. I will now also be moving forward on some additional fronts. From here on, you will be seeing other things appear in this space that are not computer or development related, but may still be of interest.

I've been forced into a need to quickly diversify my trades a bit and will be trying to get some art and music work up for sale, as well as my development side of things. My artwork is mostly abstract and my music tends to lean into the experimental and trance genres.

I will now be using this space to showcase my artwork, music, as well as the development journals. I will more than likely be putting the actual works up for sale on places like Etsy or ImageKind.

Watch this space for things to come. Hopefully quickly.

Update: Design

Working on design this week for the iPhone / iPod Touch application.

I've gotten a good chunk of the requirements hammered out. Hopefully I'll be able to get the UI design fleshed out and figured out next week and get the MVC stuff started. This all hinges on me getting myself through the examples on Core Data either over the weekend or early in the week next week though.

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.

Progress: Day 2

So, managed to make my way around the Xcode IDE a little bit today. Got in, wrote a few console style applications, all throw away code, but all in the hopes that I would be able to get a feel for the tool. To some degree, I have a better understanding of what is available to me and what I can do with it. This is a GOOD thing.

Tomorrow, I have to take as a downtime day. People coming into town and I must clean and prepare for company, so no coding or exploration can be done. This is okay. I need the mental break anyway.

So in brief summation for today:

• Can create new projects
• Can write and run said projects
• Can set breakpoints and step into code
• Can leverage most of the debugging tools, although, a call-stack still seems to be eluding me.

Although, I want to get in and write something with a UI, I am not. This is considered rushing things. I will pace myself.

The goal for Friday is tackling OO concepts in Objective-C and learning the difference in syntax (if any) from C#. So far, language differences have been minor. The ones I've seen so far have been around pointers and memory management / garbage collection. (Imagine that?)

Anyway. Have a great Thursday and I'll see you all back here on Friday!

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.

Finally.

It's been a grueling several days of fighting with the look and feel and the maddening ordeal it has been of trying to get Blogger to play nicely with my templates to get things working mostly how I want them. I think I'm finally there. So, with that being said, development on the iPhone and iPod Touch application will begin in earnest tomorrow. This will mean I'll be updating here with the progress.

What this means for all of you:

• Updates on Design and \ or Pitfalls
• Updates on what I've learned about Cocoa and Objective-C vs C# and VB.Net
• My thoughts on mobile device design and development vs classic web and desktop development.

Typically, I'm not an Apple developer. I've been a strict Microsoft developer, so this is all a learning curve for me. I'll be posting my thoughts about the transition from Microsoft technologies to Apple tech as well. For now, this is all just a work in progress on the site. I'll let you all know before making any sweeping changes. ;)

For now, Enjoy the ride.