I sold myself on the idea of getting a MacBook to develop an iPhone application. It wasn’t the dream of striking it rich with my creation that fueled me. I love learning. I also love buying. I could combine those loves with a sweet aluminum unibody MacBook. I bought the MacBook in March of 2009. Picked up an Objective C book, bought a developer’s license, and set off to write my application.
I followed the Stanford iPhone Application Development course. Watching the lectures and doing the homework got me started. I didn’t complete the class. After the 7th or so lecture I ventured off on my own to write SeaCast. SeaCast was going to be the mashup of 3 different pieces of data I used when I’d plan a day out on the water. My SeaCast app would provide a single place to go for tide, forecast, and current weather data. Probably not a huge demand for this application, but it would be something I found useful.
My routine for planning a boat/dive/fish trip was to start several days in advance by looking at the marine forecast. I’d go to NOAAs site and lookup the forecast for my region – Mobile Bay, Nearshore, Offshore. As the weekend approached I would watch the forecast for changes and also look at the tidal forecasts. If I were going fishing or nearshore diving I use the tide information to gauge what’s a good time. Getting this info meant looking up another website or using an app and navigating again to my area of interest. The day before the trip I’d check the current buoy status. This info is displayed on another NOAA site. You can get wind direction, wave height, water temp and many more metrics depending on the type of data buoy. Sounds like a lot of planning just to go and have fun.
I made good progress on developing the application. Concepts like Model-View-Controller weren’t easy for me to understand implement when I was trying to grasp the UI controls. I managed to complete a UI for drilling down the regions. It used SQLite to maintain a database of forecast feeds for all of the NOAA regions. Raw data was requested via HTTP, parsed and displayed for the selected forecast area.
I had a solid understanding of working with the data feeds. My plan was to apply the same techniques for the buoy and tidal information. What stumped me was how to organize this information. I wanted the locations for the buoy and tidal stations to follow the same hierarchy as the forecasts. The forecasts were grouped by major geographic regions then drilled down to smaller areas. For example, Atlantic → South Atlantic → Coastal Florida, etc. Looking back at the problem, I was dead set on getting the coordinate based tidal and buoy information in to the same grouping. I remember researching GIS topics for help. I believed the problem was how to sort the locations geographically while not hard coding a lot of rules. For example, you might sort one region East to West and another North to South. Not a hard problem. Now how do I take the hundreds of geographic regions that are defined for forecasts and apply them to all of the coordinate locations for buoys and stations? There wasn’t a nice set of data defining bounded boxes for all of these regions. The thought of creating the boundaries for each region manually was ridiculous. It didn’t take long for my interest to die. I had the MacBook. I could say I’d worked with Objective C. I could bring up SeaCast on my iPhone and pull down forecast info. The novelty wore off when my application’s provision expired. The feeling of guilt hung around.
I still enjoy that MacBook. It compiles a lot of C code. Surprisingly, it’s much faster than an equally equipped Windows box. It also renders a lot of HTML. I find myself obsessing as new versions and upgrades hit the market. Two and a half years later I still think about that promise. Buy a Mac. Write an app. It’s time to write that app.