Seeking Serendipity

Here are a some of bugs/things I found after the application had been released to adhoc (beta) users. All good reasons to spend as much time in this phase as possible/neccessary:

1) I failed to ‘retain’ a property that happened to be the one locating the website. It seemed to work at start-up but (for many people, any people who had not gone into Settings to make edits which somehow made a difference) it did not after that. In short, the application failed to connect back to http://wildobs.com. Big bad bug.

2) My ‘pretty’ (ok pretty w/o quotes, they are nice nature shots) splash screen was a copy of my about page; aspens with some text over it. I knew what it said, and it looked fine to me. To new users, they couldn’t read the text in time and were left confused.

3) I believed that code in applicationDidFinishLaunching: would be called before viewDidLoad: on any views. *wrong*. Views loaded from the MainWindow.xib (and for a tab layout that can be a few) get loaded simultaneously (perhaps even before.) I started getting reports of random crashes in initialization code. I ended up moving all my initialization code (properties, databases, application-wide data) into a singleton (see Apple site for instructions on how to create one of these) to protect this. Cost me a few hours of re-work and global search/replace but now I know it I’ll design future apps this way.

4) viewWillAppear: does not get called on views loaded from NIB directly into view; i.e. it only get called when another view goes away to reveal this. Important ‘cos I’d tried to fix (3) with some of this, hoping viewWillAppear: would happen after applicationDidFinishLaunching:.

5) I was using <BACK navigations as a “cancel” when they are truly just a “back”. I removed buttons (like ’save’ and ‘done’) simplifying and making more correct against  the HIG, no doubt. Less is more.

6) If you don’t retain the CLLocationManager (keep a reference in your own code, e.g. as application data) you’ll probably not get updates from it. Doh, kinda obvious but it happened. Testing on an iPod Touch (long story), and using the simulator, really doesn’t help navigate the complexities of receiving location information. Sure, they code is there, but you need the stream of data. [For example, I never expected to have to ask the location manager to stop trying after it reported failure to get a location. A never ending supply of pop-ups was not what I had hoped to present to the user.]

7) Numerous small bugs based on my account/test data being more well troden than others, and sometime environmental (divice) differences. Other users had empty WildObs lists, or fewer lists, or any number of different sets of data. Those differences caused different code path.

8] My initial release would not even install due to issues documented here: http://neukadye.com/blog/2009/02/19/installing-adhoc-beta-iphone-applications-via-itunes-on-microsoft-windows/

9) Data stored in an sqlite3 database was getting corrupted (cross-wired.) I learned to use sqlite3_clear_bindings as well as sqlite3_reset on statements I planned to re-use. See this: http://www.sqlite.org/c3ref/clear_bindings.html.

10) Much as the installation/start-up experience is increasingly minuscule over the lifetime of an application, it is critical for that first impression. For an application like WildObsObserver (that needs an account, then downloads data and images before it can be used) there is a lot going on at this installation time. Simplify, simplify, simplify. Spend as much time here as you can…

Not only did the adhoc testing uncover bugs and issues, but it *far more importantly* it revealed how others saw the application I’d built. Seemingly small issues that I’d grown oblivious to could be big issues to new users. Things I was sure were obvious to users, were not.

I cannot thank the users enough for how they progressed this application.