| Members: 20544 |
| Language: English |
|
Group categories:
|
| More group info » |
|
| Aug 27 |
|
| Feb 28 |
|
| Feb 28 |
|
| Mar 19 |
|
| Feb 2 |
|
| Jan 24 |
|
| Jan 17 |
|
| Jan 17 |
|
| Jan 17 |
|
| Dec 4 |
|
It's now been a few weeks since the release of GWT 1.4 and Apple's iPhone.
We've spent some of that time learning how to optimize Google Web Toolkit
applications for the iPhone. Since nothing beats experience with real
code, we decided to write an application that we would find useful and that
shows off the cool features of the iPhone. The result is the
GWT
Feed Reader, an RSS feed reader that uses the
Google
AJAX Feed API with a user interface optimized for the iPhone. This article
will discuss what we've learned from writing this RSS reader.
Interface design decisions:
The iPhone has three primary UI gestures: tapping (or pointing),
swiping, and double-taps. Tapping is the primary command gesture,
analogous to a mouse click, and can be handled with standard
ClickListener.onClick()
events. Swiping, in both vertical and horizontal directions, is used to
pan the viewport over the (sometimes larger) virtual page. Element-per-Widget design:
The Document Object Model (DOM) specification defines a hierarchical box
model that is used to compose the image that is displayed on your screen when
you view a web page. Typically, web browsers convert the HTML data
received from a web server into a DOM structure, however it is also possible to
manipulate the DOM via purely programmatic means via client-side JavaScript
code. The GWT UI classes provide abstractions over the underlying DOM
structures that they represent, allowing you, the developer, to think about
high-level Widgets and Panels, rather than collections of DOM elements.
Each Widget has associated with it a DOM Element that represents the Widget in
the DOM. Simple Widgets, such as Button, can be represented by a single
DOM Element. Improving interactions: Both actual as well as perceived application performance are critically
important factors to consider when designing user interactions. If the
application pauses, hangs, or otherwise stalls during use, users will very
quickly become
frustrated.
Progressive (or lazy) rendering in the UI and retention of already-rendered UI
elements adds to the perception of responsiveness.
Applications
typically "feel faster" and annoy the user less when something happens
immediately in response to a user's event, even if it is to simply displaying a
"Loading..."
message.
Using
DeferredCommand.addCommand()
with an
IncrementalCommand
allows you to implement a "deferred Iterator". This will avoid blocking
the UI event loop while you create UI elements from a list of data
objects:
final
List objects = ....;
DeferredCommand.addCommand(new IncrementalCommand() { Iterator i = objects.iterator(); public boolean execute() { Foo foo = (Foo)i.next(); .... do something ... return i.hasNext(); } }); Robust use of GWT's History support adds to the usability of the application. The browser's back and forward buttons are always on-screen, so you may as well take advantage of them in your application. Most of the state changes within the GWT Feed Reader are controlled by history tokens. Instead of having user-generated events directly cause panels to be shown or hidden, the code simply executes a History.newItem() call. This ensures that externally-driven behavior (back/forward, deep-linking) is identical to UI-driven behavior and serves to decouple event-handling code from presentation code. For example, articles in a feed are viewed by setting the history token to a combination of the feed's URL and the link target URL of the article. See the processHistoryToken() function. Program data:
Minimizing the number of round-trips to the server was also a design
priority for the GWT Feed Reader application. We are using
ImmutableResourceBundle
and
StyleInjector
from the new
GWT
Incubator project. This combination allows program resources, such as
CSS and background-image files to be either cached "forever" or inlined directly
into the GWT application. The latter behavior allows the feed reader to
always be able to render correctly, even when the iPhone is temporarily unable
to access the Internet. Programmatic access to module
Resources
also helps in the development phase, because the compiler will warn you of
missing files. As an additional deployment optimization, the module
selection script has been inlined into the host HTML page as a post-build
step. The net effect of these optimizations is that the entire GWT Feed
Reader application and all of its runtime resources can be downloaded in just
two HTTP round-trips. Wrapping it up: After deciding on the UI layout style, implementing the RSS reader
application was just like writing any other GWT application. Much of the
gross feature set was worked out with hosted-mode development and then the
fit-and-finish of the application was finalized using a combination of Safari3
and an iPhone. Most of the time, the test application was accessed over
the EDGE network, to simulate the typical use case. Targeting the
high-latency, low-bandwidth configuration makes using the application on a WiFi
network even better.
|
| ||||||||||||||||||||||||||||
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2009 Google |