I started this site a long time ago. At times I’ve tried to keep my weblog current, but that hasn’t always been easy.

I’ve been spending much of my time focused on iOS apps both for work and for myself. With the new year I'm focusing very hard on my next project. I'll post up details as they come.

Life at Expedia working on Mobiata apps has been fun. With FlightTrack 5 finally out at the end of 2013 and the tablet release coming very soon, I'm going to be working on a new project that is very exciting.


Ab Initio

This blog is going to talk about my experiences and frustrations as a software developer. A lot of what I write about is for my own personal edification and not necessarily intented for human consumption. Read at your own risk.

You can find the RSS feed here.

Robots on a Board

My good friend Chris Biewer has been collaborating with me on yet another project. Robot Candidate is now in the app store, for the iPad! 

Its been a long time in the making and I’m super happy to finally have this thing shipped, even if we had to drop a few features along the way. I’m not sure if we’ll actively invest more time into this app, we’ve already circled back to another project we’ve been dreaming of for several years. 

Its been an exciting 2014 already.

And It Was 2012...

2011 was a great year. I worked on some cool projects, shipped one of my own apps, and helped others ship a ton of apps. The search for a perfect job continued, but now in 2012 I think I'm finally there! I got to do some awesome hiking in both MN and NM. Overall I'm pretty happy with how things went, but this year is going to be 10x better.

Photo Jumbler was not a smashing hit on the App Store, but it really wasn't meant to be. It was a fun collaboration with my art buddy and I learned a lot during the project. Jambots ended 2011 shipping 5 or 6 apps, with as many prototypes that may see the light of day soon. Personal growth in development at it's best.

For a day job I continued to work on iOS apps for both row27 Studios and Imation's XtremeMac brand. Working with hardware accessories is challenging, mostly in the product design. It was a great opportunity and I worked with some truly wonderful people. Like most corporations, meh, time to move on. Expedia is great, they let the Mobiata team work independently on most things. We are a completely separate entity that works well across the boundaries. I really enjoy the collaboration and the smart people that I get exposed to. It is going to be an awesome time.

Busy Busy

Things have been busy around here. I've been working on many projects, some done and some still in progress. 

I've been collaborating with my good friend Terry Schubring on some projects for our joint venture Jambots. We released Railroad Train for the iPad a few months ago and just got our second app, Lo-Fi Folk Arranger, into the store. We have game / toy app, Lifebulbs, that will be in the store soon as well. 

These projects are all done using our awesome native wrapper. Terry creates the UI with HTML5 and WebKit goodness, while I do all the heavy lifting with objective-c. We support caching resources, so we can ship all our assets but update them when bugs come up. We created a multi-track audio engine, something web programmers can only dream of without a plugin like Flash. It also has support for iAds and In App Purchase, so we can support both ad supported and freemium models for our apps. 

Check Railroad Train and Lo-Fi Folk Arranger on the app store.

Silly code snippets useful for interviews

The never ending process of interviewing with prospective employers often involves silly little logic tests. I'm going to start a series on how to solve some of these problems using standard C. These entries assume you have some basic understand of C and pointers. For the following example you should understand the basics of how C strings work.

Reverse a string for me son

To kick the series off I'm going to solve a very common problem that comes up during interviews, reversing a string. While not a practical problem, what employers are trying to determine is how efficiently you solve it.

If the interviewer does not provide you with any function prototype, then you should ask them to do so. If they tell you to make it up yourself then you have a couple of choices. I'm going to keep things simple in this post and assume that you can just pass in a character array and its length. These example do not require the use of any library functions either. Your interviewer may want you to determine the string length, either manually or using strings.h. I'm not going to talk about that for this example and just focus on the actual reversal of the string.

And then it was fall

The summer has gone by fast. I started at Thomson in July and it has been a great two months. For the first time in my career I don't worry about how long it is until Friday. Many weeks I wake up and my wife mentions the weekend and only then does it dawn on me that I don't have to work tomorrow. 

I've been very busy getting a demo ready for their meeting of the board. It was pretty high profile and everyone likes what I accomplished for it. I have been mentoring a few developers on iOS development, which has been educational for myself as well.

I am presenting at CocoaHeads tonight, the topic is Core Data on iOS with Networked Apps. I put a lot of effort into it and am happy with the slides and the sample project. I'm sure that the delivery will be fine. While I don't like public speaking I have never had a problem giving technical presentations.

I have to get my secret project done soon, it will be a year at the end of the month. It has been fun at times, but now I need to get it done so I can move on. If it ends up making money great, but I have other things that require my attention and I'm certain they will turn a profit.

Summer Time

That last six months have been interesting, with many things happening.

- Updated Hansel,
- Started worked with Nibisoftware Group and got their iPhone/iPad app into the store,
- Created Contacts Map and have updated it several times with lots of great feedback,
- Continued working on NDA project for Social Networking,
- Started preliminary work on a remote control project for the Mac/iOS

This was of course outside of my regular 9-5 routine, which has recently changed. I have accepted a position as an iPad developer at Thompson-Reuters working on their next gen Westlaw application. I am very excited and this will definitely take my career to the next level. 

I wish that I could have been more active on my weblog, but all of this coding has gotten in the way of that. I still want to do a series on Apache CXF/JAX-RS/iOS, and am hoping that I can get to work on that soon. As of now I just don't have the time.

iPad after a few weeks

Now that I've been working with the iPad for a few weeks, I really like what Apple has done with the development process. 

Making Hybrid iPhone/iPad applications is very easy for existing iPhone apps. You simply open up the xib in IB and select the File -> Create iPad version menu option. That combined with UI_USER_INTERFACE_IDIOM() and you can reuse all your existing view controllers while having full control over how you handle specific devices. 

I think there merit in making hybrid apps from existing iPhone apps in many cases. Nibipedia for instance is a perfect candidate for this. It is a small lightweight app that is mostly UIWebView driven. There isn't a lot of UI code for animations or dynamic view creation. It makes sense to just create a hybrid app.

Hansel on the other hand is more complicated. My initial attempt to make a hybrid app has failed miserably. The main problem is that I have lots of UI code that moves views around and makes assumptions about the device, that it is indeed an iPhone. While I could have written it in a more generic fashion, I never felt the need to do so. It didn't seem like there was enough benefit for spending the extra time on a free app. 

Hansel Crash Reports

While submitting Hansel 1.5, I decided to snoop around iTunes Connect. I hadn't really looked at the site much recently and Apple has been busy updating it for the iPad. To my distinct amusement, I saw this message.

New Year

I started a new job over the new year. Working for ITR Group was a good experience but they lacked direction and leadership. I was the senior most engineer out of a team of 6. It was enjoyable but I'm glad it is over. I have iPhone work I'm doing on the side, so I still get my fix.

Back at McKesson, I am now working with GWT, Java, and RDF. It is interesting work and I am happy to broaden my skill set. I forgot how challenging working with Eclipse can be, but I plan to work with CXF web services to expose data to the iPhone. I'll be writing a set of articles about that in the coming months.


I've been working on a couple of projects since my last blog post. I plan to have the next installment on Data Services done by the end of the week. There will probably be 2 more posts in the series after that.

Hansel has been submitted to the app store for review. I'm waiting to hear back from Apple, probably another 5-10 days. I added a new page about the app. It explains how to use the app and provides a way for users to leave feedback.

My only real concern is that it will get rejected for the way I handle current generation iPods. If I do not detect a camera, then a message is displayed instead of the image picker UI. The interface guidelines doc specifies that functionality which is not available should not be displayed. I tested on an iPod at the last minute and decided for a quick fix so I could indicate that it is supported. Other than camera support, the app works flawlessly on the 2nd gen iPod Touches. 

I've also been working on a project that involves social networking. Due to NDA, I'm unable to talk about it in any detail. Suffice it to say, it is a pretty cool project :)



This is the fourth installment about using and accessing RESTful webservices on the iPhone.

You can download the example project artifacts here. This includes the iPhone example project and SQL Server scripts for generating the CarDealer DB and demo data.

Getting Started with iPhone + Data Services

Getting this post out took much longer than I thought. Setting up my .NET development and hosting environment was painful. My personal environment is different from my work environment, so I had some catch up after several months of not using it. 

Setting up SQL Server Express was not bad at all. I had an older version and decided to upgrade it to '08. Trying to create the data services project was painless as well. The pain began when I tried deploying to IIS 6 locally. While I'm sure someone out there can do it, I was unable to make it work. I decided to setup a Windows Server '08 VM to ease the pain. It helped a lot, but was very time consuming.

I started looking around for a free .NET hosting service that I could use to make the services public for the example. After several hours a gave up on this. I could have paid for a cheap one, but I doubt that I'd ever use it for anything else. 

Sample Code Update

A reader pointed out a problem with the sample code where it would not compile. I tracked down the issue in RestConnection and fixed it. The data member has been renamed to responseData. This should fix the compilation problems.

Both sample code projects have been updated with the fix.

ADO.NET Data Services

This is the third installment about using and accessing RESTful webservices on the iPhone.

There is no example project associated with this post.


[ADO.NET] Data Services is Microsoft's way of turning EDM into web services. While researching the best way to access data stored in an SQL Server database from the iPhone, we decided to give Data Services a go around. Superficially it matched our broad criteria for the project's services layer:

  • RESTful Interface,
  • JSON payload support,
  • Run on IIS,
  • Easily access SQL Server

Accessing it on the iPhone turned out to be very simple. After it was accessible via a browser I began working on displaying a simple table from the database. I created the first version of RestConnection and I was able to get a list of data primitives out of the database and displayed in a UITableView in about an hour.


Atom is the default format for Data Services. You can specify JSON by setting the Accept header on your HTTP requests. JSON is much easier to deal with on the iPhone because of it's simpler format. However, if you have a good Atom handling methodology than that format maybe preferable.


The example code for the first 2 posts in the REST series have been updated. 

I discovered a problem with the willSendRequest delegate callback not being passed the current request. There was also a bug where the Accept header was not being defaulted to application/json if one did not exist.

JSON Handling


This is the second post in a series on accessing RESTful web services from the iPhone.
The example project used in this post can be downloaded here.


JSON has been around for about a decade now.  It has more recently become a popular alternative to XML because of both a smaller payload and a standardized format which focuses on associations and collections. WCF web services, for example, provide out of the box support for JSON as a data exchange format. After years of dealing with XML and various schemas, I prefer JSON's succinct style.

JSON + iPhone

As far as the iPhone is concerned, handling JSON is not currently built into any of the frameworks. For native development, there is nothing to specifically facilitate consuming or exporting JSON. However some people at Apple do recognize that JSON is widely used, as evident by both its support in Dashcode bindings and its use as the exchange format for APNs.

Because the JSON specification is extremely simple, this does not pose a problem for creating a JSON handling solution. The question always arises, should I find someone else's solution or roll my own? In my case, I take the lazy programmer approach. I am generally lazy unless I find the problem very interesting or I can't find something to suit my needs (in that order). Sometimes a problem *IS* very interesting and I want to solve it in my own way, as a personal challenge. Sadly business deadlines and schedules don't accommodate this very often. So to the end of being as lazy as possible, I found a very well written (complete with test cases!) JSON "library" that works on the iPhone.


I actually looked around at a couple of JSON handling "libraries" for the iPhone. BSJSONAdditions was the only one that had test cases and more than one contributor. What it lacked was specific support for EDM date types.  The JSON format does not have support for date as a first-class primitive type, only numbers and strings. Obviously no iPhone library I was going to find would have support for *THAT*, nor did I expect it to or even anticipate needing it (lesson learned there!). I will discuss EDM, EDM dates, and my additions to BSJSONAdditions [pun intended] in a later article.

This library translates JSON objects (name/value pairs) into NSDictionarys and JSON arrays into NSArrays. So given the following JSON:
																					    "myCoolObject" : 
BSJSONAdditions would create an NSDictionary with one entry, "myCoolObject". The value for "myCoolObject"'s entry would be an NSArray with 2 values, "value1" and "value2". 

The Example

This article will build on the previous post's project. Those classes will be modified and extended, as well as adding the BSJSONAdditions to the project. The primary focus of the changes will be on parsing the JSON data and displaying it in a UITableView. 

If you have not yet downloaded the source for this example, you can do so here.

This post is not about explaining what a UITableView is or does and assumes you know how to use one. Please referring to UITableView docs for more information.

The Project

The only new files are those under the BSJSON group, now at the top of the project.


This class has been slightly extended to incorporate the BSJSONAdditions. As a convenience, there is now a new property for returning the response body as a parsed dictionary.
// Returns a dictionary representation of the last data received.
																					@property (nonatomic, readonly) NSDictionary *dictionaryData;
- (NSDictionary *)dictionaryData { return [NSDictionary dictionaryWithJSONString:[self stringData]]; }


This class has changed the most. The UITextView has been removed and replaced by a UITableView. The delegate and datasource have been set to the view controller.

The finishedReceivingData method has been changed to the following.
- (void)finishedReceivingData:(NSData *)data
																					    NSLog(@"finishedReceivingData: %@", [restConnection stringData]);
																					    [activityIndicator stopAnimating];
// Get the dictionary containing the raw parsed data. NSDictionary *rawData = [restConnection dictionaryData];
// Get the interesting search results data for display to the user. [tableData release]; tableData = [[[rawData objectForKey:@"responseData"] objectForKey:@"results"] retain]; [mainTableView reloadData]; }

A parsed dictionary representation of the data is now retrieved instead of the raw JSON. We reach into the responseData and get the results which contain the interesting information that our UI wants to display, search result information.

The table view methods section has also been added. These methods are for the table datasource and delegate implementation. Basically for each result we display a table row that shows a search result description and it's URL. Thats it, pretty simple and straight forward.


This post has mostly talked about JSON and how to parse it on the iPhone. The next post for the series will talk more about connecting to an EDM backed web service and some of the challenges that have to be overcome in doing so.

Until next time, enjoy.


This is the first post in a series on accessing RESTful web services from the iPhone.
The example project used in this post can be downloaded here.


Unlike many other types of web services, all RESTful web services provide a uniform set of actions irrespective of their data entities. Every resource, or "noun", in a RESTful web service has the same set of methods, or "verbs", to do any and everything to that resource.

Resources are specified using HTTP URIs.  www.myurl.com/people could represent a collection of persons, while www.myurl.com/people/joebob would represent a single person. I should note that normally you would have your resources identified by a unique id, such as SSN or account number, and not by something like a name. That is a different discussion however.

The HTTP methods POST, GET, PUT, and DELETE map to basic CRUD (Create, Read, Update, and Delete respectively) very well. Non RESTful services may have methods like CreateWidget, UpdateTheThing, or RetrieveMySearchStuff. Under these schemes you would invoke different "verbs" depending on the "noun" you're handling.

Using our example URI above, if we do a GET on /people we would expect to get back all the persons in the collection. Doing a GET on /people/joebob should only return one person, joebob.

REST + iPhone

One of the great things about REST web services is that consuming them on the iPhone is easy. NSURLConnection provides all the functionality required to connect to a URI and transfer information in and out it. By simply building an NSURLRequest, you can perform all your CRUD operations via the NSURLConnection. We are going to simplify access to the NSURLConnection class through composition and object delegation. 

In any non-trivial client application, there are multiple objects in your data model. RestConnection will help to compose the commonalities of accessing those objects. It will also provide a way to persist information associated with the request; the NSURLRequest, NSURLResponse, and the response data.

The Example

I'm not necessarily a proponent of Google, however they provide some very useful web technologies that are very easy to use. For this article I'll be using their non-javascript AJAX search api. Though the RestConnection class will support all HTTP methods, I'll only be showcasing the GET functionality for now. We'll evolve the class as the articles progress.

In keeping with the classic search paradigm I'll keep the example very simple. The end result will look like screenshot on your right. The text field at the top allows search text to be entered and the text view on the bottom displays the results. You can grab the code here if you haven't already.

As will all future examples, this one assumes that you have an iPhone development environment already setup. If you don't then start here. This also assumes that you have a basic understanding of iPhone development. Some of the things I talk about may not make sense if you do not.

The Project

On top of a bare bones iPhone window project, there are the following additions; a view controller and accompanying xib, the RestConnection class, and the RestConnectionDelegate protocol.

I'm only going to be talking about the interesting parts of the codes in this article. All that I'm going to say about the app delegate is that it is standard glue code, nothing special going on in there. Lets focus on the RestConnection and it's client, SearchResultsViewController.


RestConnection is a lightweight composition class. It houses an NSURLRequest, NSURLResponse, NSData, and (while loading data) an NSURLConnection. It allows you to specify a base URL string that can be prepended to all requests it handles. It also provides a delegate for callbacks of interesting connection events. Lastly it provides methods for both loading url requests and accessing the current state of the RestConnection; the last request, last response, and last response data.

The method initWithBaseURL is the designated initializer for the class. Calling init will cause this method to be called with an empty base URL. Most of the time when dealing with web services there is a root URL (i.e. domain or ip address) that a collection of services will have in common. The base URL is a convenience for dealing with collections of endpoints so you can easily specify relative URLs in your requests.

Once the class is created, you can set an optional delegate. The delegate will receive callbacks about interesting connection events. All of the information passed to the delegate are accessible via properties as well.

Once a RestConnection instance has been initialized, it can begin requesting data using NSURLRequests with the performRequest method. RestConnection uses NSURLConnection to perform all the requesting. An instance of NSURLConnection is created every time performRequest is executed and destroyed after the request is completed. NSURLConnectionDelegate method callbacks drive the object after this.  The interesting ones are either passed on to the RestConnection delegate or used to accumulate the connection data.

Please note that an instance RestConnection is only meant to retrieve a single resource at a time. Attempting to call performRequest while a request is already pending can have unexpected consequences. A future version of this class will prevent this from being allowed. Creating multiple instances of RestConnection would allow this type of behavior. 


This view controller drives most the example. First, when the view loads, it creates an instance of the RestConnection and manages it for the lifecycle of the view controller.
- (void)viewDidLoad {
																					    [super viewDidLoad];
																					    restConnection = [RestConnection new];
																					    restConnection.baseURLString = @"http://ajax.googleapis.com/ajax/services/search/";
																					    restConnection.delegate = self;

Here you can note that it instantiates a RestConnection and initializes its properties. The base URL is set which will cause subsequent requests to be relative to that URL string. The delegate is also set to the view controller's instance, this will allow it to keep tabs on the request as the it progresses.

iPhone + EDM + REST

In my first series of posts, i'm going to be talking about my experiences with developing a medical application for the iPhone. This project involved a Microsoft SQL Server database and C# .NET Entity Data Model on the backend and standard native APIs on the mobile device.

I'm going to talk about the challenges me and my coworker faced interfacing a nascent ORM with iPhone technologies. Hopefully someone else will find this information useful in the future.

The first post talks about creating a RestConnection class to facilitate gathering RESTful resources.

Even your worst day has a lesson to learn.