
Developing iPhone applications using Ruby on Rails - jmonegro
http://www.ibm.com/developerworks/opensource/library/os-eclipse-iphoneruby1/index.html?S_TACT=105AGX44&S_CMP=EDU
======
redsymbol
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>

~~~
dmix
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.

~~~
redsymbol
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/>

