Web Toolkit Blog
The official source of information about GWT.
The enterprise (apps) in your pocket
Monday, October 19, 2009
When building great enterprise apps for our users many of us often first target the desktop user. Did you know that GWT lets you just as easily build great user interfaces for your mobile users?
Modern mobile phones such Android based devices and the iPhone ship will powerful web browsers which use the same Webkit rendering engine which GWT already supports and increasingly includes great capabilities like geo-location and offline storage.
Today's guest blog post is from Navin Kumar, CTO of Socialwok who has offered to share some of their experiences around building mobile apps for the enterprise.
If you have an enterprise story you'd like share please
send me an email
.
--
Google Web Toolkit (GWT) is a great set of open source tools for developing powerful Ajax-enabled web applications.
Socialwok
uses GWT on top of Google App Engine to provide a feed based group collaboration service for Google Apps users. GWT makes development more efficient, particularly for Java developers who work on both the front-end and the back-end. Since we use Java language support for Google App Engine, this is true for us. By using the Java programming language, GWT can make you more efficient in many other ways too. For example, after spending a couple of months developing the desktop web version of Socialwok, we developed the mobile HTML 5 web version in four days.
To see the desktop web version of Socialwok go to
http://socialwok.com/
and use any existing Google Apps domain email address to login.
Once you have created your socialwok network, you can now access the mobile web version by pointing your mobile web browser to
http://app.socialwok.com/
. Login using your google apps domain email address.
Here are a few pointers based on our experience in creating Socialwok's desktop and mobile web versions:
1. Think about the devices you want to support.
75% of iPhone users say they browse the web more often from their iPhone now more than they ever did before. 40% of them browse the web more often from their iPhone than their own desktop. Hence, it is important to have a mobile web version of your application for different mobile web devices like iPhone and Android. Socialwok mobile web version supports mobile browsers based on the Webkit codebase like the iPhone's Safari and Android mobile web browsers. The first step was therefor to fix the
user.agent
in our module's
.gwt.xml
file to speed up compile time by having GWT only compile the Webkit permutation:
<set-property name="user.agent" value="safari">
Of course, during development we enjoy GWT's quick edit-refresh-test model thanks to Development Mode (formerly Hosted Mode) which lets us test our code in a real browser while executing and debugging in Java.
Another thing to note is that with Mobile Safari on the iPhone and the Android Web Browser, you are now allowed to use webkit-specific CSS for mobile devices. This allows you to use native accelerations that include transitions, border images, as well as natively-created gradients. Here's an example of CSS used to create a native accelerated transition.
.menuPanel {
width: 100%;
\-webkit-transition: opacity 500ms ease-out 100ms;
}
Look for more info
here
. While the information is specific to the iPhone, the same rules do apply and work well on the Android browser as well.
2. Optimize for the screen that your users are using.
iPhone and Android devices use very powerful touch screen user interfaces. The user interface for all the iPhone applications is pretty well-defined; it involves a navigation header at the top, the content in the middle, and maybe a footer at the bottom. If you're thinking in GWT widgets, you should be thinking
VerticalPanel
or
FlowPanel
. These are the widgets of choice for the mobile web GWT developer.
Screen real estate on mobile phones is precious. You have to optimize the amount of visible content on the screen. Try to make things "expand" when you click on them. For example, in Socialwok, when someone clicks a post from the listing screen, a new screen is given to the user with only the single "opened" post that lists all the attachments, comments, and other pieces of information right there.
Unlike the desktop version, instead of one single widget for the feed item, we need one widget for the feed listing, and one "feed item" panel, that contains the single update along with the corresponding comment thread.
Finally, understand that your users are looking at the mobile as a "complement" to your desktop version.
While they might end up using the mobile version more often, they expect it to mirror the desktop interface in basic ways. This is actually great because you have already developed your widgets using Java, and porting them to the mobile is only a matter of changing CSS classes, and removing a few unnecessary UI elements.
3. Share as much code as possible between versions.
This is the most important reason why mobile development can be done rapidly. All of GWT's HTTPRequest, marshalled
JavaScriptObject
, and other non-UI code is shared between the mobile web and desktop web versions. This concept is important in general for any GWT application that uses multiple EntryPoint modules. The great thing about this is that the Java programming language makes this possible by it's own definition. OOP developers tout code sharing all the time, and you should follow their advice nonetheless.
This page
in particular is very useful to understanding how to organize your GWT code.
I hope the above pointers help you get started on desktop to mobile web development on GWT. For more information on Socialwok and GWT, check out Google's developer
GWT profile on Socialwok on YouTube
.
Finally, here are some useful classes and libraries you can use for GWT mobile web development:
ImmutableResourceBundle
- A great set of tools that was started in the GWT incubator project but has now made their way in the mainline GWT trunk development (soon to be known as
ClientBundle
). ImmutableResourceBundle is the followup to the great ImageBundle interface. Both seek to reduce greatly the number of round-trip times used by browsers to download cacheable resources such as images, CSS, and other resources. The mobile browser is even more limited than the desktop browsers when it comes to downloading simultaneous resources, so the use of
data:
URLs and
CssBundle
are used heavily by the mobile version of Socialwok.
FlowPanel
- Unlike desktop browsers which are more optimized for
tags that GWT uses for its CellPanel-based layout controls, mobile browsers like Safari and the Android browsers perform much better with
tags. Layouts also seem to be more predictable with these tags than the others on the mobile phone.
GWTQuery
- Ray Cromwell's excellent port of JQuery to GWT provides most of the JQuery functionality to allow you to modify CSS, and perform other actions with ease. In the case of the mobile web interface, there are times when it is definitely necessary to modify CSS dynamically, and this library will make that process much easier on you as a developer.
GWT Google APIs (Gears)
- Google Gears is a browser plugin installed in the Android Web Browser used to provide extra functionality, particularly offline support which is very import for mobile browsers which don't always have a permanent connection. Google provides a GWT library that can be used to access the Gears plugin.
-- Navin Kumar, CTO, Socialwok
Building Enterprise web apps in the cloud
Thursday, October 08, 2009
An important decision to make when building a web application is how to coordinate state between client and server. This includes how to create appropriate representations of your data to
send over the wire
.
There are many possible approaches. I'd like to present a straightforward one from Jerome Breche, CEO of TimZon, who was kind enough to share it with us today.
When we started our first GWT project (
TimZon.com
), we found out that one of the major benefits of using GWT is its ability to transfer complex object data structure between client and server through the
RPC mechanism
. So when we initiated our second project (
SnapABug.com
) combining GWT and
Google App Engine
, we were very excited by the prospect of passing datastore objects directly though RPC.
We quickly realized that this is not very practical. First one of our
JDO
objects includes images binary representation that we wouldn’t want to communicate through RPC. And then while making the JDO class serializable for GWT RPC may seem like a simple task, it created all kind of new problems since the JDO class will have to be configured as transient (using
detachable = "false"
) and we would still need to copy the object when passing it through the RPC. Instead we decided to simply create intermediary classes for the data objects used only for RPC communication. This way we can exactly control and optimize the data payload used by the RPC both for size and speed. On the JDO side, we simply created a getter and setter function to translate the JDO data into an RPC data format.
Here is an example of how this works in client side code.
1.
Employee
class: contains JDO objects definition and getter and setter to translate them to GWT RPC serializable format
@PersistenceCapable(identityType = IdentityType.APPLICATION) public class Employee {
@PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) private Long id; @Persistent private String name; @Persistent private String email; @Persistent private Blob image; /**
* Constructor * @param name * @param email */ public Employee(String name, String email) { this.name = name; this.email = email; } /** * Set Employee from RPCDataEmployee */ public void setRPCDataEmployee(RPCDataEmployee employee) { name = employee.name; email = employee.email; } /** * @return Employee data in RPC format */ public RPCDataEmployee getRPCDataEmployee() { RPCDataEmployee employee = new RPCDataEmployee(); employee.name = name; employee.email = email; return employee; } }
2.
RPCDataEmployee
class used by GWT RPC calls
public class RPCDataEmployee implements IsSerializable {
public String name; public String email; // Note: image Blob not included in RPC payload }
Here is an example of how this works in the server
3.
RPCDataEmployee
server service implementation
public RPCDataEmployee getEmployee(String email){ RPCDataEmployee employee = new RPCDataEmployee(); // create data store connection PersistenceManager pm = PMF.get().getPersistenceManager(); // query datastore to get emmployee data String query = "select from "
+ Employee.class.getName()
+ " where email == "
+ email;
List
employees =
(List
) pm.newQuery(query).execute();
if (employees.size() == 1) { // record found employee = employees.get(0).getRPCDataEmployee(); } else { // do something else... }
pm.close();
return employee; }
While I am sure there are many other ways to achieve a similar result, maybe even avoiding duplicating the data classes, this solution was the easiest for us to get going quickly, keep our code very maintainable and control the amount of data exchanged between client and server.
There is also a very interesting
discussion
about this subject on the GWT Google Group.
-- Jerome Breche, CEO & Founder of TIMZON, LLC
If you would like to share your experiences with GWT and Google App Engine, either privately or on this blog, I'd like to
hear from you
.
Making AJAX Crawlable
Thursday, October 08, 2009
At the recent
Search Marketing and Expo East Conference
(SMX) several members of the Google Web Toolkit team delivered a presentation on making AJAX enabled web apps crawlable. This presentation included a proposal that is currently in the works which aims to solve the fundamental problem that it is difficult to index AJAX enabled web apps and therefore their searchability suffers. If you care about SEO in your GWT apps, check out the post on the
Google Webmaster Central Blog
and
let us know your thoughts
.
GWT helps developers innovate in the enterprise
Monday, October 05, 2009
I had an opportunity to sit down with
TechCrunch50 Demopit winners
and creators of
Socialwok
, a cloud based application which mixes
Google Apps
and a unique set of social capabilities to make their customers more productive, both at their desks and on the road via their mobile web client. They chose
Google App Engine
for scalability and hassle free web hosting and
Google Web Toolkit
to maximize their productivity so that they could focus on creating a great web experience for their users. You can watch the interview
here
.
Labels
accessibility
1
crash
1
dev mode
2
English
172
googlenew
1
gwt
1
IE
1
internet explorer
1
Web Toolkit Blog
172
Archive
2016
Oct
2014
Dec
Nov
Sep
May
Jan
2013
Nov
Oct
Jul
Mar
Feb
2012
Dec
Oct
Sep
Jul
Jun
Jan
2011
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Feb
Jan
2007
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2006
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Feed