Today Ballies (and Ballies Lite) for the iPhone was released on the App Store. I started working on Ballies at the start of July and finished it in the first week of October. It was very much a learning experience for me — this being my first released iPhone application and my first game that’s actually moved to the published state. It also happens to be a fun game as well too. If you are interested, please go check it out on the App Store.

This was the first time that my uncle, Dave Munsie, and I have worked together on a game. I have to say it has been a very fun project and that this won’t be the last one we do together. I’m already deep into the next project, one that we hope to have out before Christmas. Go checkout Munsie Games for some more info.

But what if you want to do something different? For example, you are working on a game that has it’s own navigation hierarchy. Not only are you not using the normal UINavigationController usage model, but you also want to do something different visually besides sliding in the new view? Read on for one possible way of handling this.

The method that I am using involves having a custom root view controller object that manages the transitions between the other view controllers. The way I have it setup is that there is never more than 2 view controllers active at once — the root controller and whichever controller you are currently using. I’ll also point out that for this example, I am not using Interface Builder or XIB files. Everything is generated using code. Feel free to experiment on your own if you want to use IB.

To start, you will need to setup your root view controller class. This is simply a subclass of UIViewController:

    @interface MyRootController : UIViewController {
        UIViewController *activeController;
    }
    -(id)initWithController:(UIViewController *)aController;
    -(void)loadView;
    -(void)dealloc;
    -(void)crossfadeTo:(UIViewController *)aController duration:(float)aDuration;
    @end

We are going to implement a simple crossfade effect in this class — the crossfadeTo:duration: method will handle properly fading between the two views and properly disposing of the old view controller when done.

Let’s take a look at the initWithController: method next:

    -(id)initWithController:(UIViewController *)aController {
        if(!(self = [super initWithNibName:nil bundle:nil])) {
                return nil;
        }
        activeController = [aController retain];
        return self;
    }

As you can see, it is very basic — all we are doing here is just keeping the initial controller around so that we can use it later. The real work begins in loadView:

    -(void)loadView {
        self.view = [[[UIView alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];
 
        [activeController viewWillAppear:NO];
        [self.view addSubview:activeController.view];
        [activeController viewDidAppear:NO];
    }

The first thing we do is obtain a new UIView object that covers the screen. This is the view that will be used as the parent view for the active controller’s view. It will also hold the second controller’s view during an animation.

The next part is to hold up to the contract of UIViewController. Whenever a view will appear or disappear, there are four methods in UIViewController that need to be called: viewWillAppear:, viewDidAppear:, viewWillDisappear: and viewDidDisappear:. The parameter for all of these is a BOOL indicating if there is an animation happening. Since we are not animating the first view onto the screen, we say NO.

The dealloc method is basically the reverse of both the loadView and initWithController methods — we are just cleaning up all the toys we got out:

    -(void)dealloc {
        [activeController viewWillDisappear:NO];
        [activeController.view removeFromSuperview];
        [activeController viewDidDisappear:NO];
 
        [activeController release];
        [super dealloc];
    }

Notice that we are calling viewWillDisappear: and viewDidDisappear: to keep up our end of the contract again.

At this point, we have enough code for our view to show up on the screen and for us to not leak any resources when we are done with the view controller. But that’s not why we are here — we’re here to do some custom animations between two view controllers. Let’s take a look at how to do a crossfade:

    -(void)crossfadeTo:(UIViewController *)aController duration:(float)aDuration {
        [aController viewWillAppear:YES];
        [activeController viewWillDisappear:YES];
 
        aController.view.alpha = 0.0f;
        [self.view addSubview:aController.view];
 
        [aController viewDidAppear:YES];
 
        [UIView beginAnimations:@"crossfade" context:nil];
        [UIView setAnimationDuration:aDuration];
        aController.view.alpha = 1.0f;
        activeController.view.alpha = 0.0f;
        [UIView commitAnimations];
 
        [self performSelector:@selector(animationDone:) withObject:aController afterDelay:aDuration];
    }
 
    -(void)animationDone:(UIViewController *)aNewViewController {
        [activeController.view removeFromSuperview];
        [activeController viewDidDisappear:YES];
        [activeController release];
 
        activeController = [aNewViewController retain];
    }

There are two parts to this code — first we start the animation in crossfadeTo:duration: and then finish it up in animationDone:. The intent with animationDone: is that you should be able to reuse this method for whatever animations you feel like implementing. All of the animation setup is done in crossfadeTo:duration:. Let’s take a closer look at that code:

    [aController viewWillAppear:YES];
    [activeController viewWillDisappear:YES];

The first part is just about keeping the contract again. In this case, we have both a view that is about to appear and another one that is about to disappear. Notice that we are passing YES since we are going to be doing an animation this time.

    aController.view.alpha = 0.0f;
    [self.view addSubview:aController.view];

Next we add our new view to our parent view with the alpha set to zero. The new view needs to be a part of the view hierarchy for it to eventually get to the screen, and we don’t want it covering up the current view yet.

    [aController viewDidAppear:YES];

Since we added our new view, we need to let the view controller that it’s now visible. Even though the alpha is set to zero at this point, it’s part of the view hierarchy and is active. Therefore, we need to make sure the controller knows.

    [UIView beginAnimations:@"crossfade" context:nil];
    [UIView setAnimationDuration:aDuration];
    aController.view.alpha = 1.0f;
    activeController.view.alpha = 0.0f;
    [UIView commitAnimations];

This part is the animation code. All we are really doing for the animation is just changing the alpha on our new view from zero to one and the alpha on the old view from one to zero. We set the duration to the passed in value and then kick off the animation with the commitAnimations call.

    [self performSelector:@selector(animationDone:) withObject:aController afterDelay:aDuration];

This last bit of code is to kick off a call to animationDone: when the animation is actually done. There are methods in UIView to setup a callback method (setAnimationDelegate: and setAnimationWillEndSelector:), but when I attempted to use them with the 2.2 SDK, I ran into issues with the callback being called at the wrong time. If you are using a newer SDK, you might be able to use these methods, but the performSelector:withObject:afterDelay: method should work just as well for our needs.

The second part of the transition is in animationDone: method. It has two parts — the first part is to finish up with our view controller we just transitioned off the screen:

    [activeController.view removeFromSuperview];
    [activeController viewDidDisappear:YES];
    [activeController release];

We are simply removing the view, letting the view controller that we did remove it and finally releasing the controller.

    activeController = [aNewViewController retain];

On the new controller side, we are now finally going to retain the new object. We haven’t had to retain it up until this point because it was always being retained for us — the performSelector:withObject:afterDelay: method retains the object that you pass to the withObject: parameter.

And with this, our crossfade animation is complete and we now have a new active view controller. If you’ve been playing along at home, you should be able to see this for yourself.

To use your new view controller, simply do this in your appDidFinishLaunching::

    window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    controller = [[MyRootController alloc] initWithController:[[[MyFirstViewController alloc] init] autorelease]];
    [window addSubview:controller.view];

And when you want to crossfade between two views, do something like this:

    [controller crossfadeTo:[[[MySecondViewController alloc] init] autorelease] duration:2.0f];

I’ll leave it as an exercise for the reader as to how to create MyFirstViewController and MySecondViewControler. These are just subclasses of UIViewController.

I hope that this gets you started with doing different animations between view controllers than simply the stock animations that Apple provides with the UIViewController class.

For more information regarding the classes that I’ve used above, please take a look at these links:
http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIViewController_Class/Reference/Reference.html
http://developer.apple.com/iPhone/library/documentation/UIKit/Reference/UIView_Class/UIView/UIView.html

-(float)invokeGetSelectorForField:(NSString *)fieldName inObject:(id)o {
    float value;
    SEL fieldGetSelector = NSSelectorFromString(fieldName);
    NSInvocation *i = [NSInvocation invocationWithMethodSignature:
        [[o class]
        instanceMethodSignatureForSelector:fieldGetSelector]];
    [i setSelector:fieldGetSelector];
    [i setTarget:o];
    [i invoke];
    [i getReturnValue:&value];
    return value;
}

But what if you need to call this getter multiple times? Maybe hundreds or thousands of times? In this case, you can keep your NSInvocation object around and then simply invoke and then call getReturnValue: on it anytime you need to make the call. You can change the target of the NSInvocation to point to a completely different object. Or even change the selector. Pretty much anything you want to change you can. So instead of the above code, do something like this instead:

In your init method:

    SEL fieldGetSelector = NSSelectorFromString(fieldName);
    fieldGetInvocation = [[NSInvocation invocationWithMethodSignature:
        [[o class]
        instanceMethodSignatureForSelector:fieldGetSelector]] retain];
    [fieldGetInvocation setSelector:fieldGetSelector];
    [fieldGetInvocation setTarget:o];

In your dealloc method:

    [fieldGetInvocation release];

And then when you need to call it:

    float value;
    [fieldGetInvocation invoke];
    [fieldGetInvocation getReturnValue:&value];

Doing this can easily end up saving a lot of CPU usage in your application, depending on how often you are calling the method. In my current project, I went from 20% usage in calling the setter and getters down to effectively 0% when measured with Instruments. All of that time was being eaten up in creating and destroying NSInvocation objects. Certainly not the best usage of the limited resources on the iPhone.

For more information on the NSInvocation class, please take a look at the documentation on Apple’s site: http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/nsinvocation_Class/Reference/Reference.html

First up, you need a project to work in — I’m using the OpenGL ES Application template in XCode for this. Also, I’m using the 3.0 SDK. This should apply just the same to earlier SDK versions, but there may be minor differences.

Out of the box, this project will use an orthogonal view. But it isn’t in widescreen mode, and the 0,0 is in the center of the screen. This might be fine for some uses, but if you are porting code that expects 0,0 to be someplace else, this just isn’t going to work. For this example, we are going to setup the scene so that 0,0 is the bottom left and 480,320 is the top right.

First off, lets change the method -(id)initWithCoder:(NSCoder*)coder. Underneath the line:

    animationInterval = 1.0 / 60.0;

put in the following code:

    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glRotatef(-90.0f, 0.0f, 0.0f, 1.0f);
    glOrthof(-480.0f / 2.0f, 480.0f / 2.0f, -320.0f / 2.0f, 320.0f / 2.0f, -1.0f, 1.0f);
 
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    glTranslatef(-480.0f / 2.0f, -320.0f / 2.0f, 0.0f);

What we are doing here is setting up our two matrices — the projection matrix and the model/view matrix. We rotate the matrix -90 degrees so that we will be in widescreen mode with the home button on the right. If you want to flip it the other way, just rotate +90 degrees instead. Once we’ve done that, we can setup our orthogonal projection with the bottom left being 0,0 and the top right being 480,320.

For the model/view matrix, all we need to do is just translate the matrix so that the bottom left is 0,0 and the top right is 480,320.

Down below in the -(void)drawView method, you need to remove this block of code:

    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glOrthof(-1.0f, 1.0f, -1.5f, 1.5f, -1.0f, 1.0f);

Since we are setting up the projection matrix in our initialization code, we do not need to reset it every time we draw a frame. Also you will need to replace this block of code:

    const GLfloat squareVertices[] = {
        -0.5f, -0.5f,
         0.5f, -0.5f,
        -0.5f,  0.5f,
         0.5f,  0.5f,
    };

with this:

    const GLfloat squareVertices[] = {
        -120.0f, -120.0ff,
         120.0f, -120.0ff,
        -120.0f,  120.0f,
         120.0f,  120.0f,
    };

The old coordinates were based on 0,0 being in the center of the screen and that the width/height of the screen was 2.0 and 3.0. We also need to change where it is drawn. We can do that by adding the following code right before the glMatrixMode(GL_MODELVIEW) call:

    glPushMatrix();
    glTranslatef(480.0f / 2.0f, 320.0f / 2.0f, 0.0f);

and this after the glDrawArrays() call:

    glPopMatrix();

It should look like this now:

A couple of quick notes — you probably noticed that the glTranslatef() in drawView cancels out the one in initWithCoder:. This is really only for demo purposes. In my projects, I do rotation and translation myself so that I can take advantage of calling glDrawArrays() for a batch of objects instead of sending them to GL one at a time. But that’s beyond the scope of this article. The other thing is that if you run this project right now, you’ll also notice that it’s still not in widescreen and it’s no longer rotating the cube. The first is really easy to fix. Open the plist file for your project — mine is called OrthoGL-Info.plist and it’s located in Resources. You need to add the following flag:

You can add a new entry by clicking on the + button that shows up when you click on any line. It doesn’t matter where in the file the flag is — you can put it anywhere.

That fixes the first problem, but the second problem still remains. We lost rotation when we added the glPush/PopMatrix() calls. This one is fairly easy to fix as well. Simply add a new instance variable to the EAGLView.h file. Call it rotation with a GLfloat type:

and then replace the glRotate() in drawView with this:

    rotation += 3.0f;
    glRotatef(rotation, 0.0f, 0.0f, 1.0f);

All done!

I hope at this point you have enough to get started with 2D projection in widescreen on the iPhone. Please let me know in the comments below any questions you may have, and I’ll try to answer them. Maybe if there is enough interest, I can do a follow up article as well.

#include <stdio.h>
 
class Foo {
public:
    void doStuff() {
        printf("hi from Foo!\n");
    }
};
 
int main(int argc, char *argv[]) {
    Foo *f = NULL;
 
    f->doStuff();
    return 0;
}

If you said it would crash because of the NULL pointer, you are wrong. This code will actually print “hi from foo” to the console. Why? Because as long as you are not calling any functions that use instance variables or are virtual, the NULL pointer is never dereferenced. And if you know how C++ handles member functions, you should know exactly why.

For the record, I ended up spending a few hours at work today tracking down an issue that ended up being caused by a NULL pointer call. The bug had actually been lurking for a few releases and only when the method being called was modified to use an instance variable did the problem become exposed.

We picked up a VideoNow player over the weekend for a dollar at a yard sale. It immediately was a hit with the kids, but I was curious about the video format. It took me some searching around, but I was able to find enough information to bang out a quick and dirty player for the Mac using OpenGL and CoreAudio. It doesn’t have a GUI, but it works pretty well for a few hours of work I think. If this is something you were looking for, enjoy!

videonow.cpp

As for me, I’ll be waiting a bit longer for the jump to 3G. I currently have a 8GB iPhone and 16GB iPod touch — I was really set on replacing both devices with a 32GB iPhone, but it looks like I’ll have to wait a bit more for that option to show up. As good of a deal the new iPhone is, I just don’t think it’s good enough to warrant an upgrade from a 1st gen iPhone unless you happen to have one of those 4GB models. 3G looks like it will be fantastic, but it comes with an extra $10/month over the existing iPhone data plan. GPS also will be welcome, but I personally don’t see it worth the extra cost associated with switching to a 3G iPhone will incur at the moment.

Now as soon as that 32GB model comes out, I’ll make the jump over to 3G…

What this article seems to miss (along with all of the makers of “iPhone killers”) is that it’s not about putting a shiny touch screen on a phone or putting a fresh paint job on the UI while keeping the behavior the same (hello Blackberry 9000…). What Apple has been consistently doing ever since Steve Jobs came back in the mid 90s is building flashy products that work with people rather than making people work with them. Most people seem to focus on the flashy side of things — but it would be much more beneficial to focus on the human interface side. This is Apple’s strength.

Lets take the iPod/iTunes juggernaut as an example. On the surface of things, an MP3 player should be a commodity item at this point. You can build one out of a handful of off the shelf parts — hard drive, small embedded processor, some RAM, a display, some buttons for controls. Bring in an open source OS like Linux, and voila, you have an MP3 player. You don’t even have to write much software, since you can easily find tons of open source libraries to use to build your device.

Yet somehow, Apple still has a commanding lead with the iPod and iTunes — even the demise of DRM hasn’t seemed to hurt Apple yet. In fact, the recording industry appears to be actively trying to knock away at the iPod/iTunes duo by licensing their music in DRM free formats to everyone but iTunes.

So what is it about the iPod that keeps people buying iPods over devices that looks similar but cost much less? It’s the software of course — the part of the equation that makes it work just as good as it looks. What Apple’s competitors seem to overlook is that having the best hardware in the world is worth nothing when your software isn’t anywhere near where it needs to be.

Let’s take loading music onto a device — with iTunes, if your music collection is small enough to fit on the device, iTunes will automatically load it all in. If it’s not, iTunes will offer to pick a subset for you based on how you rated your music (higher rated songs go on the iPod, lower ones don’t). If you don’t like that, you can easily just say no and then you can pick playlists that you want to go on instead. The loading of the songs takes place over the included iPod USB 2.0 cable via your PC or Mac.

What about on the cheap knockoff iPod-lookalike MP3 player? Well more than likely, either you will have a memory card that you have to take out of the player and insert into a reader on the PC or you will connect it up via a USB connection. Once you do this, you will have a new drive show up on your Desktop (Mac) or in My Computer (PC). From there, you can copy MP3 files to the device. Where are your MP3 files to begin with? Oh you don’t know? What if you want playlists? Do you set them up in folders or lump them all together in one folder? Does the device even play this filetype?

iTunes takes care of all of those details — and more. I don’t care about how the files are organized on the iPod because I don’t need to know. If a file won’t play on the iPod, iTunes will tell me and not bother copying over the file. And any playlist I make in iTunes will automatically be available on the iPod if I choose to sync it over.

So back to my original topic — this Nokia iPhone killer. I’ve used a few Nokia devices, and from my own experience they don’t have the works-with-people part of the equation down. They’ve managed to make what is, in my opinion, clumsy interfaces that just don’t work in the same ways that interfaces that Apple makes. This isn’t just blind fanboyism at work here — this is based on my own observations of watching people who know very little to nothing at all about computers actually use things like the iPod and iPhone without assistance. It’s based on watching some of these same people, when given other devices, barely make due with them. Sure, they’ll eventually figure them out enough to get by with using them — but they never really feel comfortable with them.

Apple makes products that people are capable of feeling comfortable working with. That’s why until companies focus on making products that work with people instead of the other way around, there won’t be a real iPhone killer coming out anytime soon.

EDIT: After posting this, I realized that I might’ve not conveyed my thoughts accurately regarding BlackBerry. I am more disappointed with the BlackBerry 9000 not because it’s a bad device, but because instead of playing off their strengths, they went for the iPhone shiny look. Obviously the BlackBerry is a good device — I’ve seen a lot of non-technical people carrying them around, getting along with them just fine. But by trying to ape some of the design elements from the iPhone, I think they are unfairly putting themselves up against the iPhone when they weren’t really in the same market. At least not the original iPhone software — it seems as if Apple has recognized that RIM considers them to be a threat and has really made sure that the 2.0 firmware for the iPhone will address some deficiencies that the iPhone had when compared against the BlackBerry. But I digress. IMO, if RIM would’ve worked on improving the things that got it to where it is in the marketplace today instead of focusing on the trying to out iPhone the iPhone, I think the BlackBerry 9000 would be a very different piece of hardware. And I think that because of that, it might’ve had a better chance to survive the upcoming iPhone onslaught with the 2.0 firmware. It will probably still be a very successful device, but I’m sure there will be quite a few RIM customers who see the resemblance to an iPhone, find out that it’s not quite the same, and end up as new Apple customers because of it.