Hi Falcon,
when turning off JavaScript is criterion, using GWT will become
virtually impossible: all of the client-side logic with GWT is JS
only, so running it on e.g. current blackberries will be a hard
job...
It's supposed to work quite well on andorid or iPhone (the webkit-
enabled phones - probably on the Blackberry 6 as well then), but I
guess it will become hard without JS.
Hope this helps - best Regards
Sebastian
On 29 Jul., 23:36, Falcon <msu.fal...@gmail.com> wrote:
> 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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
