Late CodeSigning

Just for fun, I decided last night after 9:30PM to install the latest WIP of our iPhone app on my wife's 2G iPod touch. In order to that, I first tried to modify the provisioning profile so to include the new device in it, but that didn't work too well. Even after having removed completely (or so I though) the said profile from her device and mine (and from the IDE's organizer) and created a new one (following the how-to instructions from the SDK developer portal), I could still not recompile the application. The error reported (in red, mind you) by Xcode being:

CodeSign error: a valid provisioning profile is required for product type 'Application' in SDK 'Device - iPhone OS 2.2'

By then, since it was well after 10pm, way past the baby bed time (and ours ...) , I had to close shop for the night. Problem is that closing the lid of the laptop doesn't mean one's mind isn't going to keep thinking about the problem ... well into the wee hours of the night. Hopefully, when I woke-up this morning (I'm gonna need a nap this afternoon!), I had an idea: Maybe, somewhere inside the project files, references to the old profile were still present? This turned out to be a correct theory (!), for when I grep-ed the project.pbxproj file for PROVISIONING_PROFILE, I found some references to the old profile. A simple copy&paste (BTW I use Smultron for such text editing tasks) of the profile identifier fixed the issue and shortly after, Susan's iPod was running our app :-)

2Busy2Blog!

Since I'm now half-way trough my parental leave, it is time to review a bit what I have been up to, which is mostly coding and parenting ... but mainly the latter. Nevertheless, our iPhone app is getting closer and closer to be ready. I swapped successfully the old data management stuff for the soup thing I was talking about in my previous post, and so far it's working pretty well. I also, followed the advice of Tweetie's author (Loren Brichter) and replaced the five UITextView objects I was using in my UITableView cell by a single UIView (drawing by hand the content). The speed-up is great, there is no longer that impression of lag when flicking up or down, it is amazingly cunning :-)

There is two videos (youtube) I'd like to share with you today. The first one is from a concert of Terje Isungset, who use ice to make (somewhat weird, but oh so lovely!) music (courtesy of The Signal's blog):

The second video shows a simulated depiction of the Phobos -Grunt Russian mission. Pretty cool (and bold) mission I must said. Let's hope it'll get to fly:

Anyway, gotta go change diaper now. So long for now.

Parental Leave

Yesterday was the first day of my month long parental leave. While the main purpose of it is to gives me and the baby time for some more quality bounding, the hidden agenda is to try to finish-up that iPhone application which we had been working on a while ago ... Parental duties and paid job, have so far colluded into putting that project on the back (waaaay back) burner. Or so it looks like. Non-obstante the fact that indeed, my (precious) geeking time had been slashed ten-fold by the arrival of the Baby, I also wasted the few minutes I could saves here and there, on trying to come up with a better way to save my application data. Since we were in a rush to get the app usable by the time we needed it, I had hacked my model so that the data (in a form of 3 arrays plus some metadata) were been stored using a NSKeyedArchiver, and fetched from it when the application was launched. That naive solution had two major issues: it was keeping in memory data that were not used, and it was putting the newly entered data at risk, since a crash of the application will (and did ...) prevent its data to be written to the disk.

To store permanent data on the device, there is 3 common possibilities: flat binary file, NSKeyedArchiver and SQLLite3. To store a limited amount of data, I personally found SQL (even Lite!) to be overkill and not that practical when dealing with objects (yes, I do know about Jeff Lamarche's project and the iPhoneLite3 project), thus I have been working on my own object persistence framework, which won't be as efficient as using SQLLite for backend (well I'm not that good!) , but will serve its purpose for this app and the others to come (hopefully!). Since I'm an ex-Newton user and developer, I couldn't help but inspire myself, rather heavily, off the Newton's Soup ...