Random Musings of an Insane Mind

I ran into this while doing some development for SnapReplay, and, I knew that this would be a problem. Regrettably, the favorite solution is to delete the app or erase the virtual instance and start fresh, but, what causes this?

When your application first starts and you have a schema defined for SQLite, a database file is created and versioned. When you later make changes to the table schemas or add a new table, the version number is updated to allow migration. People that have downloaded your app are not going to want to uninstall the app and reinstall it.

So, we’ve made changes to our table schema, added or modified a table or whatever. Now, we need to go to our list of files, right click, New File… IOS Core Data, NSManagedObject subclass, hit next, select the Data Model for your project, select the entities. If you have only added a new table, select it, if you have modified tables, select them as well. Hit next, then, create the files.

Now, you have a few options. If your changes are slight, you can use the lightweight migration (in your App Delegate file):

- (NSPersistentStoreCoordinator *)persistentStoreCoordinator
{
    if (__persistentStoreCoordinator != nil)
    {
        return __persistentStoreCoordinator;
    }
    
    NSError *error = nil;
    NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:@"SnapReplay.sqlite"];
    
    NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:[NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption, [NSNumber numberWithBool:YES], NSInferMappingModelAutomaticallyOption, nil];
    
    __persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];

For a more complete discussion regarding more complicated data migrations, you can refer to Apple’s Core Data Model Versioning and Data Migration guide.

After sixteen days of whirlwind development, digging through APIs, bad code examples, bugs in documentation (31 of 33 reported documentation bugs have been fixed), this afternoon I released 0.9.11 of the SnapReplay iPhone app to the beta testers through TestFlightApp.com.

On Friday, we had a pending list of bugs and features which were whittled down this weekend to a set of bugs that were blockers, a set of features that would make version 1.1, and a final set of features that would be used for 1.0. Sitting and looking at a set of features and having to decide which make the cut is not an easy task. Compromises were made based on how useful that feature would be in everyday use and whether it should hold up submission to the App Store.

Over the weekend, Paul and I went through twelve versions of the app, fixing bugs, tweaking features leaving one final feature we felt couldn’t be ignored left. Hours of pouring through documentation, bug reports, code sprinkled throughout the net, resulted in me finally deciding that the feature could wait until morning. I pushed out a last test build which included everything but the last feature for testing and went to sleep for a few hours.

When I woke up, I realized that my approach to the problem was not unique, it had to have been solved previously and then I realized that the examples were deleting from the wrong class and that Apple had a convenience class method to handle this very situation. A few minutes later, that was working.

A few tweaks and 0.9.11 was pushed to TestFlightApp for beta testing.

Phew.

Hopefully this evening I’ll push 1.0.0 and submit it to the App Store.

While the SnapReplay iPhone app isn’t finished, it is mostly feature complete compared to the Android app. The first photo was uploaded last night via iPhone and the first event, Dunsborough Sharks Pre Season Party, with both an iPhone and Android phone was taken.

When was the last time I used Objective C? early to mid ’90s? This was going to be fun.

I had XCode installed but only played with the emulator to see how web pages looked. I didn’t own an iPhone and have used Android as my preferred OS for smartphones.

Comparing the development environment between the two, XCode definitely won this hands down. Within minutes of sitting down, I had my storyboard put in place, pages looked consistent when run through the emulator as buttons were connected. All that was left was to write some of the logic behind the pages… and that is where the problems started.

I can’t say I ever recall Eclipse crashing on me. XCode? After submitting 20-30 crash reports, I just click reopen without sending a bug report. Searching google shows that I’m not the only person experiencing these problems. Assistant mode gets confused which requires you to delete the files, and reimport them – and when it reconnects things, things tend to work as documented.

Since the app is based around the camera, we find that the iPhone Simulator doesn’t handle the camera. Even the Android emulator plays a repeating grid pattern with a bouncing ball to simulate the camera, but, with the iPhone Simulator, you get a blank page, your event fires, but, it isn’t really helpful. So, I purchased an iPhone 3GS for testing.

Objective C is reasonably easy to jump back into, but, Cocoa, Apple’s framework, is a nightmare. I submitted close to thirty documentation fixes, and to Apple’s credit, they are acted upon promptly. Numerous blog posts talk about the problems, API documentation errors and example code that won’t even compile, but, you can see that Apple does handle things pretty quickly when posted on their system rather than a random post on the Internet. While I wasn’t doing anything extremely complex, I did find it frustrating that the two features I needed to access were rife with documentation problems. That aside, a seven day whirlwind of coding resulted in an app that is functional and points out some other issues.

When I chose my smartphone, I chose Android for two reasons. One, I could develop applications for it for myself – of which I’ve done none of the things I envisioned. And two, I felt I needed a keyboard on my phone. I tried TMobile for 47 frustrating hours and got a bill for over $80 for dozens of missed text messages – not delayed, but missed, and several calls that went to voicemail even though I can see their antenna from my backyard. I ended up unlocking a TMobile phone and I run that on AT&T – experiencing the world at 2G speeds. When you iPhone people complain that AT&T has throttled you – that’s the speed I run at, 24×7. :) I have contemplated bringing a Desire Z down from Canada.

However, the Android experience is a bit different than iPhone and it was difficult for Paul, my brave alpha tester, to explain how iPhone apps normally worked. After actually sitting down with an iPhone and working with it, several UI issues cropped up due to me porting Android ‘feel’ to the iPhone. After some rework, I have an app that feels more like an iPhone app but still maintains a fairly good parity with the Android version. There is no substitute for actually using the platform you’re developing for. While I wouldn’t switch to the iPhone, the UI/UX is very nicely done.

TestFlightApp – absolutely invaluable. After getting the app to a point where I felt it was worth sending to Paul to test, a few hoops and stumbles and we’ve got an .ipa that can be deployed. Paul downloads the app and the first test text from a phone is a success. It takes a little time to wire up the SDK from TestFlightApp and navigating their interface is a little cumbersome, but, we are collecting data and getting things working.

    SNAPlib *lib = [[SNAPlib alloc] init];
    [TestFlight takeOff:@"api key"];
    [TestFlight setDeviceIdentifier:[lib get_PhoneID]];

While they suggest that you use the UUID, I ended up writing a library function around the CFUUID which we maintain for persistence. Since I already had this function, I didn’t need to use the phone UUID class which is deprecated and is a blocker for new apps being submitted to the App Store. I haven’t used checkpoints, but, it is immensely easier than having Paul hook up DDMS and send me a chunk of logs.

TestFlightApp wraps exception handling, which put this in the console, making remote debugging a bit easier.

Unacceptable type of value for attribute: property = "event_auth_token"; desired type = NSString; given type = __NSCFNumber; value = 6629.
7 SnapReplay 0x000aabb3 -[srAppDelegate get_from_storage:val_name:def_value:new_value:] + 775
8 SnapReplay 0x000b1bf1 -[SNAPlib set_EventAuthToken:] + 121...

If you develop for iPhones, TestFlightApp is very nice. Thank you to Craig Agranoff for the heads up there.

All in all I found the experience to be quite good. Today marks day 75 since the genesis of SnapReplay and while I wanted to write the iPhone app much sooner, it is close.

With that said, if you have an iPhone or Android phone and would like to help test – even if you only take a few random photos to send to the beta stream, it would be appreciated.

In the last few days, I’ve had a few projects come up that could have been interesting to develop on the IPhone. When the IPhone first came out, I signed up as a developer but never downloaded the SDK. Today, I took the time to download the SDK to test the emulator for the recent template design for this blog to see how it displayed on the IPhone.

The framework appears to support Python, Perl, Cocoa and Ruby as well as native C.

Here are two screenshots of this blog on the IPhone emulator.

The quick way to start up the emulator after you’ve gotten the SDK from Apple’s Developer Connection is the following:

Open up Xcode, File, New Project, Select Application underneath the IPhone Application, click Utility Application, Choose, enter a project name. After a few seconds a project window will show up with the default of Simulator – 2.2.1 | Debug. Click Build and Go and it will compile the test project and open the IPhone emulator. Click the power button at the bottom, to bring up the main menu which will show Photos, Settings, and your test application with Contacts and Safari icons at the bottom. If you open Safari, you can key in a url or use one of the existing bookmarks.

Command-left arrow or Command-right arrow will rotate the screen from Portrait to Landscape and back. You can also use the Hardware Menu and Rotate Left/Rotate Right.