If your Eternal Score does not advance or is not saved properly, just follow these three steps:

1. Enter Eternal Mode
2. Save the game and exit
3. Re-enter the Eternal Mode

This should fix the issue. Thank you for your patience!

Right now I can’t really come up with more than “It’s free, go get it!!!”. Maybe “It has full retina support” will get your motor running…

If you want some more info go to the details page for MatchBalls! Otherwise head straight to the App store and download that sucker.

My app is a universal app, so I have to fit all the different resource sizes in one application bundle. Before the iPad retina display was visible on the horizon, I hardcoded the iPhone retina image names into the iPad classes. But there is a better way which follows Apple’s guidelines and works with less code. Classic win-win

The Apple guidelines state:

Applications running in iOS 4 should now include two separate files for each image resource. One file provides a standard-resolution version of a given image, and the second provides a high-resolution version of the same image. The naming conventions for each pair of image files is as follows:

• Standard: <ImageName><device_modifier>.<filename_extension>
• High resolution: <ImageName>@2x<device_modifier>.<filename_extension>

The <ImageName> and <filename_extension> portions of each name specify the usual name and extension for the file. The <device_modifier> portion is optional and contains either the string ~ipad or ~iphone. You include one of these modifiers when you want to specify different versions of an image for iPad and iPhone. The inclusion of the @2x modifier for the high-resolution image is new and lets the system know that the image is the high-resolution variant of the standard image.

Let’s assume our image is supposed to be called “name” (creative… I know). We need to supply four image resources. The iPhone resources are supposed to have the ~iphone suffix and accordingly the iPad resources need the ~ipad suffix and the @2x for the retina display is in between the name and the suffix. So this is what we get:

• name~iphone.png
• name@2x~iphone.png
• name~ipad.png
• name@2x~ipad.png

It is important that the suffix is all lowercase. At first I tried to use ~iPhone and ~iPad but that did not work for me. It needed to be lowercase. Maybe that’s normal but maybe I screwed something up. Go ahead and test both versions if you like. If you find they are both working feel free to leave a comment below.

Wait, that’s not exactly what I want!

Before updating to iPad retina, I simply hardcoded the iPhone retina image names into the iPad classes and thusly only needed 2 image sizes for the iPhone, iPhone retina and the iPad. With this naming convention there is no need to do that any more because [UIImage imageNamed:@"name.png"]; handles the loading of all different image sizes for me. But there is one problem: I do not want to have iPhone retina images and iPad images because they are the same.

Reusing iPhone retina images as the non-retina iPad versions can be achieved by simply symlinking them. To do that, just open a Terminal window and navigate to the folder the image is located in. Let’s say its called “name” (creativity… you know ). Thus its retina version is called “name@2x~iphone.png”. All you have to do is type the following to have you iPad images:

ln -s name@2x~iphone.png name~ipad.png

You however should not try to create subfolders for your iPad resources and symlink across folders. AFAIK the folder tree is flattened in your app bundle and the symlinks wouldn’t be pointing to the right resources anymore.

MatchBalls! was already submitted to Apple for review but now that I am able to test-drive it in retina my designer and myself are working hard to have retina support live ASAP. It would be awesome to be able to have a fully retina-ready app in the store at launch time for a retina iPad.

Here is the first screen with full retina support. The others are taking a bit longer… there are lots of graphics to produce and I can’t help all that much. Graphics still aren’t my strong suit.

Funny that a retina iPad app can’t even be displayed entirely on a 27″ iMac. On my 15″MBP it displays like a fifth of the screen – must be fun for developers with an 11″ MBA

The Problem

I sigh on the inside because I know it can’t be inserted in the app as an image. The text needs to be localized and IMHO it’s not nice to localize images. I know that text outlines are the most basic thing for someone who is used to Photoshop and the like, but creating those for an iOS app can be a pain.

With my newest game – MatchBalls! – that happened again. He created artwork and I tried to make it work without the outline, but it did not come out the way it was supposed to look. The design as a whole depends on the outline. So I decided I needed a dedicated class to do what I want for future use.

The Solution

I went to write my own UILabel subclass KSLabel which is supposed to free me from future headaches. I want it to optionally create text with a gradient and/or an outline. So here is what I did.

Step 1: Subclass UILabel. duh!

Step 2: Add properties drawOutline and drawGradient to make the gradient and the outline optional.

#import 

@interface KSLabel : UILabel {
    BOOL drawOutline;
    BOOL drawGradient;
}

@property BOOL drawOutline;
@property BOOL drawGradient;

@end

Step 3: Override -(void)drawTextInRect:(CGRect)rect.

This is where the work is done. First we let our parent class UILabel draw the text as it would normally do. We create an image using that shape and fill the shape with our gradient. If we want to draw an outline around that text, we save that image for later. Then we draw an outline around that shape with a 4px border. Sadly that kills the gradient because the outline is drawn 4px inwards and 4px outwards of that shape. But hey, thats why we saved the the gradient image before. Now we can just slam that on top of the outline and we have our final outlined gradient text.

Update: The last version was a bit outdated. Since ARC does not handle CG objects I have to release those manually: CGImageRelease(alphaMask);.

- (void)drawTextInRect:(CGRect)rect {
	CGContextRef context = UIGraphicsGetCurrentContext();  

	CGContextSaveGState(context);
	CGContextSetTextDrawingMode(context, kCGTextFill);    

	// Draw the text without an outline
	[super drawTextInRect:rect];

	CGImageRef alphaMask = NULL;

	if (drawGradient) {
		// Create a mask from the text
		alphaMask = CGBitmapContextCreateImage(context);

		// clear the image
		CGContextClearRect(context, rect);

		CGContextSaveGState(context);
		CGContextTranslateCTM(context, 0, rect.size.height);

		// invert everything because CoreGraphics works with an inverted coordinate system
		CGContextScaleCTM(context, 1.0, -1.0);

		// Clip the current context to our alphaMask
		CGContextClipToMask(context, rect, alphaMask);

		// Create the gradient with these colors
		CGFloat colors [] = {
			22.0f/255.0f, 107.0f/255.0f, 168.0f/255.0f, 1.0,
			71.0f/255.0f, 160.0f/255.0f, 220.0f/255.0f, 1.0
		};

		CGColorSpaceRef baseSpace = CGColorSpaceCreateDeviceRGB();
		CGGradientRef gradient = CGGradientCreateWithColorComponents(baseSpace, colors, NULL, 2);
		CGColorSpaceRelease(baseSpace), baseSpace = NULL;

		CGPoint startPoint = CGPointMake(CGRectGetMidX(rect), CGRectGetMinY(rect));
		CGPoint endPoint = CGPointMake(CGRectGetMidX(rect), CGRectGetMaxY(rect));

		// Draw the gradient
		CGContextDrawLinearGradient(context, gradient, startPoint, endPoint, 0);
		CGGradientRelease(gradient), gradient = NULL;
		CGContextRestoreGState(context);

		// Clean up because ARC doesnt handle CG
		CGImageRelease(alphaMask);
	    }

	if (drawOutline) {
		// Create a mask from the text (with the gradient)
		alphaMask = CGBitmapContextCreateImage(context);

		// Outline width
		CGContextSetLineWidth(context, 4);
		CGContextSetLineJoin(context, kCGLineJoinRound);

		// Set the drawing method to stroke
		CGContextSetTextDrawingMode(context, kCGTextStroke);

		// Outline color
		self.textColor = [UIColor whiteColor];

		// notice the +1 for the y-coordinate. this is to account for the face that the outline appears to be thicker on top
		[super drawTextInRect:CGRectMake(rect.origin.x, rect.origin.y+1, rect.size.width, rect.size.height)];

		// Draw the saved image over the outline
		// and invert everything because CoreGraphics works with an inverted coordinate system
		CGContextTranslateCTM(context, 0, rect.size.height);
		CGContextScaleCTM(context, 1.0, -1.0);
		CGContextDrawImage(context, rect, alphaMask);

		// Clean up because ARC doesnt handle CG
		CGImageRelease(alphaMask);
	}
}

Step 4: Test-drive it.

KSLabel *myLabel = [[KSLabel alloc] initWithFrame:CGRectMake(0, 0, 320, 80)];
myLabel.drawOutline = YES;
myLabel.drawGradient = YES;
myLabel.text = @"Text with gradient and outline";
myLabel.textAlignment = UITextAlignmentCenter;
myLabel.font = [UIFont fontWithName:@"Ballpark" size:60];
[self addSubview:myLabel];

The Result

Here is what text with a gradient and an outline looks like. This screen is shown right before a game of MatchBalls starts and it works like a charm. The “MatchBalls” at the top of the screen is an image – THE image – I wanted to mimic with my code (except for the arc). I think it works quite nicely.

I’m a nice guy, so you can just download the complete class here.

BTW: I love the font. Another good pick by my designer. The font is called Ballpark Weiner and you can download it here.

The Future

I would actually like to enhance my code by make the colors and the outline thickness variable. For this project that was not necessary so I didn’t. I will definitely update this post when I’ve had the time to make the class more reusable. Maybe I’ll even open up a GitHub account. Been wanting to do that for quite some time.

The problem

The input box is so far down in the view that it gets covered by the keyboard as soon as its activated. Now the user can enter his nickname but he can not see what he is typing. That is just not acceptable.

The solution

The naive solution would be to move the input field up so that the keyboard won’t block it. But that is unsatisfying. There must be a better solution… and there is: Just register for the Keyboard notifications and move the View up exactly as much as the keyboards height.

Step 1: Register for the appropriate notifications. Specifically the UIKeyboardWillShowNotification and the UIKeyboardWillHideNotification. Using the following commands the method -(void)keyboardWillShow will be executed when the keyboard appears and the method -(void)keyboardWillHide will be executed when the keyboard disappears.

[[NSNotificationCenter defaultCenter] addObserver:self
                                selector:@selector(keyboardWillShow)
                                    name:UIKeyboardWillShowNotification
                                  object:nil];

[[NSNotificationCenter defaultCenter] addObserver:self
                                selector:@selector(keyboardWillHide)
                                    name:UIKeyboardWillHideNotification
                                  object:nil];

Step 2: Implement the methods you just registered with the Notification Center. One method moves the view out of the way and the other moves it back into place. Quite simple when know it. -(void)keyboardWillShow moves the view 160px upwards. In my case that looked nice. Maybe you need to change that value to suit your needs.

-(void)keyboardWillShow {
	// Animate the current view out of the way
    [UIView animateWithDuration:0.3f animations:^ {
        self.frame = CGRectMake(0, -160, 320, 480);
    }];
}

-(void)keyboardWillHide {
	// Animate the current view back to its original position
    [UIView animateWithDuration:0.3f animations:^ {
        self.frame = CGRectMake(0, 0, 320, 480);
    }];
}

Step 3: Tidy things up. At some point you really should remove your listener from the notification center. Otherwise, from that point on, your listener will be called for every keyboard that appears and most likely your listener will not be around for that… which ends badly.

// If you want to remove the listener completely just use this one line
[[NSNotificationCenter defaultCenter] removeObserver:self.view];

// If you want to remove the listener for the 2 notifications and nothing more, then use the following lines
[[NSNotificationCenter defaultCenter] removeObserver:self
                                name:UIKeyboardWillShowNotification
                                object:nil];

[[NSNotificationCenter defaultCenter] removeObserver:self
                                name:UIKeyboardWillHideNotification
                                object:nil];

The Result

Upon activating the input field the view moves smoothly out of the way and when you press “Done” the view moves back to where it was before.

Possible Problems

Currently the time for the keyboard to show is 0.3 seconds, but Apple may change that at any time. This is also true for the keyboard size. The default keyboard in portait mode is 216px in height and in landscape it is 162px, but that may also change at any time. If (for any reason) you need to find out the keyboard size you can do that pretty easily.

// Register for the event including the notification
// notice the ':' after the selector 'keyboardWillShow' ?
[[NSNotificationCenter defaultCenter] addObserver:self
                                selector:@selector(keyboardWillShow:)
                                    name:UIKeyboardWillShowNotification
                                  object:nil];

// Read the userInfo for the key UIKeyboardFrameBeginUserInfoKey
-(void)keyboardWillShow:(NSNotification*)notification {
    NSDictionary* keyboardInfo = [notification userInfo];
    NSValue* keyboardFrameBegin = [keyboardInfo valueForKey:UIKeyboardFrameBeginUserInfoKey];
    CGRect keyboardFrameBeginRect = [keyboardFrameBegin CGRectValue];

    NSLog(@"%@", NSStringFromCGRect(keyboardFrameBeginRect));
}

Take your time

When I started developing MatchBalls! I created four In-App Purchases in iTunes Connect and started testing after a while. Yesterday I added an additional IAP to iTunes Connect and suddenly started getting errors with all of my IAPs. I started debugging right away and hit a brick wall. I searched the web for possible reasons of IAPs not working and found lots of checklists (see here, here, here and here) and one superb tutorial. One tip was the golden one. “Just wait”. After 20 hours some magic happened on Apple’s servers and everything works like a charm again.

A simple warning “This action renders your IAPs unusable for 12-24 hours” would suffice to let people know about this. Apple is so brilliant when it comes to guiding users and letting them know about important stuff, but sometimes it seems like they do not really care about their developers (does anyone else play the game “Guess in which corner the action button appears in iTunes Connect”).

It seemed like an odd choice for me to read because I am not a designer. I am a programmer and I wouldn’t be able to produce something beautiful if my life depended on it. Before reading this book, thats what I thought design is all about, beauty. Now I know that there are more aspects to design and the book also helped me to think more abstractly and (try to) derive interaction patterns from hardware devices and translate them to well designed user interfaces.

If you are interested in design – be it industrial, software or any other kind of design – you probably already read it. If not, you should probably read it.

In his book Norman takes a close look at how user interfaces are designed and tries to scientifically explain why some designs are superior to others or why one solution is prone to mistakes by the user. The examples he chose to illustrate his ideas are mostly hardware examples. I should probably mention that the book was first published in 1988, so the kind of user interfaces we are used to did not yet exist.

Doors are one of his pet peeves. The book is full of examples of poorly designed doors or just plain crazy doors. But he also mentions a few good examples. Especially automobile manufacturers have quite a good track record designing doors. Admittedly, they do have the advantage that doors on cars always open to the outside. Norman sums it up quite nicely:

“Somehow, when a device as simple as a door has to come with an instruction manual – even a one-word manual – then it is a failure, poorly designed” (p. 87)

Obviously Norman goes into much more detail than I am. His book is a lot more scientific than what I am writing here – and doors are not the only examples Norman has to offer. Just a few that stuck in my head are telephones, light switches, motorcycle turn signals, faucets, even the NES instruction manual is featured in his book.

Gulf of execution vs. Gulf of Evaluation

Norman describes the world and the way we interact with it in seven stages of action. We observe the world, evaluate the current state it is in and form a picture of the state we would like it to be in – a goal. From this goal we infer a sequence of actions which we think will manipulate the world in a way that it changes its current state to the desired state. After executing these sequence of actions we observes the world again and evaluate whether the current state it is in, is the state we want it to be.

How translates this to design? Good design is supposed to provide actions that correspond to the users intentions. Norman calls the difference between the allowable actions and the users intentions the gulf of execution.

Good design is also supposed to provide directly perceivable physical representation which can be translated into a users intententions. This is what Norman calls the gulf of evaluation.

So how does a designer go about bridging these two gulfs? There is no perfect solution for this, but Norman provides a couple of pretty good pointers, or better questions you should ask yourself about your design. I will only share two of those questions, because I don’t want to kill his book sales completely

Visibility – Does the design provide a visual clue in which state the device is currently in and what actions are available to the users?
Feedback – Does the user receive continuous feedback about the results of his actions?

Natural mappings

Natural mappings take advantage of physical analogies and cultural standards for immediate understanding.

“If a design depends upon labels, it may be faulty. Labels are important and often necessary, but the appropriate use of natural mappings can minimize the need for them. Whenever labels seem necessary, consider another design.” (p. 78)

Norman illustrates natural mappings with different layouts of stoves and their controls. Since I don’t want to rip off his book I took a look around and found a simple example.

My desk drawers seem like an example of good design. They are lockable and the orientation of the keyhole takes advantage of natural mappings to form a mental model in the users head.

Unlocked, the keyhole is parallel to the drawers, which signals “I am unlocked – Open me”. When it is locked, it is orthogonal to the drawers which signals “I am locked – Better luck next time”. Even without trying to open the drawers it is obvious that they are (un)locked.

Admittedly, this is a pretty basic example, but think about what would have happened if the orientation of the keyhole were the other way around? What kind of mental model would support instantly knowing what state the lock is in? I can’t think of one and that’s why I think it is good design.

Norman and the future

Interestingly enough Norman is predicting the future quite accurately on multiple occasions. At one point in his book he as writing about something that sounds a lot like the iPad to me. But make up your own mind…

The computer of the future is perhaps best illustrated by my imaginary perfect calendar. [...] This imaginary calendar looks like a calendar. It’s about the size of a standard pad of paper, it opens up to display dates. But it really is a computer, so it can do things that today’s appointment calendar cannot. [...] Most important, it can also connect itself to my other systems. Thus, whatever I enter into the calendar gets transmitted to my office and home systems so that they are always in synchrony. (p. 185&186)

Other times he is a bit off in a funny way (when you look at it from todays modern point of view). Discussing to problems of self-threading projectors his final remark is: “Well in a while it won’t matter. There won’t be any film, just videotape”. Not quite…

Ridiculing Norman is not my intention. It just stood out to me. Norman doesn’t try to predict the future. He is merely looking at the mistakes of the past and describing how design can be better in the future – or rather how future designers can be better.

Final thoughts

To sum it all up, the book was a revelation for me. I will never be able to see something as simple as a door for what it is, a plain door. I will always see the designers intentions (and possibly his mistakes). Somehow a lot of things make more sense to me now that I look at things differently.

If this book had not taught me anything else but to take a closer look at things, it would still have been a pretty good investment in my personal and professional development. After reading it I started noticing things I never noticed before – small things that is. But luckily for me the book gave me more than this. A whole new perspective and things to think about. A truly good read.

This is what the button looks like in code. Nothing special so far. Okay, I did not simply create and assign the background images… I made them resizable by using the UIImage method stretchableImageWithLeftCapWidth:topCapHeight: (from iOS5 on you would use the resizableImageWithCapInsets:).

UIButton *playButton = [UIButton buttonWithType:UIButtonTypeCustom];
playButton.frame = CGRectMake(0, 0, 160, 40);
[playButton setTitle:@"Play" forState:UIControlStateNormal];

// Set the state images
[playButton setBackgroundImage:[[UIImage imageNamed:@"resizableButtonNormal.png"] stretchableImageWithLeftCapWidth:10 topCapHeight:0] forState:UIControlStateNormal];
[playButton setBackgroundImage:[[UIImage imageNamed:@"resizableButtonHighlighted.png"] stretchableImageWithLeftCapWidth:10 topCapHeight:0] forState:UIControlStateHighlighted];

[yourView addSubview:playButton];

One thing did not look right… I didn’t like the fact that the Textlabel stayed in the same place for both states. That kind of killed the illusion of a ‘real’ pushbutton for me. So I dug in the documentation but couldn’t really find any useful information. OK, that’s a lie – The Apple Documentation is really helpful and always up to date! …but I digress. I did not find any information on setting the frame of the titleLabel depending on the state of the button.

I did not want to subclass UIButton just to move the frame of the textLabel around it the highlighted state, so I experimented a little and here is the solution I came up with (I can only assume that trick has been around for quite some time, but I never read about it anywhere else):

playButton.titleLabel.shadowOffset = CGSizeMake(-1, -1);

[playButton setTitleColor:[UIColor whiteColor] forState:UIControlStateNormal];
[playButton setTitleShadowColor:[UIColor clearColor] forState:UIControlStateNormal];

[playButton setTitleColor:[UIColor clearColor] forState:UIControlStateHighlighted];
[playButton setTitleShadowColor:[UIColor whiteColor] forState:UIControlStateHighlighted];

Notice how I alternate between shadowColor and textColor? That is basically the whole trick. In the normal state you can only see the text itself and the shadow is transparent. In the highlighted state the shadowColor is white and the textColor is transparent. I like it the best with shadowOffset = CGSizeMake(-1,-1), but it also looks good with shadowOffset = CGSizeMake(0, -1).

So, this is what you get in the end.

Downside

• Well as you might have already thought while reading this, if you use this technique to give your UIButtons depth, your text can’t have a shadow (because it already has/is a shadow). For me this is not really a problem because the shadow would be used to give the text depth – to make it look like it is not on the button, but above it which would not fit with the whole idea of this button.
• One could call the buttons ugly… I like ‘retro’ a bit better