Mobile Orchard, a new blog covering iPhone and Android development, posted a great interview with Hampton Catlin this week to kick off the Mobile Orchard Podcast series.

Hampton Catlin of Unspace is probably best known in the Rails community for HAML, Sass, and Make Resourceful. He recently launched his first iPhone app, iWik iPedia. iPedia is a $0.99 Wikipedia browser that has sold over 50,000 copies so far. In this interview, Hampton talks about building the app, the process of working with Apple and the App Store, and more. If you’ve thought about building an iPhone app, this interview is definitely worth your time.

Mobile Orchard was created by Dan Grigsby and Peter Cooper. Peter is best known for Ruby Inside and a book on Ruby. Dan Grigsby is a Rail Spikes blogger emeritus, entrepreneur, and Ruby/Haskell/iPhone hacker. So far, the content is a good mix of iPhone news and original content (like the podcast, and a video walkthrough of an early Android phone). Knowing Dan and Peter, this blog should be worth a spot in any aspiring mobile developer’s feed reader.

Why mobile development?

I don’t know about you, but I’m feeling the draw of mobile development. Luke is too. So are Hampton, Dan, and lots of other folks in (and out of) the Ruby community.

Why is this? After all, mobile app development is a lot more like building desktop apps than like building web apps. Take the iPhone: desktop Cocoa programmers have a huge head start over us web programmers. You have to use low-level languages like Objective-C. You’re locked into a closed and developer-ambivalent (sometimes developer-unfriendly) platform.

So why move from the web to the iPhone? There are good reasons.

1. It’s different.

Building an iPhone app is very different than building a Rails web app. For some developers, this is a problem. We call those people bad developers. Good developers build software, not Ruby/Java/Lisp/Blubb code. In other words, they’re not interested in mastering a single tool and staying there as long as they can. They may specialize, certainly – become a really really good Ruby/Java/Lisp/Blub developer – but don’t stop there. The Pragmatic Programmer famously recommends learning a new language every year, and this is great advice.

So why the iPhone? Because there is something to be said for learning languages and tools at opposite ends of the spectrum. Should a Ruby developer learn Python, a reasonably close cousin? Maybe, in order to learn the quirks of Ruby and to find other approaches to similar problems. But should a developer learn Ruby, Python, Perl, Lua, and PHP? Probably not, because these languages are largely redundant, and there is more to software than just dynamic high-level languages.

Learning Cocoa and Objective-C doesn’t just teach new approaches to the same problems – it teaches new approaches to new problems.

2. It’s a framework.

Web application developers these days are used to using frameworks. So while Cocoa and Rails have little in common, the approach of using a framework like Cocoa is comfortable to web app developers. Unlike, perhaps, moving from Rails to raw C++ or raw Haskell.

3. Money!

Success stories like Hampton’s always catch the eye of a certain class of developers. These developers used to run micro-ISVs. (Remember that term?) Nowadays, they often gravitate to Ruby or Python or PHP. They aren’t looking for a stable career at a big organization, and they aren’t looking for VC funding or an IPO. They just want to build cool things and make some money from it.

The iPhone App Store caters to this type of developer. Setting aside for a minute Apple’s benevolent (or s/ben/mal?) dictatorship over the App Store, the whole focus is on helping people monetize their applications. The entrepreneurial developer’s dream is to:

• build something cool
• in a reasonably short amount of time
• and make money from it on an ongoing basis with minimal marketing and maintenance.

That’s what the App Store is all about.

4. Ride the growth trends.

The web was a huge growth trend in the late 1990’s, and again over the past few years, in new-and-improved “2.0” form. Whenever possible, it’s smart to ride this momentum.

Is “mobile” a growth trend today? It looks like it, and a lot of people are betting that it is. But more on that in a minute.

5. Diversify.

If you’ve focused on Rails development for the last few years, you might be feeling the need to expand your portfolio. There is still a lot of Rails work out there, and are still a lot of interesting web apps to build. But most of us won’t be doing the same thing in 5 years than we’re doing today, and learning another marketable skill is always helpful. Which would you rather have on your resume?

• Rails developer since 2005

Or

• Rails developer since 2005
• Ajax developer since 2006
• Merb developer since 2007
• iPhone developer since 2008
• Next Big Thing developer since 2009

I’ll take the latter.

Trend or bubble?

The App Store has been a worthwhile platform for Hampton and lots of other developers. My question is this: will that continue? Are App Store sales on the decline, now that the novelty has worn off; or will they increase over time? Think of Facebook Apps: for about 3 months, even the stupidest Facebook App was made of gold. (Especially the stupidest?) But now there are tens of thousands of Facebook apps that haven’t gone anywhere, and the growth stage is over. For now, at least.

The traditional growth model for successful ventures looks like this. The App Store skipped the early stage (slow growth, waiting for traction) and jumped right to the vertical bit of the hockey stick. But rapid growth can’t continue forever, and eventually even IBM and Microsoft are no longer growth companies. That’s the top part of the idealized growth model.

So where are iPhone apps? Do they have years of growth in front of them, or is the boom over?

I’m pleased to announce that FanChatter Stadium has a new customer: University of Oklahoma Sooners Football. We’re providing in-stadium photo sharing on their brand new HD LCD screen. And, as a new feature, we’re also allowing them to collect and display photos on their website between games.

+ = EPIC WIN

The Sooners’ first game was on Saturday, where they rolled over UT-Chattanooga 57-2 in front of 84,715 fans. FanChatter Stadium performed admirably, and you can see the results here.

I’m proud of this rollout because we signed the contract on Thursday and delivered the goods on Saturday. Not a bad turn around!

Want to build something like FanChatter? Check out my PeepCode on integrating e-mail into your Rails application. Just want to pay us for it? Contact Marty Wetherall.

The MMS2R project is pushing forward to a 2.0 release that promises to be easier to use and more Ruby-like.

We want to make this the best MMS library in any language, and to do that we need your help.

We currently support the following carriers. If you don’t see your carrier on this list, please send an MMS message to me at luke@slantwisedesign.com and I’ll work on adding it to the library. We especially need European carriers.

• Alltel
• AT&T/Cingular
• Dobson/Cellular One
• Helio
• Nextel
• Orange (Poland)
• Orange (France)
• PXT (New Zealand)
• Sprint
• T-Mobile (USA)
• Verizon

A week and a half ago we tested FanChatter at the Metrodome during the Gopher-Bison game.

The response was really great and so we’re going to be back at this Saturday’s Gophers game against the Illini as well as at the Vikings game on Sunday. So if you’re going to either of those games, look for our promos and send in photos from your phone to get up on the big screen!

One of the cool things about working on FanChatter is getting to see behind the scenes at a major sports stadium. Here Marty shows off his phone down on the field.

Slantwise is proud to annouce the launch of FanChatter.com: the first fully mobile sports chat network. FanChatter is a micro-blogging site targeted at sports fans.

FanChatter allows sports fans to create groups and chat on the web or via their mobile phones. Fans can also use their camera phone to send in photos. If you like to talk about sports, give it a try.

On Saturday, October 20, FanChatter will be on the big screen at the University of Minnesota-NDSU football game. So if you’re there (or following along at home), send your photos to gophers@fanchatter.com (or ndsu@fanchatter.com). We’ll pick the best photos from fans to put up on the big screen!

FanChatter is a partnership between Slantwise and Marty Wetherall, producer of The Show To Be Named Later. Marty and Jon met at the second MinneBar back in April, and the site is a product of that meeting. Completing the circle, it was officially be launched at last week’s MinneDemo.

Like what you see? Need mobile development? Contact us.

At Slantwise, we’ve been doing some projects that involve taking user-submitted content from cell phones. Using an MMS-to-email gateway, it’s straightforward to ingest photos and videos into a Rails application with ActionMailer. Every phone we’ve tested has the ability to send an MMS message to an email address, so this is a cheap and easy way to get started. We’d like to use a shortcode like Twitter’s 40404 some day, but they are hellaciously expensive.

While receiving the email is straightforward, you still have to deal with the advertising and general crap that is added to the messages by the phone carriers.

Here’s an example from Sprint, by far the worst carrier we’ve come across:

Not only is this message stacked with ads and other nonsense, the worst part is that the photo isn’t actually included as an attachment! You have to download it from Sprint’s server.

Thankfully, we found the MMS2R library, created by Mike Mondragon. MMS2R greatly simplifies processing MMS messages. MMS2R removes advertising, eliminates default subjects, and makes fetching media from the message much easier. It even has a special case to download the real media for Sprint messages. MMS2R decodes and extracts files from multipart MIME email so you don’t have to!

Imagine you have a MediaItem model that has a title and a file associated with it (we used AttachmentFu to store the files). Here’s an ActionMailer you that will process an incoming MMS message and store it as a new MediaItem.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

require 'mms2r'
require 'mms2r/media'

class IncomingMmsHandler < ActionMailer::Base

  def receive(email)
    # create a new Media Item
    item = MediaItem.new
    
    begin
      # Parse the MMS attachments with MMS2R
      mms = MMS2R::Media.create(email)
      mms.process

      # Gets the subject, stripping out known carrier defaults
      item.title = mms.get_subject
    
      # Get the most likely media for the message
      # MMS2R mocks up a CGI.rb temp file object, 
      # so get_media can be used with AttachmentFu!
      item.uploaded_data = mms.get_media
    
      # persist the item
      item.save!
    ensure
      # clean up the temp files      
      mms.purge
    end
  end
end

The error handling in this example is rudimentary for simplicity’s sake.

This all works on a per-carrier basis. The currently supported carriers are:

• AT&T/Cingular
• Dobson/Cellular One
• Nextel
• Sprint
• T-Mobile
• Verizon

New rules have to be added to strip advertisements from unknown carriers (you’ll still be able to access the media). New carriers are easy to add, so don’t be shy about submitting a patch.

MMS2R is being used in production at several web sites including mymojobaby, Vedio.tv and our own project, which is still in private beta.

(This is a preview of some of what I’ll be speaking about at Ostrava on Rails. The speakers have just been posted and it looks like a great line up. Don’t miss it if you’re in Europe.)