Mobile Phone permutation strategy suggestions wanted

Hey all.

I'm going to be using GWT for some mobile phone web applications. My
company primarily makes Java desktop applications and wants web
versions of several of those applications. There's another group here
that's already using GWT for web apps but they're not concerned with
mobile phone browsers, so it's best if we use GWT since most
developers at our company are familiar with Java and GWT's already in-
use in the company, even if we end up ignoring several features in
cases where we need mobile phone support.

I'm using progressive enhancement (meaning the pages need to work with
JavaScript turned off), and we really can't use most of the built-in
layout or widgets because of our platform targets and the fact that
JavaScript support may be non-existent or sketchy. I'm fine with
building new widgets that work in everything we're targeting and do as
much as they can without JavaScript while having nice behaviors added
on with JS. The same widgets should work very well in full-featured
browsers as well since we'll just be layering behavior on top of them.

However, I'm wondering what to do about the permutations. For the
desktop environment, having permutations such as IE6, IE7&8, Firefox,
Safari, Chrome (or even, say, Webkit, Gecko, and various flavors of
IE) make complete sense, but as quickly as the mobile space is moving
that doesn't make as much sense to me. I understand the benefits of
deferred binding, and agree that it's crazy awesome that you can get
download sizes so small and run-times so snappy when compiling to each
platform, but I'm not sure how plausible that is when we're needing to
support things like Blackberry 4.6, 4.7, 5.0, NetFront, the various
Nokia Webkit flavors that aren't quite as fully featured as iPhone/
Android's version of Webkit, etc. Object/feature detection seems like
a much better call when you're faced with that many flavors of
browsers.

Would it make sense to do permutations for the more modern browsers,
then do a catch-all for everything else and still use object/feature
detection in that path? Using object/feature detection for our
permutations would probably be a nightmare, as once you start testing
for, say, 100 different features that way then GWT is having to do an
astronomical number of compiles to allow for all of the different
combinations of features. Also, while the desktop ecosystem is
somewhat stable, the mobile ecosystem is currently refreshing much
more quickly. I don't want to walk us into a situation where we're
having to touch our apps every 6-8 months when the new crops of phones
come out.

I guess we could still get benefit from everything else GWT does (the
wonderful compilation, minification, etc.) and still use object/
feature detection throughout the app and just not even worry about
deferred binding/bootstrapping, but I thought I would ask the GWT
group for your thoughts as some of you may have had to consider this
problem before and may be able to offer some insight.

Thanks!

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.