Making Xcode less difficult

Writing Objective-C code in Xcode can be very difficult.  Especially if you're coming from a different language like Java; not only do you have to learn the new syntax of Objective-C you also have to learn the new development environment and remember what it's like to code in a non-managed environment (i.e. not having the JVM hold your hand when things go awry).

I started working with Xcode and Objective-C about 4 years ago and after many frustrating days (and nights) I found out some great information in an iTunes University video called Advanced IOS Development put out by Madison College.  

It's a very long video, about 3 hours and I'm only about half way through it but I have found some great information in it already that I wanted to share.

Problem: you're running your app on the emulator and it seeming crashes randomly.  You don't get any information about why it crashed the app just quits.

Solution: in Xcode you can set global break points that can stop your app when it crashes, the debugger puts you right on the line that causes the problem!  

Here is how you do it:

• In Xcode open the Breakpoint Navigator

• In the bottom left corner of the view is a plus sign click on it to add a new breakpoint.  You will be asked to add an "Exception Breakpoint" or a "Symbolic Breakpoint" choose symbolic.

• After selecting "Symbolic Breakpoint" a popover window will open fill it in as follows:
• Symbol: objc_exception_throw
• Module: libobjc.A.dylib

• Follow those same steps again to add a new symbolic breakpoint as follows:
• Symbol: -[NSException raise]
• Module: CoreFoundation

• To make the breakpoints global right click (command click - double finger tab - whatever) the break points to move them to the User context

And there you have next time you make a mistake Xcode will stop your app where it breaks - assuming it breaks in your code.  If you tell the frameworks to do something that doesn't work (such as loading a ViewController that won't load for some reason) you're back to the drawing board.

Hope that helps!

-Aaron

Universal iOs Applications

I've spent this afternoon looking at building a universal application for an iPhone application.

First of all I would like to go on the record that I think in general this is a bad software engineering practice - at least in theory .

Having your code check to see if what kind of device it is running and then execute a different set of functions based on the answer feels very hackish to me - at least from a conceptual level.

However, from a user perspective it is sweet software magic that is incredibly awesome - especially when dealing with "markets" similar to what Apple and Google have. For example you only can buy an application once and it can be run on the iPhone or iPad. It's like getting two great applications for the price of one.

I finally decided to buckle down and work through this and as you may expect it is much easier than I expected it to be. I started by:

• creating a brand new iPhone application
• then clicked on Application in the top left pane
• and selected "Universal" in the Deployment Target drop down

Here is a screen shot:

Once xCode runs through it's magic you get a new folder called iPad that contains a new "Window" called "MainWindow-iPad.xib".

Now if you run the application you will be able to run in full iPad mode but the layout will be used by both the iPhone and iPad emulator and that is not what I intended to happen... To get this to change first of all you need another ViewController for the iPad to run so go ahead and create one of those using:
File -> New -> New File... c'mon you know the rest...

So... how do we get our new controller instantiated? Probably have to link into the app delegate, check the InterfaceIdiom to find out what kind of device we're running right?

Nope - not at all. You can handle all of this magic in the Interface Designer. No code change is actually needed! Here is how to do it:
Click on the new "MainWindow-iPad.xib" that xCode created for us
Select the View object in the hierarchy
and change the class under the "Identity Inspector"

Now if you run it you will still get the old layout (and probably crash). What you have to do is tell interface builder to load a different nib file:

Now you can run either emulator and you will get the correct view controller magically instantiated and the correct nib will be laoded.

That doesn't feel very hackish at all now does it?

-A

Objective C can really stink

Let me preface this by saying I am not a very good Objective C programmer. I come from a strong background in Java and enjoy Objective C becuase it's a new technology (for me) and it solves problems different from Java... well at least the API backed by Cocoa Touch solves them in a different way.

Coming from Java I will tell you this - Exception handling in Objective C is horrible! I've spent all morning dinking around trying to get a table view to display. I've been doing Objective C for 2 years now (not exclusively - but I'm not a complete newbie) so to be having problems with something this basic is pretty frustrating.

The problem really starts with me becoming more familiar with the language. As comfort levels increase I begin exploring how to solve things in slightly different ways... This is what happened today. I'm using a NavigationController to pop on a series of views (successfully until this morning).

I have this little block of boiler plate I toss around to pop a view on the NavController that looks like this:

NewViewController *vc = [[NewViewController alloc] initWithNibName:@"NewViewController" bundle:nil];
NSArray *items = [NSArray arrayWithObjects:@"Item 1", @"Item 2", @"Item 3", nil];
[vc setItems:items];
[vc setTitle:@"Items"];
[self.navigationController pushViewController:vc animated:YES];
[vc release];
[items release];

Here is the logic behind the code -

1. Create a new view controller
2. Create a new list to slam into the table view for the view controller and pop it in
3. Set the items array into the view controller
4. push the view controller into the navigation controller
5. releace the memory for the view controller as it is now owned by the navigation controller
6. and release the array since it is now owned by the view controller

Even now just looking at the code I just figured out what the problem is - I'm not actually creating a new instance of the items array. So by releasing it - my new view controller crashes because it's retain call got mistakenly released by someone else.

Simple problem - no big deal at all. My frustration really is that the app just crashes without any type of error at all... just a *blip* application died... Occasionally it would spit out this error:

Program received signal: “EXC_BAD_ACCESS”.

Which is not helpful at all - basically that means we accessed memory that we shouldn't have.

I agree whole heartedly that this is not a problem with Objective C - it all comes from my ignorance and lack of experience - however, it is still very frustrating.

-A

Testing and xCode

Java developers are spoiled.

I was a late comer to the testing band wagon. I'm not a test nazi by any stretch but there is a certain amount of confidence that testing gives you.

I miss that when I'm coding in Objective-C.

I was so happy today when I found out today that xCode has built in support for unit testing. But it sucks horribly. Granted much of my problem may be that I have not fully grokked the underpinnings of this environment. But I have spent all day and most of the night trying to figure it out and this is the extent of what I have figured out.

Unit tests that exercise simple parts of the application (non-framework/Cocoa stuff) can be tested after a build is performed. However:

• Debugging is not an option
• Capturing output from sysout is not an option
• Decent reports don't seem to be available
• Decent error reporting doesn't seem to be available

It's hard to believe that unit testing is so far behind on this platform. Java developers don't know how good they have it.