In my case, I had a singleton that handles all interactions with GameCenter, called DAGameCenter. With this, anywhere in my application I could simply report an achievement with a single call:

[[DAGameCenter sharedGameCenter] reportAchievement:@"com.mygame.achievement" 
                                 percent:100.0f];

DAGameCenter then tries to report the achievement to GameCenter and if it fails, archives it in a list of achievements to try reporting at another time. The proble comes in, as you probably guessed it, having a uniform method of displaying achievements to the user across all screens.

My first idea was to simply use a new UIWindow. UIWindow has properties for order the level of each window. I could simply create a new UIWindow, set the level to be above my keyWindow, and simply forward all events to my keyWindow so the user can still interact with the window below.

Problem

Apple advises against creating more than one UIWindow object. Your UIWindow is also already created for you by UIApplication when your app launches. So, things aren’t as simple as we would hope.

We can move up the object hierarchy a little bit to UIView, UIWindow’s parent class. We can simply put this view on top of our main view and all is peachy, right? Something like

OverlayView *myOverlay = [[OverlayView alloc] initWithFrame:frame];
[[[UIApplication sharedApplication] keyWindow] addSubView:myOverlay];

Not quite…simply adding a UIView to our existing UIWindow causes our interface to become unresponsive. This is because our newly added view is capturing all events. As our view doesn’t handle any events, it simply forwards the event up the responder chain, to our UIWindow, which then forwards it to our UIApplication, and then the event is ignored.

Our mainView and our overlayViews are not parent-child but they are both siblings of our UIWindow. This, in effect, creates our overlayView creates a second hierarchy of views in our application.

A quick and dirty solution would be to simply add a delegate to our overlayView and when creating our ourlayView set our mainView as the delegate. What happens when we push a second view above our mainView, say a settings screen. Our settings will become unresponsive unless we also remember to update our delegate.

So, this solution effectively loses maintainability after expanding beyond a single view and requires us to actively remember to set our delegates with navigation. It’s just asking for problems.

Our problems are two-fold: locating the view that is currently being displayed and then forwarding events to said view.

Solution

Forwarding events is quite simple. We simply need to overwrite the hitTest:withEvent method in our view.

It turns out that you can access a given view’s subviews with a simple call to…subviews. This returns an array, that’s helpfully ordered from back to front. UIView has a method that allows us to insert views above other views. UIWindow is a subclass of UIView, so all of this applies to it as well. We can gain access to an ordered array our subviews of our window anywhere in our application by simply calling subviews on our keyWindow.

As I’m sure you can probably guess by now, the solution. We simply need to insert our overlayView above our UIWindow. Then, we can forward events to the back-most subview that our window has.

When we push a modal view on to our UI to change screens from mainView to settings, it actually removes our mainView from our view hierarchy and replaces it with our settings view. This means that the “active” view will always be at 0.

All together, our code looks something like as follows:

// Somewhere in our Singleton. Add our view so it is always above all views in our window
// In my case, I have it in the block that runs when a player is authenticated with GameCenter
-(void)insertAchievementView {
    UIWindow *mainWindow = [[UIApplication sharedApplication] keyWindow];
    if(!_achievementView)
        _achievementView = [[DAAchievementView alloc] initWithFrame:[mainWindow frame]];
    [mainWindow insertSubview:_achievementView aboveSubview:mainWindow];
}

// Then, in our actual achievementView, forward our hitTests
- (UIView*)hitTest:(CGPoint)point withEvent:(UIEvent *)event {
    return [[[[[UIApplication sharedApplication] keyWindow] subviews] objectAtIndex:0] hitTest:point withEvent:event];
}

Conclusion

We can mimic the usage of a second UIWindow for displaying achievements of our application with a simple overlay view. Integrating the appropriate display methods of our overlay view in our singleton allows decoupling of the overlay and the view behind it, greatly reducing complexity. Furthermore, this decoupling allows all views in our application to utilize the overlay “for free”.

We built the application and submitted it near the beginning of September. 3 weeks later I got an email from Apple telling me that they had been trying to contact me and asked me for my phone number. After finishing the application and submitting the application I got a phone call from apple telling me that they didn’t accept Powerhour applications because it encourages consumption of something.

That single phone call singly handily killed a lot of excitement about the application for us, so we shelved it for a few months while I worked on Jisho.

Last week we picked it back up and reworked the idea a little bit and resubmitted. It only took 2 days for approval and I’m proud to announce that DisposableApps’ first application, Pubtunes is on the app store.

So please check it out. Let me know what you think.

As always, there is more to come from us.

Programmers are lazy. If you are going to have some no-frills text on the screen that does not change too often an UILabel is the way to go. Changing the is very simple. It’s just a matter of:

myLabel.text = @"Change that text!";

What happens when you do this, every second for 45+ minutes (that’s 2700+ updates)?

Problem

I noticed that with every update of that label in the manner above my consumed ram was growing. Not a lot, but a few bytes. Enough though that after 2700+ times, it was causing some problems. I must be leaking I thought. Pop up Instruments with Leaks and test. No leakage apparent. Perhaps it was getting cached somewhere in UIKit?

As my application was going to be getting the proof-of-concept UI completely rewritten, UILabel was going to be a placeholder unless I could be a good lazy programmer and continue to use them.

However with UILabel seemingly cacheing the old labels or something, using them is out of the question.

Solution

Most programmers aren’t going to be updating their labels very often. Let alone 2700+ times every second.

My solution was a combination of Quartz2D (to change the color of the string) and NSString’s drawing categories.

- (void)drawRect:(CGRect)rect {
    // Get the current context so we can draw.
	CGContextRef context = UIGraphicsGetCurrentContext();
 
	// Set the fill color to white. 
	CGContextSetFillColorWithColor(context, [[UIColor whiteColor] CGColor]); 
 
	//Draw in the specified rect
	[myString drawInRect:rect withFont:[UIFont fontWithName:@"Helvetica" size:16.0]  lineBreakMode:UILineBreakModeTailTruncation alignment:UITextAlignmentCenter];
 
}

Notes:

• This assumes that you have a property myString declared somewhere.
• You could probably improve performance a bit by cacheing the UIFont.
• By drawing our own strings we lose the convenience of having a CALayer ready to use.

Conclusion

I used the above code (of course modified for posting) in my application and poof my application was no longer growing. Moreover, it actually feels a bit snappier.

UILabel is great for displaying static or mostly static text on the screen. However if you are going to be updating it with any frequency, it is advantageous to draw text manually. UILabel uses the drawInRect: or drawAtPoint: methods to draw anyways, calling them directly saves your phone from a lot of unneeded calls. This equates to less execution faster which in turn means more battery life for your users. A win for everybody.