In the Apple Developer Library, it explicitly states that for MacOS applications take both the Language and Regional preferences of the user into account, but only look at the preferred language on iOS – Support for Internationalization. This means that a single variant per language is supported.

However, these is a way around this. I’m not sure if this is a good thing to do, but it works for me and I haven’t noticed any ill side effects yet.

To support both US English and British English in your iOS application, create 2x Localization.strings files just as you would for multiple language. Put the US English translation file Localization.strings in a directory in your iPhone app called English.lproj (Apple defaults) and the British English translation in a directory named en_GB.lproj (just in case they decide to support regions in the future).

Then, you’ll need to create some code to manually set the preferred localization. In your main.m file (yup, main.m is being edited) alter it so it performs some logic similar to below.

int main(int argc, char *argv[]) {
	NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
	NSString *language = [[NSLocale preferredLanguages] objectAtIndex:0];
	NSString *locale = [[NSLocale currentLocale] objectForKey: NSLocaleCountryCode];
	if ([language isEqualToString:@"en"] && [locale isEqualToString:@"GB"]) {
		[[NSUserDefaults standardUserDefaults] setObject:[NSArray arrayWithObjects:@"en_GB", @"en", nil] forKey:@"AppleLanguages"];
	}
	int retVal = UIApplicationMain(argc, argv, nil, nil);
	[pool release];
	return retVal;
}

When the line

int retVal = UIApplicationMain(argc, argv, nil, nil);

gets executed, it seems to set up all the Localization bundles before calling the application:didFinishLaunchingWithOptions method on your app delegate, so putting Localization code in the app delegate is too late. So, what the code above does is retrieve the users current language and region, and compares those against pre-determined values – en for the language and gb for the region. If these match, then I force a new setting in the NSUserDefaults to overwrite the users preferred language. Then, when the UIApplicationManager function gets called, it appears to retrieve the users preferred language setting, and look up the Localization for that – which in my case I’ve forced to be en_GB.

One thing you need to be careful about is persistence of this NSUserDefault setting. It is saved once it’s set, and persists through multiple application executions. To get around this (lets say the user changes their region back to US), you need to remove the setting after the bundle initialization has taken place. In you app delegates application:didFinishLaunchingWithOptions method, just execute the following code.

[[NSUserDefaults standardUserDefaults] removeObjectForKey:@"AppleLanguages"];

This wipes out the NSUserDefault setting that the app made in the main.m file.

If anyone knows of issues with this approach (apart from being a dirty hack), or faults with my code please let me know in the comments below. I wish Apple supported different regions per language natively in iOS but they don’t. This is the only way I’ve found to do this, and continue to use localization functions such as NSLocalizedString.

How frickin’ exciting!

- (NSInteger)age:(NSDate *)dateOfBirth {
  NSCalendar *calendar = [NSCalendar currentCalendar];
  unsigned unitFlags = NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit;
  NSDateComponents *dateComponentsNow = [calendar components:unitFlags fromDate:[NSDate date]];
  NSDateComponents *dateComponentsBirth = [calendar components:unitFlags fromDate:dateOfBirth];

  if (([dateComponentsNow month] < [dateComponentsBirth month]) ||
      (([dateComponentsNow month] == [dateComponentsBirth month]) && ([dateComponentsNow day] < [dateComponentsBirth day]))) {
    return [dateComponentsNow year] - [dateComponentsBirth year] - 1;
  } else {
    return [dateComponentsNow year] - [dateComponentsBirth year];
  }
}

ARGeoViewController as the overlay on a ImagePickerController on iPhone

I want to tidy up some of the code before I check it back into my clone of the source, but this is a really good basis for some smart location and direction aware augmented reality apps on iPhone.  Wonder what the iphonearkit license is – it’s unclear…

— EDIT —

Bugger.  It appears that zac has implemented similar functionality to me already  Bloody github and it’s slow (never!) updates to fork queues and network graphs.  Oh well, maybe I won’t bother tidying my code.

My 4th iPhone application was approved yesterday by Apple, and it launches in the iTunes store today. It’s called Kit Quiz: UK and is a UK team based football (soccer) shirt quiz game. It features over 130 shirts from UK football teams, and will have more added shortly.  There are 3 modes of gameplay, from the practise model “Friendly” to a time challenge “Blitz”.

It’s integrated with Twitter and Facebook so you can check out your friends scores and find out once and for all who can recognise the most football shirts.

Couple of screenshots below for anyone interested.  Download it now!

Kit Quiz: UK menu screen

Kit Quiz: UK - Blitz screen

</shameless self promotion>

The codes can do boring things like retrieve your divert status from the network, return your IMEI or perhaps ICCID, but they can also interact with specialised applications driven via USSD Gateways to return useful information and execute transactions. These are applications that are sent specific codes by an operators core network, perform some processing on the data received, and return a response. Things that are non-standard that are enabled by USSD Gateways are services such as USSD-based prepay balance retrieval, USSD-topup, or interactions with NGIN features to alter a network based service.

I looked into USSD codes on the iPhone a while back, not to be used by users typing them in, but more to be used by applications querying information from the network via them. The reason why I wanted to programatically access them? To look at what’s possible for network operators or enterprises to release as iPhone based network service management applications.

Sadly, Apple have disable the use of USSD codes from within the (legitimate) iPhone sandbox available to developers (via the open URL methods, passing in a tel://xxxxxx URL). This means that there won’t be any applications from your operators that will make it easy to retrieve and change network settings that can be released thru the app store – at least not until Apple change their mind about interactions with USSD codes. Which is a pity – there are lots of useful services that would be useful to expose simple interfaces for usage for to the operators end users. USSD is an efficient, fast way to configure the network, using capabilities that most operators already have.

You can configure your keywords with the “Edit Information” link against the application. SendIt4.me (iTMS) has already been updated

Be careful though. It appears you can only update your keywords ONCE per application update – so make sure you choose the right ones the first time around – otherwise you’ll have to go through the painful approvals process to get it corrected.

The keywords should help with searching for your application within the store. Fingers crossed.

— EDIT —

You can also only have up to 100 characters for the keywords. Don’t get caught out! If you submit with more than 100, it tells you too late – you’ll have to resubmit your app to fix it.

Download now!

Sidenote: I submitted this application initially to Apple on the 18th Jan 2009. It was finally approved tonight. There was only 1 “Please wait” mail, and one “We need some help testing it” mail – too long in my opinion.

I did hit a strange error though.  On the simulator the touch events were working correctly – screens transitioning, sprite/label touches generating events and triggering animation and so on.  On the actual device the story was quite different.  My menu items were triggering correctly, but no subsequent touch events were doing anything on the phone.  When the application exited (home button) all the touch events were then passed through as I could see them all fly up the screen in the console.

A long search in google yielded the following page:  http://groups.google.com/group/cocos2d-iphone-discuss/browse_thread/thread/8aae440d81721ff4

I don’t know what causes the actual issue, but the fix is to alter the Director.m’s main method – adding the following code fixed the issue right up.

while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0, YES) ==  kCFRunLoopRunHandledSource) {}; 

The odd thing is (and let me know if I’m wrong here) that that code doesn’t actually do anything.  It performs a test, but changes nothing.  I don’t get why this fix works.

?

error while killing target (killing anyway): warning: error on line 1987 of “/SourceCache/gdb/gdb-962/src/gdb/macosx/macosx-nat-inferior.c” in function “macosx_kill_inferior_safe”: (os/kern) failure (0x5x)

I figured out that it had to do with definition of a selector… Naughty code below.

MenuItem *start = [MenuItemFont itemFromString:@"Start Game"
                                        target:self
                                      selector:@selector(startGame)];

The problem is that the method name inside @selector() MUST have a colon on the back of it.

Good code

MenuItem *start = [MenuItemFont itemFromString:@"Start Game"
                                        target:self
                                      selector:@selector(startGame:)];

Hope that’s useful to someone.