Random Musings of an Insane Mind

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.

It’s been a long road of late nights, early mornings, and quite a bit of learning and coding. When I came up with the idea, I selected node.js and socket.io to develop the project. Shortly thereafter, I started working on the Android App, testing my mettle with Java, a language I hadn’t used in 9+ years. Seventeen days after the concept, we had our first test, resulting in an archive of Roger Waters ‘The Wall’.

The Android app was refined from a usability standpoint, the site UX lagging behind the infrastructure and databases being built to support the site, but, always moving forward, pushing 133 commits, sometimes massive rewrites to change functionality to work much differently than originally anticipated. Iteration sometimes led to massive backend changes while maintaining the site functioning and live as more people poked and prodded and were generally impressed with the idea.

Reminding myself that this is an app that was built ‘in my spare time’, I’m still somewhat amused that 1k+ lines of Javascript, 1.2k+ lines of Java, 100+ lines of PHP and a few dozen lines of Python were written and I have a workable site. I have started to write some Objective C, but, nothing more than a few tests and demo scripts to dive into writing the IPhone app.

With that said, I’m looking for people to beta test the Android App and give feedback. Extra Bonus points if you’re willing to go to a concert or event and use the app. Even more bonus points if you have the ability to recruit a second (or third) person to take pictures at the same concert. If you have an IPhone and are willing to Beta Test, get in contact with me. I don’t have that app completed, but, it is based very heavily on the Android App’s flow as we have spent a lot of time working out the interface. It is ugly, but, we believe it flows well and is very usable. Still have a minor lag bug that appears to be related to JSON parsing.

I’m still happy with Node.js and socket.io. There are some things I will probably change with expressjs which I might handle with my own middleware, or, might do a fork/pull as it is functionality others may find valuable. I’ve reworked a lot of functionality to help the User Experience and have gotten a lot of good feedback.

I’m unsure whether I would write it entirely in node.js again, but, it was still a great learning experience. I might rewrite it later, but, for now, it seems to do just fine.

So, if you can help me out and try the app or find a few of your friends to help out, it would be appreciated.

Thank you.

SnapReplay.com