Creating the Sports Schedules App for the iPhone

I finally released my first real iPhone application in the app store that I did not create specifically for a client. The app is called Sports Schedules (great name, eh?) and is available via the Apple App Store here: bit.ly/SportsAppStore.

First, a quick background

I really do enjoy watching any Pittsburgh sports and it is pretty easy to remember to watch a Steelers football game.  But when it came to college hoops or hockey I frequently forgot about the games and missed them. Being pretty busy with work as well as (the more full time) entertaining my 5 year old I really didn’t leave much mental capacity for remembering there was a game that night.

Well … I have this nice smartphone so I perhaps I’ll put it to work for me, right? So I launched the App Store app and searched for Sports Schedules. I was faced with the very standard problem of finding a useful app in a sea of apps that didn’t do what I wanted. To top I off, there wasn’t an app simply called Sports Schedules so I figured I would just go ahead and create it.

Other apps

There are certainly other apps out there which have schedules for sports in them. First, each sport and even many teams have apps specific to them, but I really didn’t want a bunch of one off apps. Next, there were apps like ESPN, etc. While they have schedules in them … I really wasn’t impressed with the way the information was organized. Lastly, there are apps which simply put events on your calendars and I wasn’t really pleased with that scenario either.

Design

The first thing I was concerned with was creating some a nice, simple design for the application.  I started with some wireframe mockups using Balsamiq (great tool) so that I could initially focus on the information flow within the application.  Since it isn’t (initially) a large app this didn’t take much time: I wanted a dashboard showing the week at-a-glance, and the ability to add and remove teams

Next, I wanted to spend some time skinning this wireframe as I wanted to focus on creating a visually appealing app.  This reinforced the fact that I am a TERRIBLE designer.  I spent hours creating what I thought was an acceptable design and showed it to  my wife.  Trying to be nice she said: “It looks like you did it your self … can’t you buy a design on the Internet or something?”  Thankfully … you can … and I did!

Data

Now that I had proven my lack of design skills, I decided it wasn’t worth putting too much time into the app until I was able to locate a source of the data for the schedules.  Initially, I had thought about just entering it myself or paying someone a few bucks to enter the data into a database manually and keep it updated.  The problem is, that does not scale and is in no way reliable.  Instead, I started the search for a source of the data as an online service.  After searching for well over a week and contacting many many sales people (still gettin’ those emails) I finally found a source for the data … data that is not free and not cheap, as it turns out.  Before fronting the cash, I decided I better actually create the app first.

Developing the app

Once committed to creating the app, the problem became finding time to actually sit down and develop it.  I set a self-imposed deadline of “May” to try to keep motivated. With a full time job and a family this was indeed the most challenging part.  However, I managed to push through it and get the code written so I was able to move on to the next phase, the services.

Services

Next I needed to decide how to get the data updated on the app.  I didn’t want to spend a lot of money on servers but also I wanted to be able to scale up easily.  Elastic cloud computing seemed to make sense but last I had checked cloud services were a little pricey.  Lucky for me, Amazon started their deal where new customers get a pretty good share of EC2 instances and EBS storage free for a year so my decision was pretty easily made.

Next, I needed to decide whether or not to use a Windows instance or a Linux instance.  In a previous life, I did a fair amount of work on Linux but in recent years I was far more productive in Windows so that was my original choice.  The thought was that if I wanted to expand with some web applications I would have a nice .NET and SQL instance setup.  However, I quickly realized that Windows instances in Amazon are not nearly as economical as Linux instances so I scrapped that idea and setup an Amazon AMI Linux instance.  Frankly, the fact that the Windows instance uses a minimum of 30 GB of EBS storage and the Linux instance only 6 GB solidified that plan.

For better scalability and performance I decided to generate static XML data files for the iPhone app to download from.  This would mean fewer resources used on the Linux instance and would enable me to leverage Amazon’s CDN if necessary to better distribute the content.  As a result, I actually have no real web services serving up the content.

Integration

With the plan for services underway, I now needed to figure out how to get the data from my provider into a format suitable for the app.  As an Integration Architect on many projects I learned a lot of patterns and techniques as well as best practices for this sort of problem.  The primary take away is to decouple the data source from the apps in the event I need to replace it or even aggregate the data from multiple sources.  Also, having worked extensively with BizTalk I saw great value in leveraging an integration platform but BizTalk is far too pricey for my problem.  I decided to investigate free/open source integration solutions.

There are several FOSS integration platforms out there: WSO2, Mule, JitterBit, etc.  JitterBit caught my attention for a few reasons: it was simple, it had just the features I needed, and the installation was relatively lightweight.  It also came with a decent development environment.  JitterBit allowed me to very quickly integrate the XML data source with my database (PostgreSQL) and then to output the static XML files.

More app development

Now that I had a steady stream of data coming in from the provider, I needed to finish the coding in the application.  Hooking up to the XML content was a pretty standard academic exercise as was adding in some small features and fixing bugs.

App Store

The part I dreaded most was submitting to the App Store.  One can spend a lot of time and a lot of money just to have Apple reject the app for some completely unforeseen reason.  In nearly all occasions, when I submit to the App Store I get rejected at least once.

I submitted the app fully expecting to get rejected … what I didn’t plan on was that I would be the one doing the rejecting.  In two occasions while waiting for approval I found bugs and needed to reject my own app.  After re-submitting it … twice … I was very pleasantly surprised when my app was approved after nearly EXACTLY one week.

After all the effort, my app was finally in the App Store and working well … maybe a few bugs that need squashed … but overall a pretty smooth launch.

Advertisements