Thanks. I think I can still get away with using GWT as long as I don't use any of the built-in layout panels, widgets, etc. I'll let you guys know how it goes.
On Aug 1, 3:29 am, Sebastian Rothbucher <sebastian.rothbuc...@clarities.de> wrote: > 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.
