Question

I have a weird problem with a bugfix for Tiny Wings. In my game i use something like:

NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];      
[userDefaults setFloat:musicVolume forKey:@"musicVolume"];

for saving some preferences and the highscore table. At the end of the game when the gameover screen appears the game saves the highscores to the standardUserDefaults. It works very well until the game displayed an UIAlertView like this:

UIAlertView *alert = [[UIAlertView alloc] init];
[alert setTitle:@"Get ready!"];
[alert setDelegate:self];
[alert addButtonWithTitle:@"Ok"];
[alert show];
[alert release];

After the AlertView disappeared everytime the game save somthing to the standardUserDefaults the game lags for a while (on some devices for several seconds). This also happens after the game used an UITextField for inputting the player name. There is not any lag in the game before one of the two UIKit Elements are used but after the use of them the game lags until i restart the app. I have analysed the problem with the Performance Tools and the “I/O Activity” Instrument shows that there are hundreds of “open – read – close” accesses to the

/System/Library/Frameworks/UIKit.framework/InputModeProperties.plist

which causes the lags.

I totaly have no clue what to do. Any ideas?

Edit:
there is a thread in the apple developer forum http://devforums.apple.com/message/424374#424374 where somebody has an equal problem and it seems that it only appears with iOS 4.3. I have tested it and the lags only happens on my 4.3 devices (not on a 3.1 iPod Touch and 4.2 iPad).

Answer 1

EDIT

A decent bug workaround :

Short version: Just delay the bug-triggering calls until user is not annoyed.

Long version:

Since I think the issue is coming from [NSUserDefaults standardUserDefaults] call, that triggers that dirty plist-loading loop AFTER some action requesting Keyboard layouts (like an UIAlert)…

I would suggest to call [NSUserDefaults standardUserDefaults] just one time at app loading (BEFORE any bug-causing call), and keep the returned reference in a singleton class during all app lifecycle. I don’t think the memory footprint would be huge… (I’m doing this in several apps w/o any issues). At worse the plist load*100 would be done only once at app load, and not during game.

If the issue comes from [userDefaults setXxxx:...] calls, same workaround, you could just keep values to save in memory and set them later in userDefaults, like just before syncing them… But at the risk of losing informations if anything goes wrong, like a crash. I personally prefer to sync after each set to ensure data integrity…

ENDOFEDIT

---

The short answer : iOS4.3 bug, very few chances to find a workaround… bugreport and wait for next iOS update… WWDC in 2 weeks… 1~2 month.

The long one:

After looking at UIKit asssembly, here are my guesses:

• InputModeProperties.plist contains a list of all keyboards layouts by locale.
• UIKit use this for several things, like when showing a keyboard, to determine available keyboards layouts. (Locales…)

• One thing is interesting, we can find some of its informations in NSUserDefaults :

  NSLog(@"%@", [[NSUserDefaults standardUserDefaults] dictionaryRepresentation]);
  ==> {
  AppleKeyboards =     (          // I have two keyboard in preferences
     "fr_FR@hw=French;sw=AZERTY", // french  first
     "en_US@hw=US;sw=QWERTY"      // english second
  );
  ...
  

• But these informations are not stored in apps preferences, unlike your score. (NSGlobalDomain, or more likely Separate domains for each of the user’s preferred languages)
• So I would not be surprised a conflict (bug) exists in UIKit + NSUserDefaults causing that dirty plist loading loop.
• Around 100 call you say? That’s something like the number of locale/layouts in the plist!

When no keyboard is available in NSUserDefaults… (Like after synchronizing, let’s imagine a bug doing this)… UIKit could try all available keyboards to determine user one, dirtily parsing this 4.4K plist hundred times… Like when showing an UIAlertView… after a NSUSerDefault sync/change.

Who knows? The Apple folks who has the source code 🙂

I would not be surprised going to preferences to set a keyboard other than default US then reverting to US would solve the issue. Useless in your case, but would confirm the issue. Seen that for another 4.3 bug…

As other people said, not using NSUserDefaults but a simple custom plist in /Documents could be a (in)decent workaround.

Great work on Tiny Wings! 🙂