Hacker News new | past | comments | ask | show | jobs | submit login
Developing iPhone applications using Ruby on Rails (ibm.com)
16 points by jmonegro on Aug 1, 2009 | hide | past | favorite | 3 comments



When developing websites recently with an eye towards mobile visitors, I've been using the device detection classify the requester into one of three categories, and serving a possibly different presentation for each:

  - smartphones
  - feature phones
  - desktop and laptops
I'd like to ask those of you doing mobile webdev what your take is on this. Do you use these three "buckets"? Or see any problems with doing so? Do you make different distinctions? If so, why?

Some background:

Been thinking much more about mobile users in the last few webapps I've made, using device detection to somewhat customize content depending on broad device capabilities. IMO this is a good middle ground between two extremes: (a) serving a lowest-common-denominator html response that will work OK for every requester, and (b) serving something slightly different for every (OS, browser, device) combination you care about. (And neglecting those you don't :)

So-called "feature phones" are the kind that still make up most of the cell phones people on the planet use every day. Smartphones are the more recent and, uh, featureful devices like the iPhone, Android/G1, Palm Pre, and color Blackberries.

The line between a feature phone and smartphone is fuzzy. Generally, though, a device called a smartphone will have a full qwerty keyboard for input (hard and/or soft); larger full color screens; higher data connection speeds; and richer web browsers capable of rendering full XHTML documents and (critically) complete, efficient javascript engines.

Smartphone browsers will often present the average web page more or less acceptably. However, there are a lot of good reasons to present something different to smartphones and to desktop clients. The article lists some. For an excellent demonstration, visit espn.mobi in a smartphone (which automatically serves you the mobile version). Then, at the bottom of the page, click on the link that lets you visit the desktop version, and compare.

My opinion is that, if you're going to do device detection, it makes a lot more sense to develop a smartphone version than an iphone version. Even if the iphone is the most common smartphone now (at least in the USA), a large double digit number of smartphone internet users do NOT have an iphone OS device. And who knows what the mobile landscape will look like in a few years, when the websites you're making now will hopefully still be in use?

Please share your thoughts if you've been making mobile websites.

On a related note, if you want to learn about mobile webdev, this is video is an outstanding overview of the current landscape:

http://video.google.com/videoplay?docid=-6391025572807739271


Assuming your audience/customers use smartphones I would only have 2 buckets (otherwise just a):

a) Desktop browsers

b) Smartphone browsers

I don't bother supporting feature phones because if its anything more then a small piece of data like the weather then browsing the internet on feature phones (and some early Blackberries) is pointless.

The web based vs native app question depends on a few things:

a) Do you need to use built in smartphone features (camera, GPS etc)

b) Have enough money to invest in developing for multiple platforms? (or you could use Rhomobile for rails)

c) Need a device-specific UI in order to deliver the content in a useful way?

d) App needs to work outside of 3g/CDMA networks? (business critical?)

I believe that web based is the way to go for most cases and will continue to be a better option over the next few years as more smartphone browsers are on level with iPhone/Android. But if the answer to the questions above are yes then native is the best bet.


Re ignoring feature phones: Good point. Making a distinction between feature phones and smartphones gives us the choice to not support the former. At least in the USA, it's probably rarely worth the effort. (Don't know about other markets.)

Native is sometimes the way to go, for the reasons you mention. It's also AT LEAST an order of magnitude more expensive - especially for several platforms... It's good to see things like geo-location.js [0] taking shape.

cheers, thanks for the comments Aaron

[0] http://code.google.com/p/geo-location-javascript/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: