At the time, having a full, professional grade IDE available for free was mostly unheard of. Compared with Visual Studio, who’s minimum entrance fee was in the range of $1000. Students, of course, got a discount. Since then having a free IDE on your platform has become the norm. If this is because of Xcode or not, I am not sure.

Suddenly, for the first time, Xcode has a price for non-paid developers: $4.99. There has been an uproar as to what open source developers and people who are interested in learning to program will do. That Apple is somehow taking away a lot from developers by adding this barrier to entry. I would argue, they aren’t.

Open source developers often list Xcode as a dependency for those that wanted to compile from source, not because the project required Xcode, but because it installed the requisite compilers. If having Xcode as a dependency is not something that developers want, then the community is going to need to pick up the slack as per keeping the toolchain current and packaged. As these tools are open source, it shouldn’t be that difficult to do (although we do know what happens when we say shouldn’t….)

Ignoring the argument that if you can afford a Mac, and you’re interested in learning to program, you can afford $5 dollars for tools to develop with. More than likely, the book you pick up to learn Objective-C will cost a heck of a lot more than that.

At the end of the day, any serious mac developer is going to have the $99 dollar subscription to the Mac developer program. If you’re looking to learn to program for the Mac, 5 dollars is a minimal investment for access to a world class development tools. If you’re just looking to program on your Mac but don’t want to spend the $5 for Xcode or $99 for the developer subscription, learn a language different than Objective-C. There are many build in programming languages in OSX, including Python and Ruby.

As for me? I will keep my paid developer accounts ignore the rest of the uproar.

I was looking for some way to display a Title as regular, then right under it some kind of subtitle. Naturally, NSMenuItems are designed to handle just a single title. It seemed like if I wanted to display anything other than a single title, I was going to have to take advantage of NSMenuItem’s new ability to host a generic NSView.

Problem

Getting your custom NSView in to a NSMenuItem is easy. I actually got it displaying rather nicely. The problems came when I wanted my NSView and NSMenuItem to behave like they would as per regular.

1. Passing clicks from my NSView to the NSPopupButton proved to be rather difficult. Moreover, it felt like a huge kludge as it tied these items to a single control. I also wanted to reuse these in the menu up top.

2. Even with the kludge, I decided to proceed on. Next up was displaying the checkbox (NSOnState) image. For some reason, the checkbox image returned by [NSImage imageNamed:NSOnStateImage] is different from the checkbox image used in the rest of the system. It was skinner and looked out of place.

Overall, making a custom view with this much kludge and not quite feeling right grated on me. I wasted 2 days to get this far, but it doesn’t live up to the user experience that I want to give users and expect from software on the Mac.

Solution

In my rush to get my NSMenuItem running, I overlooked a a critical feature: NSMenuItem titles can take an NSAttributedString.

When initializing your NSMenuItem we can use an attributed string to set our colors. \n also works for creating new lines.

// assume we have an NSMenuItem alloc'ed/init'ed named item.
// we also have a model objected that responds to the "title" and "subtitle" messages 
// named myObject

NSString *title = [NSString stringWithFormat:@"%@\n%@",[myObject title],[myObject subtitle]];
NSMutableAttributedString *attributed_title = [[NSMutableAttributedString alloc] initWithString:title];
        
// This is the system default for controls. anything else and it looks off
NSDictionary *title_options = [NSDictionary dictionaryWithObjectsAndKeys:[NSFont fontWithName:@"Lucida Grande" size:13.0f],NSFontAttributeName,nil];

//make our subtitle a different color as it is just auxillary information 
NSDictionary *sub_title_options = [NSDictionary dictionaryWithObjectsAndKeys:[NSColor disabledControlTextColor],NSForegroundColorAttributeName,nil];

// apply our color attributes to the ranges of the string they are applicable to...
[attributed_title addAttributes:title_options range:[title rangeOfString:[myObject title]]];
[attributed_title addAttributes:sub_title_options range:[title rangeOfString:[myObject subtitle]]];

// finally set our attributed to the menu item
[item setAttributedTitle:attributed_title];
[item setRepresentedObject:myObject];

// clean up
[attributed_title release];

With the above in place we are halfway there. Our new shiny menu item looks great and it fits in. Most importantly there is zero kludge. Actions go where we want them when we want them. The NSOnState image looks like it does in the rest of the system. Life is hunky-dory.

Until we highlight it.

Our title and state images turn white when highlighted as expected. However, our subtitle…not so much.

Luckily we can fix this without too much trouble. NSMenu’s has a lovely delegate that tells us when it is about to highlight something with it’s menu:willHighlightItem: call. “Will” is the keyword that we tips us of we can use this. It means that our currently highlighted item is still selected, so we can revert any changes made.

*Update: * I had left a huge block of code that smelled bad and left it as an exercise to the reader to clean it up. I decided to remove some of the smell myself. If you have ideas on how the code below could be refactored even better, please let a comment below.

// set our controller to be the delegate of our NSMenu. In the case of a NSPopupButton, 
// you can access it with the [myButton menu] method.

- (void)setForegroundColor:(NSColor *)foregroundColor 
    onAttributedString:(NSMutableAttributedString *)attributedString 
    forRangeOfString:(NSString *)string {

    NSRange range = [[attributedString mutableString] rangeOfString:string];
    NSDictionary *attributes = [NSDictionary dictionaryWithObjectsAndKeys:foregroundColor,NSForegroundColorAttributeName,nil];
    
    [attributedString setAttributes:attributes range:range];
    
}

- (void)willHighlightItem:(NSMenuItem *)item currentlyHighlightedItem:(NSMenuItem *)currentItem {
    
    if (currentItem != nil) {
        NSString *subtitle = [(MyModelObject *)[currentItem representedObject] subtitle];
        NSMutableAttributedString *attributedString = [[currentItem attributedTitle] mutableCopy];

        [self setForegroundColor:[NSColor disabledControlTextColor] onAttributedString:attributedString forRangeOfString:subtitle];
                
        [currentItem setAttributedTitle:attributedString];
        [attributedString release];
    }
    
    NSString *subtitle = [(MyModelObject *)[item representedObject] subtitle];
    NSMutableAttributedString *attributedString = [[item attributedTitle] mutableCopy];
    
    [self setForegroundColor:[NSColor selectedMenuItemTextColor] onAttributedString:attributedString forRangeOfString:subtitle];

    [item setAttributedTitle:attributedString];
    [attributedString release];
}

Conclusion

With just the few lines of code above, we can create a custom looking NSMenuItem that behaves exactly as we would expect it to. What’s more by using an NSAttributedString isntead of a custom view, our “custom control” get accessibility for free. This means users with impaired sight get the same first-class experience as everyone else. Talk about a win-win-win.

When I first started writing Jisho, my hammer of choice was Objective-C. All projects, no matter their suitability, were developed in Objective-C. I even wished that Apple would have continued NeXT’s support for WebObjects in Objective-C. Afterall, everything is nail.

This meant that things that probably should have never been written in Objective-C were written in Objective-C. That’s not to say that the things I wrote couldn’t be written in Objective-C, indeed, they could, but that it would have been better to pick a different tool. A rock can break a piece of wood in two, which is great if you just need two random lengths of wood, but if you need any more precision, you should use a saw. Objective-C and Python can both parse xml, but the former takes a lot more effort than the later.

I eventually came to my senses and realized that my supporting application was not scaling the way I had hoped. It needed to be rewritten. What did I do? I picked the same hammer again, foolishly expecting different results.

It worked great for a while – until it didn’t. Features only came after great reluctance if at all. I knew it needed to be rewritten, again.

This time around, I have a wider skillset than I did when I first started Jisho. I know a few more scripting languages reasonably well. Some I like a lot more than others.

While I am still in the process of writing the parser, it’s coming together much quicker than the old versions ever did. More importantly, it doesn’t read like a bunch of voodoo magic. These tools excel for things like this. We should use them.

Today, Objective-C is still one of the most important hammers in my toolbox – perhaps even my favourite. But sometimes you need a saw.

As a software developer if you think something would be easier with a different tool, try it and find out. Best case scenerio you’re right and you’ve learned a new tool. Worst case scenario is you’ve learned a new tool and expanded your skillset. You can’t lose.

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”.

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.