Blog Moving

The blog is moving locations. This is to allow more flexibility with other languages etc. For the latest updates, please visit the new blog.

Understanding Model-View-Control (MVC)

If you're new to iPhone development or new to programming in general, I encourage you to take a look iTunes-U for a wide variety of classes and courses. In particular, look for the Stanford course for iPhone Development. It is complete with a wide array of resources, lecture slides, materials, and will definitely save you time in your quest to develop the next iPhone application.

Ok, enough with the free plug. What is MVC? The Model-View-Control design pattern is used extensively throughout the development of an iPhone application. It is used to separate the presentation of your graphical layout from the data that populates that view. The connection between these two components is the controller and is often referred to as "the glue". Understanding it properly will save you from my mistake, which incidentally led to "Class explosion". Here's the problem:

"I have way too many UIViews! It's getting hard to keep track of all my classes. It seems like my UIView is composed of nothing more than my UIText, UILabel, etc. Seems like a waste."

In fact...it is a waste.  Hopping on the MVC train by simply explicitly saying...view elements go in the view, control logic goes in the control, and my model goes in its model area will saturate some of the power that the controller will provide for your view.

You might be saying, "Hey! That violates the design! The Controller shouldn't be managing elements contained in a UIView!" While from a purist standpoint, it tends to make sense.... the deficiency arises in the fact that you now need an entire class just to house the @property and the IBOutlets for each of your objects. It's somewhat overkill to have this many views doing really nothing in regards to the view.

If you're like me, you need to rationalize it somehow. I rationalize it by saying that each element populated in the UIView, is simply a type of view. For instance, UILabel has a property "setText", and that gets relayed to the actual view where it is displayed. UIView is as much of a view as UILabel is. The only difference is that UILabel doesn't have the word "View" in the class name. By placing the UILabel as an IBOutlet in the controller, you are providing easier access for the view's components. Additionally, the UIView then maintains a single responsibility, which is to control the placement of the view elements. The controller maintains the single responsibility of propagating model elements to the view.

So what have I found out works well in using the XCode IDE? Take advantage of Interface builder. Unless you need to do something with the actual UIView, you can pretty much get away without having to create a separate UIView class. Put your UILabel and objects in your viewController as IBOutlets. That way you can operate directly on the elements. If you follow the pattern, one controller per view, so you shouldn't need to worry about who's UILabel it is. It's the view that the controller owns. You'll greatly reduce the number of classes you need to keep track of, and accessing those views will be a much less tedious task.

Side Note - C++ reinterpret_cast

If you find yourself handed code that has memory corruption issues and uses reinterpret_cast, take a closer look. Reinterpret cast in C++ is not meant to be used to downcast a derived class to a more basic class. Doing so will give you the incorrect address for the base type.

Instead, do a dynamic_cast. It's much safer and is the correct way to make a cast of this type.

Walking Backwards - Introductory Tutorials - The AppDelegate

When I started coding for the iPhone, I spent the first few coding sessions reading and watching tutorials and books. They're priceless when it comes to learning at a rapid pace. In fact, there's a good deal of freely available video tutorials that show you first hand how other developers go about coding on the iPhone.

One example in particular I would like to highlight is the Hello World App. Like any program, it's great to start out with. However, you need to read it with a bit of caution...because if you put it into practice in the actual program, it doesn't scale rather well and things quickly grow out of hand.

For instance, the Hello World application has you create your delegate methods which provide functionality in your AppDelegate class. If you have one window and one view, it's perfectly fine. Now what if you have multiple views? Do you really want all your functions in the app delegate? If you said yes, you'll quickly find yourself swamped and lost in your own program.

So what does the Application Delegate do? The delegate provides a functionality to allow global references to do stuff. Now...how would you go about looking for a pay stub from last year? One way would be to put everything in a filing cabinet. Perhaps you might sort it by year?

However, maybe you're not organized. All your papers are in a big heap on the floor in a spare room that nobody uses. All the junk mail with coupons that you thought you were going to use is in there too. Now go find that pay stub! This is exactly what you don't want to do with your Application Delegate, you'll never find things and debugging and tracing the flow of your program will be a complete nightmare...both for you and anyone that works with you.

So what do you do? What the architecture eventually forces you to realize is that you'll want to house your view control logic in your ViewController. If you're using a XIB, this will be your "File Owner". References you make from the controller will be made simply to retrieve some global data, like a model representing the data you're trying to present and be accessible to multiple views.

By moving this control logic to your control, you compartmentalize a great majority of the logic in places where it is important and relates to the task at hand. If you want to to switch views, the task of switching is fairly easy, as you can call your delegate to swap out views from the root view.

Mysterious issues creating plist files

So I've been using plists as a way to internally store data to my application. My data set has gotten so huge that I needed to beef up my unit tests to uncover some test algorithm bugs in order to produce a better histogram as to how well my application is performing. 

Unfortunately, I ran into a little snafu. When I created my test plist file, I neglected to pick the correct type of file. I simply right clicked in XCode to add a new file. I didn't select text file, nor did I select plist. I selected a non-type kind of file (That's not the official name...but I'll update this blog once I get back home). 

Suffice it to say when you don't, you miss out on a key piece of information in the DTD part of the XML telling XCode that you're writing a property list. It will proceed to populate your list with enumeration type data sets rather than XML plist when editing it in XML view in the XCode editor. If you view the file as a text file, you'll see what I mean. This came to bite me in the...well you know, and I proceeded to get exceptions in my application telling me that a string isn't a BOOL. 

Doh!

Anyway, I'll clean this blog up later with some screenshots and the like, but in case you have a coding craving this weekend, here's something that may have gone under your radar.

XCode Crashing? Did you just add a PNG to your project?

This issue took me less than a half hour to figure out, but apparently after adding a PNG file to my project, XCode seemed to crash rather frequently. I was getting a trace of NSView in the dump, and it seemed to crash whenever I clicked on t

he image I added (which triggered the preview to be displayed in XCode.

It turns out, XCode doesn't like 16-bit PNG files. So, if you happened to add one and are having that problem, just save your PNG as an 8-bit and replace the 16-bit image in your project. If you have a hard time removing the image from your project, just enter your project's directory and replace the image file outside of the XCode interface.

Speaking of PNG files, here's the version of XCode I'm running:

What's to Come!

I suppose to start off with this blog, why blog? Consider it part of the developer's code of conduct...helping developers become better developers. We've all gone through the trenches at one point or another, and yet we all seem to hit the same spots where we get tripped up.

So here it is, my....

"iPhone Developer's Notebook!"

Each article I write is sort of like a "lessons learned", my hope is that I can help lift the fog for some of the more mystifying and less talked about aspects of the iPhone and iPod Touch SDK in addition to pointing you in the right direction of resources that I've found useful in uncovering the SDK's...deepest and darkest secrets.

In one of my next articles, I'll discuss some misleading examples that send you on a design pattern coding and refactoring adventure! It's sort of like navigating a jungle with a compass that always points to the magnet in your shirt pocket and you ask yourself, "Why am I here again?"