MultiNC develops iPhone applications for a number of global markets, and sometimes we run into bugs unique to globalized applications.  One application that we’re developing has France as primary market.  U.S. users very rarely change their settings from the usual 12-hour mode (AM/PM mode) to 24-hour mode.  However, in France it’s not rare for users to switch from the more common 24-hour mode to 12-hour mode.  And that’s when things start acting strange, even causing your application to crash.

Because of users’ regional habits, developers of globalized applications are more likely to encounter this time bug than for US applications.

Region format & 24-hour mode setting

First, a little background on the iPhone user interface.  When iPhone users change their region format between, say, “United States” and “France”, the users’ “24-Hour Time” setting is automatically switched to the mode that is most prevalent in that region.  In France, that would set 24-Hour Time to “ON”, and in the U.S., that would set it to “OFF”.  The users can then manually override that setting and that’s where trouble starts.

NSDateFormatter bug

The pattern of this SDK bug was relatively tricky to determine because of the specific combination and sequence of user settings that would trigger it, but now it’s actually quite simple to explain.

The problem comes from NSDateFormatter somehow “getting stuck” in the 12 or 24-hour time mode that the user has manually selected.  So if a French user manually selects 12-hour mode,  and the application requested NSDateFormatter to output time with the 24-hour format “HHmm”, it would actually receive time in a 12-hour format, e.g. “01:00 PM”, as if the application had instead requested “hhmm aa”.  The reverse would happen if a US user manually selected 24-hour mode: outputting time with the 12-hour  format “hhmm aa” would actually get you time in the 24-hour format instead, e.g. “17:00″.

This bug turns especially nasty when your application is trying to parse time from a string, rather than outputing.  Similar to the above, the NSDateFormatter seems to be stuck in the time mode that the user has manually chosen and insists on reading time that way, regardless of the string format.  What you can end up with is an incomplete or invalid NSDate, which when later used can cause other parts of the application to crash, as the UIDatePicker did for us.

We are developing with the iPhone SDK version 3.1 beta, but we wouldn’t be surprised if it applied to all previous SDKs.

Workaround

Now that you know the source of the bug, a workaround is straightforward.  But to save you time until Apple fixes it, with our client faberNovel’s gracious permission, here’s our workaround when dealing in 24-hour time (dealing in 12-hour time would be very similar):

// Returns time string in 24-hour mode from the given NSDate
+(NSString *)time24FromDate:(NSDate *)date withTimeZone:(NSTimeZone *)timeZone
{
	NSDateFormatter *dateFormatter= [[NSDateFormatter alloc] init];
	[dateFormatter setDateFormat:@"HH:mm"];
	[dateFormatter setTimeZone:timeZone];
	NSString* time = [dateFormatter stringFromDate:date];
	[dateFormatter release];
 
	if (time.length > 5) {
		NSRange range;
		range.location = 3;
		range.length = 2;
		int hour = [[time substringToIndex:2] intValue];
		NSString *minute = [time substringWithRange:range];
		range = [time rangeOfString:@"AM"];
		if (range.length==0)
			hour += 12;
		time = [NSString stringWithFormat:@"%02d:%@", hour, minute];
	}
 
	return time;
}
 
// Returns a proper NSDate given a time string in 24-hour mode
+(NSDate *)dateFromTime24:(NSString *)time24String withTimeZone:(NSTimeZone *)timeZone
{
	int hour = [[time24String substringToIndex:2] intValue];
	int minute = [[time24String substringFromIndex:3] intValue];
	NSDateFormatter *dateFormatter= [[NSDateFormatter alloc] init];
	[dateFormatter setTimeZone:timeZone];
 
	NSDate *result;
	if ([Util userSetTwelveHourMode]) {
		[dateFormatter setDateFormat:@"hh:mm aa"];
		if (hour > 12) {
			result = [dateFormatter dateFromString:[NSString stringWithFormat:@"%02d:%02d PM", hour - 12, minute]];
		} else {
			result = [dateFormatter dateFromString:[NSString stringWithFormat:@"%02d:%02d AM", hour, minute]];
		}
	} else {
		[dateFormatter setDateFormat:@"HH:mm"];
		result = [dateFormatter dateFromString:[NSString stringWithFormat:@"%02d:%02d", hour, minute]];
	}
	[dateFormatter release];
 
	return result;
}
 
// Tests whether the user has set the 12-hour or 24-hour mode in their settings.
+(BOOL)userSetTwelveHourMode
{
	NSDateFormatter *testFormatter = [[NSDateFormatter alloc] init];
	[testFormatter setTimeStyle:NSDateFormatterShortStyle];
	NSString *testTime = [testFormatter stringFromDate:[NSDate date]];
	[testFormatter release];
	return [testTime hasSuffix:@"M"] || [testTime hasSuffix:@"m"];
}
 
// Converts a 24-hour time string to 12-hour time string
+(NSString *)time12FromTime24:(NSString *)time24String
{
	NSDateFormatter *testFormatter = [[NSDateFormatter alloc] init];
	int hour = [[time24String substringToIndex:2] intValue];
	int minute = [[time24String substringFromIndex:3] intValue];
 
	NSString *result = [NSString stringWithFormat:@"%02d:%02d %@", hour % 12, minute, hour > 12 ? [testFormatter PMSymbol] : [testFormatter AMSymbol]];
	[testFormatter release];
	return result;
}

References:

• StackOverflow – NSDateFormatter, am I doing something wrong or is this a bug?

• You can open-source your app.  Specifically, you provide to your users the source code of your entire application under the LGPL or GPL.  That means for example all the .h and .m files.
• You can keep your app closed-source, but you provide to your users all the object code of your  application necessary to re-link your application.  That means for example all the .o and .a files.  Most people forget that this option is in fact available to iPhone app developers.

Dynamic/Shared Library

Static Library Exception

Spirit of the LGPL

• Jailbreak their iPhone to install any binary that they want
• Join the iPhone Developer Program for $99 a year to be able to legally distribute "Ad Hoc" the new app to up to 100 devices.

References:

• GNU Lesser General Public License, particularly section 4.d)
• StackOverflow - Which open source licenses are compatible with the iPhone and App Store?
• Nabble - iphone, and releasing object code satisfies LGPL Re: Static building and bundling of SDL.
• Nabble - iPhone SDK <-> SDL License

Before this will work, you may have to ensure the following:

In Windows, the “Apple Mobile Device” service must be running
You should enter the Passcode on your iPhone or iPod Touch
The device must be jailbroken if you want to see anything outside the Media folder, e.g. if you want to see the root folder.

So I needed to update to the latest firmware 1.5, a.k.a. “Cupcake”.

The official instructions are at HTC Support but they were nicely summarized by some dude.  I’ve included his instructions with my changes in red (I didn’t get the minor problem he ran into):

1. From the HTC support page, download radio image ota-radio-2_22_19_26I.zip and recovery image signed-dream_devphone-ota-147201.zip
2. make sure HTC Gphone is connected to your computer, and `adb devices` see your phone listed
3. adb push ota-radio-2_22_19_26I.zip /sdcard/update.zip
4. adb shell sync
5. shut down your GPhone. When preparing to restart, please press and hold “Home” then hit the Start (should be the same power off button aka the “Call End” button) button, waiting for the “!” icon to appear.
6. Press ALT + l (this is a lowercase L, not a capital i or number 1) to display the console output
7. Press ALT + s  to install the update
8. Press HOME + BACK and write the install, and there will follow an automatic reboot
9. adb push signed-dream_devphone-ota-147201.zip /sdcard/update.zip
10. repeat 4 – 8

That worked pretty well, but it didn’t solve the syncing problem I’ve been having (my contacts having not been syncing to Google since I first got the phone.

Note that several applications have problems when upgrading from 1.0 to 1.5 and need to be updated, including ChompSMS, Power Manager, Toggle Settings, Task Manager for Root Users, System Monitor.

The new OS runs snappier, supports video recording mode and a on-screen soft keyboard, lists applications under Manage Applications much quicker.

Key takeaways from the Google Tech Talk video were:

• Insourcing → Outsourcing → Crowdsourcing →  Testsourcing
  • Some companies are already doing crowdsourcing of testing:
    • utest.com pays the internet community to find bugs in software. (Companies who want their products tested credit their account with at least $2000, with which they pay for discovered bugs that they aprove.)
  • The speaker believes that in the next phase of evolution, we’ll have “testsourcing” where vendors are providing tests themselves.
• Virtualization:
  • Virtual machines and their environments are going to be key for wrapping up and reproducing bugs as they happen.  They should run not only on testers’ machines but also users’ machines.
  • Market of the future: virtual test machines
    
• Visualization:
  • Microsoft testers use a tool to visualize their codebase (see image below) and focus their testing
    • 
    • Size denotes lines of code
    • Darkness denotes complexity [can't hear what he mumbles there]
    • I wish I knew what this tool was
  • Game testers use numerous GUI tools:
    • displays where they are in the application itself (in addition to the usual game screen) as they play the game
    • displays surrounding testable objects and allows them to teleport to them
    • displays objects that need to be tested because the code has changed
    • displays the degree of testing that has been done for each object

XMLVM

Other languages for the XMLVM

Enhancing the iPhone emulator with hardware data

Better to Develop in Objective-C

• Limited functionality
• Lower performance
• More complicated development process
• More source of bugs in your way (from not just the iPhone OS and SDK, but from the language adapter)
• Smaller community of developers, fewer development tools, less documentation