Build Web Apps, Not Smartphone Apps
If you built an application for the iPhone 4, for
example, and you needed constant access to a data source, how would you handle
the iPhone's reception problems? Or how would you handle the demise of the many
Android platforms that will take place in the next few months as new versions
are launched?
In reality, there are two approaches you can take to stay
out of trouble. The first is to support more than one smartphone environment.
Sure, it's kind of a pain to develop for both the iPhone and for Android
devices, and it's more of a pain if you also have to develop for WebOS and for
BlackBerry devices. But the goal is to make sure that you can use your
smartphone for the benefit of your enterprise. That means making sure that your
important mobile business applications will always run, even if it requires
supporting multiple models.
Perhaps a better approach, however, is to support your
enterprise's needs with Web-based applications. You'll still have to deal with
issues such as reliable reception, but at least you won't have to write a new
application every time a hardware platform gets upgraded.
Most smartphones support fairly decent Web browsers these
days, and as long as you can detect what browser you're serving, you can make a
point of avoiding things that don't work, such as Flash for users with iPhones.
The only real limitations then are the small screen size of some devices and
delays in delivering multimedia information in areas with poor reception, and
those issues can be handled with proper design.
But it's important to note that the best plan is not to
decide that you're going to support a single platform, and work from there.
Single platforms have a way of going away with little warning. While some
smartphone companies are better than others when it comes to helping you with a
transition, your real goal is to make application transitions on your own schedule,
not on Apple's, Motorola's or Palm's.
To ensure application stability and continuity, you have
to start with the assumption that the smartphone you're currently designing
your applications for will probably not exist by the time you've finished. So
instead of locking yourself into a single set of features, plan for a steady
and rapid pace of change so you can be ready when it happens.








