This is a guide to using XSLT to extract default values from your iPhone app’s Settings bundle into a separate property list file. That file can be loaded by your app at runtime, sparing you the need to maintain the same data in two places and avoiding the risk of a mismatch leading to buggy behavior.
Archive for the ‘iPhone’ Category
Avoid defining your iPhone app’s default values in two places
Tuesday, October 6th, 2009App Store Reviewer Incentives
Saturday, August 8th, 2009I think Daniel Jalkut has it backwards:
Many of the mercenary testers I encountered were motivated to scrape the system for bugs, as ridiculous as they may be. They logged them into the bug system and then defended them at all costs, as if their lives depended on it. And it turned out, they did. At least, their paychecks did.
I would not be surprised to learn that App Store reviewers are working under a similar structure. A system that rewards “unique, valid rejections” would certainly explain the behavior we have seen coming to light in the past year.
QA teams, like the ones Daniel writes about, reward “unique, valid bug reports” because all the testers are testing the same piece of software. If a group of testers repeatedly file duplicate bug reports, clearly you have an inefficient team, and can afford to let some of them go. The team has an incentive to reward unique reports.
The App Store review team, on the other hand, has one reviewer per app, and each app is different. Even if the team was perversely trying to justify its existence by beefing up its rejection numbers, there would be no need to come up with “unique, valid rejections.” In that case it would be more efficient for them to reject apps with increasingly vague reasons, or no reason at all.
It is more likely that reviewers are severely punished (i.e., fired) for approving an app that later causes a problem. That’s the kind of situation that leads to overzealous reviewers without assuming that management is dumb.
And there are problems: all the writing on the Ninjawords rejection pits Apple against enlightened liberal people. Not pictured are the parents who have purchased an iPod touch for their young child and want to let them download games from the App Store, but maybe don’t want to let them downloading Motorboat, which is not actually about boats, but involves rubbing your nose on the touchscreen.
When Apple added ratings to the App Store, it did not do so in a vacuum. It has quite a few customers with children, who I suspect express themselves by making phone calls instead of posting on blogs. So while we’ve read a lot about the helpless developers who are being persecuted by puritannical Apple, we haven’t read the testimony of parents who are trying to give their child a little bit of freedom without having to worry that they will get the idea that sticking your nose in a woman’s cleavage is an acceptable thing to talk about during Thanksgiving dinner.
FatWatch 1.4.1
Wednesday, June 24th, 2009I intended FatWatch 1.4.1 to be a minor update, primarily to fix a display issue that appears on iPhone OS 3.0. If you’ve upgraded, you may have noticed that when you switch between Variance and BMI in the Log view, the table rows no longer update immediately; you must scroll to force them to redraw.
I submitted an update to Apple, changing as little else as possible, hoping that it would get through their review process in time for the public release of 3.0. Unfortunately, it was rejected for violating the iPhone Human Interface Guidelines. That’s right: I was nailed for something that they previously approved.
What I got away with
I could bitch about it, but they were right: the objection was to the Wi-Fi Import/Export feature, which in FatWatch 1.4 was enabled by a simple switch.
If you want to import or export a CSV file containing your weight history, all you had to do was turn that switch, and a new row would appear beneath it with an IP address to connect to.
If you didn’t know what to do with all those geeky numbers and slashes, hopefully you would tap on it, because doing so would display an alert explaining that you are supposed to enter that into the address bar of a web browser on your computer.
Even when working properly, this is a spartan interface. I’d honestly be surprised if anybody who doesn’t describe themselves as a “geek” figured it out. What’s worse (and this is where I got into trouble with Apple) is when you turn on Wi-Fi Import/Export and you’re not even connected to a Wi-Fi network. You get a blank row.
So yes, I could say to Apple, but that’s how it worked all along! But that’s like telling the police officer you shouldn’t get a ticket because you run this red light every day and nobody gave you a ticket before.
Making things right
Initially, I tried to fix things by detecting whether a Wi-Fi connection was available and, if not, snapping the switch back to the OFF position and displaying an alert with an error message. While that would have been an improvement, it still felt… terrible.
After sleeping on it (always more productive than hammering away all night, will I ever learn?) I realized that Wi-Fi Import/Export really deserves its own screen, rather than the series of alert views I had allocated it. In practice, you aren’t going to use your iPhone or iPod touch for anything else while you are importing or exporting a file, so there’s no need for it to operate in the “background” of the app.
So in FatWatch 1.4.1, the Wi-Fi Import/Export changes from a switch to a menu item.
When you tap it, you see a screen that explains what Wi-Fi Import/Export does and how to use it. It also tells you that you can use Bonjour, instead of typing in a series of dots and colons and numbers. FatWatch always used Bonjour, but there wasn’t enough space in the old interface to explain it.
FatWatch will now remember the last time you imported or exported a file; very useful if you want to export a file as a backup every so often and you can’t remember when you did it last.
But, most importantly, if you are not connected to a Wi-Fi network, FatWatch now makes it abundantly clear.
As a bonus, now that I have a whole screen for this feature, I was able to get rid of the alerts and do some nice things, like display a progress bar so that you know things are working when you’re importing a large file.
I won’t claim it’s perfect: even now I want to edit some of the text in those screenshots. I held myself to a fairly tight schedule because I didn’t want people to be waiting too long for the bug fixes that was supposed to be the primary focus of this release. However, I am glad Apple challenged me to improve this feature, because it has gone from an embarrassment to something I can feel mildly proud of.
More
A few other improvements that are coming in 1.4.1:
- The Wi-Fi Import/Export web pages are easier on the eyes.
- FatWatch puts today’s date in the exported file name, for example: weight-2009-06-29.csv. Useful if you let those files accumulate in your downloads folder.
- The Go To Date screen displays its buttons in a navigation bar; looks a lot nicer.
- Fixed a bug where BMI values were calculated incorrectly. Basically, if you select your height in feet and inches, FatWatch always added an extra centimeter to your height. That has been fixed.
Everybody cross your fingers, and hopefully it will appear on iTunes soon!
