my opinion on mobile web vs. rich
app development quite often, and
understandably so. For most mobile
developers, this is one of the very
first questions we face when we
begin planning to build an
application. And to be honest,
there’s really no “correct” answer to
the question. If I absolutely had to
break it down to a couple distinct
criteria, the decision would likely be
based on the following:
OS/Hardware-specific feature
requirements
Development budget
Development timeline
Target audience
Before I get too much further, I feel
I ought to explain that a vast
majority of my mobile development
experience has been with Android,
so you’ll likely find that most of my
examples revolve around it. With
that in mind, let’s carry on.
OS/Hardware-specific
feature requirements
HTML5 and native mobile browsers
are quickly getting to the point
where the gap is quickly closing
between what can be accomplished
from inside a browser vs. what can
be done from a native (rich)
application. However, there is still
one significant feature that separates
the two in my opinion: push
notifications.
I’m not very familiar with the push
notification system for iOS, but I
have implemented Cloud-to-Device
Messaging (C2DM) for Android
several times, and it is incredibly
useful for server-to-device
communication. You can use them
to get a device to “call home,” start a
process running on the device, or
even deliver a short message. The
only feature that comes close to this
in HTML5 is the WebSocket. But if
the user closes the browser, your
channel of communication is
severed.
Another reason why you might
choose to build a rich app is
because your requirements demand
a long-running service that persists
in the background. A background
service may be needed for indefinite
location tracking, device monitoring,
or lengthy calculations/processes.
One of the features I like most about
Android as a developer is the way
intents were designed. Intents allow
you to not only integrate other
applications into your own, but also
integrate your application into
others. A good example of the prior
scenario would be launching a thrid
party barcode scanner application
from within your own app and
receiving a UPC code back. As far as
the latter situation is concerned,
many apps will allow you to “share”
content with other apps, so it’s
possible to get your app to appear
in the list of possible choices (for
instance “sharing” a place from
within Google Maps). This unique
interoperability is definitely a very
strong case to build a native Android
application over a web app.
Development budget and
timeline
I doubt there are very many
developers out there who’d
disagree with me when I say that
mobile web development is grossly
cheaper than developing a native
rich app. Granted, 95% of my
development experience is web
development, so it’s fair to say that
it’s what I know best. However, the
fact that you can develop once and
automatically target every web-
enabled platform is quite a powerful
one. Compare this to developing,
say, an Android, iPhone, and
Blackberry app separately, and it’s
easy to see the advantage here.
As far as development timeline is
concerned, I don’t think I need to
say much more. Obviously
developing one web app is quicker
than developing multiple rich apps,
so let’s move along.
Target audience
OK, I’ll admit it. I’m an Android
fanboy. So when I first started doing
mobile development, I completely
neglected iOS and only focused on
Android. No wait, let me try that
again. I completely thumbed my
nose at iOS and all my iOS-using
friends. It didn’t take me long,
however, to realize that if I was
really serious about being a full-time
mobile developer, I simply could not
ignore one of the top two mobile
OSs, no matter how much I
disagreed with Apple’s philosophy or
believed in Android’s success.
So, the easiest and quickest thing for
me to do was develop a mobile web
site for my iOS-toting friends. The
result was actually quite impressive,
as I had created a nearly identical
copy of my Android app for the web
using webkit transforms via some
javascript I found/borrowed/
modified for my own purposes, to
create independently scrolling areas
(something that is not easy to
accomplish with mobile web).
At first, my peers were pleased that
they now had a way to use an app
they had been begging me to port
for months. But as soon as the
novelty wore off, they quickly
realized that the mobile web version
just wasn’t quite as slick as a native
rich app could be. Even though they
could create a bookmark on their
home screen to make it appear as a
native app, the differences were still
noticeable (namely the lack of push
notifications, which I get around by
sending emails).
Conclusion
Now I’ve presented a select few
arguments on both sides of the
case. Clearly there are a lot more
factors that go into this decision, but
I feel like the ones I’ve mentioned
have been the biggest determining
factors in my own personal choices.
There really is no right or wrong
answer at this point, and at the rate
the mobile tech industry is evolving,
everything I have just said may be
moot tomorrow.
As things stand today, I feel that the
best approach is to target both
mobile web and rich apps if all your
determining factors allow for it. But
this is clearly a subject that will need
consistent reevaluation as time
progresses. Eric Schmidt himself has
been quoted as saying “HTML5 is
the way almost all applications will
be built, including for phones” so
I’m confident in saying this is a topic
to keep your eye on.
On a final note, I encourage
everyone reading this article to
watch this video if the subject matter
discussed piques your interest. It’s
the Android vs HTML5 session from
Google I/O and I discovered while
writing this article that it was
uploaded to Youtube, as it was not
streamed live from Google I/O.
Hopefully I have answered a few
questions for you, and if not feel
free to sound off in the comments!
Published with Blogger-droid v1.7.2
No comments:
Post a Comment