2012 Red Ribbon Ride Contest Winner!

If you haven’t donated yet, there is still time. Please visit this link to make a donation.

A smoked ham and bacon wrapped asparagus for Easter dinner!

Always ensure that your cupcakes are properly secured!

Storing Complex Types Using NSUserDefaults

This week I wanted to store a complex data type using NSUserDefaults. Unfortunately, NSUserDefaults only allows you to store common types. Storing objects using NSUserDefaults can be accomplished by using NSData and NSKeyedArchiver.

The code below uses NSKeyedArchiver to archive someObject then store the NSData object in the defaults.

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
NSData *data = [NSKeyedArchiver archivedDataWithRootObject:someObject];
[defaults setObject:data forKey:@"someKey"];
[defaults synchronize];

To retrieve the object from the user settings, retrieve the NSData object using the same key that was used to store the object. Then use NSKeyedUnarchiver to retrieve the object.

NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
NSData *data = [defaults objectForKey:@"someKey"];
SomeObject *someObject = [NSKeyedUnarchiver unarchiveObjectWithData:data];

The class of the object that is being archived/unarchived must implement these two methods. If the object has a property that is not a common type, then that object must also implement these methods.

-(void)encodeWithCoder:(NSCoder *)encoder
{
    [encoder encodeObject:self.itemId forKey:@"itemId"];
    [encoder encodeObject:self.title forKey:@"title"];
}

-(id)initWithCoder:(NSCoder *)decoder
{
    self.itemId = [decoder decodeObjectForKey:@"itemId"];
    self.title = [decoder decodeObjectForKey:@"title"];
    return self;
}

Three of My Favorite iOS Frameworks

I have been doing iOS development for a few months now and I have come across some nice frameworks to assist in documentation, exception logging, and even a framework to help manage beta testing. I have found the following three frameworks invaluable in my current project:

1. TestFlight is the framework I rely on the most to date. I use it to manage distribution of builds, gain feedback from app testers, analyze crashes, and gain insight into what my users are doing by placing checkpoints throughout the application. The sign-up and setup process took only about 10 minutes. It was very easy to integrate with my project. Integration includes adding a static library to your project and adding one line code in your AppDelegate that contains your API key. Once this in place, data will now be sent to TestFlight and you will be able to see it immediately on TestFlight’s website. You can see what type of devices your users are using along with the time spent testing. If the app does crash by chance, you will be able to see the stacktrace as well. You can also push new builds out to your users easily. Once you upload your IPA file to TestFlight, they will send an email to your users that will have a link for them to install. If they are in the application while a new build is being pushed out, they will even get an in-app notification that there is an update ready. If your users have feedback for you, they can simply reply to the update notification email and the feedback will be stored with the build. One final thing, you can add checkpoints throughout your app to gain insight into what your users are doing while using your app. Adding a checkpoint is as simple as adding one line of code. I am sure there are more features that I have failed to mention here, but I encourage you to take a look at this framework if you do any sort of beta testing. You won’t be disappointed.
2. Before finding TestFlight, I was using BugSense. First off, they have different purposes. BugSense is an error logger for beta testing or production use, while TestFlight has more functionality to allow for managing distribution and gaining feedback from your users, but is meant for beta testing only. BugSense was also very easy to integrate into my app. BugSense also works for iOS and Android! I used this in our Android application as well and it was very easy to integrate. Bugsense allows you to gain insight into errors that are happening out in the wild. You can mark errors as resolved or not resolved to know which ones have been taken care of. BugSense also groups the errors together so you don’t have to sift through hundreds of errors. When I was using BugSense it was free. They have started charging for additional features since then. We will need to re-evaluate when we go to production if we are going to utilize it in our application.
3. Doxygen is my final favorite framework so far. It is used to auto-generate documentation for your code. For those of you familiar with .NET, this is like XML code comments. It allows you to document classes, properties, and methods by following a certain comment format. It will create HTML pages or you can set it up to integrate your documentation into Xcode. I found Doxygen more difficult to set-up, but I went way out. Instead of just creating the HTML documentation, I set it up so the generated documentation would show up in the organizer in Xcode. I also setup a service so I could just highlight code, right-click, click Doxygenize and voilà, the Doxygen template comment was inserted above my code. It is pretty slick if you are willing to spend the time to set it up. Maybe I will write a post about that another day.

Do you have any frameworks you use in your projects (iOS or Android) that you find beneficial? Leave a comment if you feel like sharing one or many!

Write Once, Run Everywhere

How Facebook Mobile Was Designed to Write Once, Run Everywhere.

I recently read the above article on ReadWriteWeb.com. The article describes the technical architecture of the Facebook mobile applications and the direction they are heading. The article is based on a presentation that a Facebook engineering manager gave. He seems proud of the architecture and the so-called progress of the application. In reality, the Facebook application gets worse every day and has gone from being one of the best apps to one of the worst. It isn’t coincidental that as Facebook has moved from a native app to a more web-based app wrapped as a native app that the user experience has diminished. The app use to feel native, was virtually bug free, responsive, and accurate. Now, the app barely works. Bugs are littered throughout the application from pictures being un-viewable to some friends having profile pictures that are of a different Facebook friend. It’s classic that this article has “Write Once, Run Everywhere” in the title. Java, which is also slow and unresponsive, has used this slogan for years. Writing something once, and running it everywhere often comes with a price and when that price is user experience, it often isn’t worth it. Is it worth having millions of users pissed off at your unusable product just so you can cut a few developers or so your developers can feel better about having non-redundant code? Facebook can easily afford to have a small team of iOS developers, a small team of Android developers, and a web team for dumb phones. This would have allowed them to keep the best user experience for each operating system until HTML5 was ready enough to support an equal or better user experience.

New Wheels

Yesterday I traded in my Jetta for a 2012 VW Tiguan SEL 4Motion. So far, I love it. It is a little bit different getting use to a gasoline engine again after having a diesel for a couple of years. I am excited to drive it to southern Minnesota this weekend. Click on the images for a larger view.