Back in October of this year we released GWT 2.1, with a framework and set of tools that made it easy to build business web apps. Since then we've had some great feedback from the GWT community, and today we're happy to announce that we've incorporated that feedback into our latest release, GWT 2.1.1. The specifics of this release are detailed below, but if you're interested in getting started you can do so here.
For Eclipse users, simply click on the “Google updates available” icon in the lower left hand corner of your screen, or select the “Help->Check for Updates” menu item.
Alongside this release, we’ve also updated the Google Plugin for Eclipse and GWT Designer. Both can be installed via the links below.
The main release updates for each product include:
GWT SDK
GWT’s RequestFactory component, introduced in GWT 2.1, received a lot of attention, both from the GWT team at Google and from the GWT open source community at large. Based on this feedback, we’ve added the following:
If you have questions or want to provide some feedback, we’d love to hear it, and the best place to do so is in the Google Web Toolkit Group.
For those of you that are diligently testing the bounds of the web, you may have noticed some issues when debugging GWT apps within Internet Explorer 9. Even though IE 9 is still in a pre-release phase, we did want to provide some context around the root of the problem, and offer up a workaround to get you working in Development Mode again.
Note that this is only an issue when running your GWT app in Development Mode under IE 9. Production Mode is unaffected.
For some background, there appears to have been a change in behavior in IE 9 related to the way Javascript names are resolved from the perspective of native plugins. When executing in document mode 9, the IE tab that hosts the dev mode plugin crashes.
We are working with Microsoft to understand the issue and come up with a definitive solution. Again, note that this issue affects only GWT Development Mode.
The current workaround is to avoid document mode 9. See the link below for more information.
To force an earlier document mode, add a meta tag to your html files indicating a different document mode. For instance, in the case of the sample GWT app html page, add <meta http-equiv="X-UA-Compatible" content="IE=8" /> to the <head> section as shown below:
Until this issue is resolved, you will need to do this for each HTML host page in order to use GWT dev mode with IE9.
One of the features that makes GWT unique is the ability to run your application in the browser of your choice, and debug your Java source in the IDE. While the “browser of your choice” portion of the feature has been quite true for Windows users, our Developer Plugin support has had some gaps. Today we’re happy to close some of these gaps, by announcing the release of a Chrome Developer Plugin for Mac and Linux users.
To download and install the new plugin, simply start debugging your GWT application and point Chrome at the URL provided by the Google Plugin for Eclipse. From there you’ll be prompted to install the “GWT Developer Plugin for Chrome”.
You can also browse directly to the following URL for installation: http://gwt.google.com/missing-plugin/.
In addition to the new OS support, there is an important security fix included in this update. You will see the GWT icon appear in your browser bar when the plugin sees the ?gwt.codesvr fragment in a URL, and it will turn black and white if you need to authorize that host. If you see a full-color icon, that indicates your permissions are in order. You can click the icon to quick-jump to the permissions configuration.
Note to Windows users: we have created a new permissions UI that is baked into the extension rather than using native Windows dialogs. You will need to re-add any hosts you had configured for this new version.
For more information regarding security and the GWT Developer Plugin, checkout the plugin design wiki page, here.
If you have questions or want to provide some feedback, we’d love to hear it, and the best place to do so is at the Google Web Toolkit Group.
For several months now, we’ve been hard at work adding the features and functionality that was first demoed at this year’s Google I/O. The goal of this release has been to make it easy to build business oriented web apps that can take full advantage of the cloud -- zero deployment, instant scaling, cost savings, and portability that allows you to run your app in a variety of cloud environments, such as Google’s hosted service, App Engine, and VMware’s on-premise solution, vFabric. A few weeks ago we mentioned that we were close to wrapping up this project, and today we’re happy to announce the general availability of these tools.
Download the Google Plugin for Eclipse or SpringSource Tool Suite to get started now!
Google Web Toolkit SDK
If you’re looking to start building apps using the Spring Roo and SpringSource Tool Suite integration, the quickest way to start is by downloading SpringSource Tool Suite and installing the Google Plugin for Eclipse from the main Dashboard component.
Once downloaded, simply start up Roo’s command line interpreter, and run the “script expenses.roo” command.
This will run a series of Roo commands that produce the following starter web app:
Now that we’ve created our app and launched it from the command line, we can import it into STS to start customizing it. To do this switch back to STS and click the menu item File->Import, and then select “Existing Maven Projects”.
Once imported you can now run your app directly from STS by right clicking on the project and selecting the “Run As->Web Application”
From there you can start customizing it using our GWT Developer Guides and Roo documentation to help you along the way.
For a complete “Getting Started” guide, be sure to checkout Getting Started with GWT, Spring Roo, and SpringSource Tool Suite.
As you may be able to tell by the list of available product updates, this release has been the culmination of work of several teams. Thanks to the VMware and Spring engineers (Ben Alex, Christian Dupuis, and teams) for working with us to create a seamless and integrated developer experience. And to the developers that have been riding tip of trunk for the past few milestones, submitting questions, issues, and patches, thanks. It wouldn’t be a success without you.
Want to get started? Please download the Google Plugin for Eclipse now! You can jump right in with the Getting Started with GWT 2.1. docs. GWT 2.1 is also available in Maven Central as version 2.1.0.
If you’re interested in receiving updates about existing Google Developer Tools as well as those that are about to be launched, sign up here!
Earlier this year at Google I/O, we announced a collaboration between Google and VMware focused on making it easy to build business-oriented, cloud portable web apps. We showed how businesses could use our integrated developer tools to build modern web apps that are “cloud ready” from the start, and can be deployed to any standard environment, including Google App Engine and on VMware vFabric on-premise solutions. Today we are happy to announce that these tools will be generally available within the next few weeks.
Of course, if you’re itching to get a head start, you can jump right in by downloading the release candidate (RC1) versions of the tools. The easiest way to get the entire tool set is to by downloading SpringSource Tool Suite RC1.
If you’d prefer to wait for the general release, you can sign up here to be notified as soon as they are available.
Spring Roo and Google Web Toolkit - Spring Roo, a next generation rapid application development tool, combined with the power of Google Web Toolkit (GWT) enables developers to build rich browser apps in enterprise production environments. These GWT-powered applications leverage modern browser technologies such as AJAX and HTML5 to create the most compelling end-user experience on both desktops and mobile browsers.
Spring Insight and Google Speed Tracer - Google’s Speed Tracer with VMware’s Spring Insight performance tracing technology enable end-to-end performance visibility into cloud applications. This integration provides a holistic view into the web application performance, improving the end-user experience by optimizing the client side as well as the server side.
SpringSource Tool Suite and Google Plugin for Eclipse - The integration of SpringSource Tool Suite and the Google Plugin for Eclipse makes it easy for developers to build and maintain large scale, web-based, enterprise applications, putting tools that were previously only available when building desktop and server solutions in the hands of those building cutting edge web apps.
Moving forward, both teams are excited about the strides we can make in the mobile web app space. As it stands today, the current technology stack makes it possible to create optimized web apps targeted for the mobile browser. Longer term, we will be looking at incorporating mobile best practices, styled UIs, and HTML5 features such as app cache, local database storage, and geolocation to make the developer and end-user experience first class.
As always, we’d love to hear your feedback and thoughts on this release. Our GWT developer forum is the best place to post this information. Happy coding!
By Brad Abrams, Google Developer Team
A new article on the GWT articles site discusses some of the benefits of hosting a GWT app in a dynamically generated page vs. static HTML.
Using a Dynamic Host Page for Authentication and Initialization
Building on the three previous milestones, we're happy to announce the first release candidate (RC1) of GWT 2.1. While we're still focused on the overall theme of making it easier to build cloud portable business apps via some help from our friends at VMware and Spring, there are more than a few aspects that make this milestone a RC.
First we've rounded out the list of components and features that will ship with GWT 2.1. One of these components is a new Editor framework that allows you to bind your DTOs to a customizable UI which handles all of necessary grunt work of validating and syncing change sets. Another is the availability of the SafeHTML component and its integration within the cell-based widgets. After all, we've optimized these new widgets by injecting HTML, we better do it in a secure manner.
Along with the new components and features, we've solidified the Activities/Places, RequestFactory, Editor framework, and Cell-based widget APIs. So, if you're looking to start a project with GWT 2.1, you can feel confident that your team won't have to refactor code because we've switched out interfaces between now and the final release.
Also, if you're looking to get started with GWT 2.1 we have an initial draft of the new Developer Guides. These can be found at the links below (the Editor framework Developer Guide is coming soon).
As with previous milestones, to get the full effect, you'll want to pick up the Spring Roo RC1 and SpringSource Tool Suite RC1. Ben and Christian from the SpringSource teams have been hard at work adding features and functionality, and it's great to see that we're all very close to the final release.
GWT 2.1 RC is available on our Google Code download site and as version 2.1-SNAPSHOT in the Google Maven Snapshot Repository. We’d love to hear your feedback and thoughts on this release, and our GWT Developer Forum would be the best place to post this information.
In early August, Google acquired Instantiations, a company known for its focus on Eclipse Java developer tools, including GWT Designer. We're happy to announce today that we're relaunching the following former Instantiations products under the Google name and making them available to all developers at no charge:
Now that these products are available again, we hope you’ll start using them within your GWT projects. Meanwhile, our next step is to more deeply unify them into the GWT family of tools by blending the fantastic Instantiations technology into the Google Plugin for Eclipse (GPE). So, there’s much more to come, including things we’re pretty sure you’ll like, such as UiBinder support in GWT Designer.
You can download any of the tools from the GWT download page. If you have questions or comments we’d love to hear from you. The best place to discuss the tools above is at http://forums.instantiations.com. As always, continue to discuss GWT and GPE at the main GWT Group.
We would love to stay in better touch with you as we have more news about how we are integrating the Instantiations products into the Google Web Toolkit suite. Sign up if you’d like to receive email updates on these products and other developer tools.
By Bruce Johnson, Google Developer Team
<repository> <id>google-maven-snapshot-repository</id> <name>Google Maven Snapshot Repository</name> <url>https://oss.sonatype.org/content/repositories/google-snapshots/</url> <snapshots> <enabled>true</enabled> </snapshots> </repository>
Back in May, at Google IO, we announced an integration between VMware’s popular Spring framework for server-side development and GWT for the client-side. Since then we have been excited by the feedback and comments from customers building real world apps with this technology. In response to their feedback, and pushing towards delivering on our our promises form IO, we are very happy to announce release M3. Looking forward we expect our production quality, GA (general availability), drop to land in a few months.
Some key features included in this release are built-in history support in Activities and Places, relationship management within RequestFactory, and the ability to call instance methods on entities themselves. The overarching goal was to nail down the API and deliver on features and functionality that are vital to creating industry-grade business apps.
For the Spring Roo community, we're continuing to build-out the integrated stacks that we announced back at Google I/O. GWT 2.1 M3 includes a parallel Roo 1.1 M3 that will allow you to take advantage of all the features mentioned above. Also, in the spirit of co-operative and transparent development, you can find a full list of features and functionality over at Roo's issue tracker.
GWT 2.1 M3 is available on our Google Code download site. We’d love to hear your feedback and thoughts on this release, and our GWT Developer Forum would be the best place to post this information.
I'm pleased to announce that the GWT 2.0.4 jars are now available in the maven central repository. Better maven support has been frequently requested on the issue tracker and mailing list, and this is a first step in that direction. In the future, Google will publish GWT releases to maven central as part of the release process.
The GWT 2.0.4 jars currently in the repository include gwt-user, gwt-dev, and gwt-servlet. Please note that gwt-soyc-vis as a separate jar has been deprecated and soyc (story of your compile) is now bundled with gwt-dev.
Would you like to have unit tests for your server code which exercise the same call sites which are used by your users? Would you like to do batch processing using these same RemoteService APIs, without having to drive a web browser? If so, this article is for you. Jeff McHugh, from Segue Development, has offered to share his work, which builds on the RPC capabilities that ship with GWT.
If are you currently working with GWT and require serialization, this article might be a great interest to you. GWT RPC is an API provided by the GWT SDK that makes client/server communication easy to implement and support. I developed GwtRpcCommLayer, a library that sits on top of of GWT RPC, that:
This post will explain how GwtRpcCommLayer makes this possible. The entire codebase is available for download and can be used with your GWT projects.
As you already know, the GWT SDK contains a very powerful serialization mechanism that can be easily leveraged to make AJAX RPC calls. This serialization mechanism is called GWT RPC. The API reflects the overall spirit of Java's RPC mechanism, which allows you to call remote objects' methods just as if they were running within the local JVM. In either case, there's no need to handle any of the marshaling/un-marshaling (serialization/de-serialization) details. That is all taken care of by the underlying framework of the API.
What makes GWT RPC so powerful is that it enables Java developers to be more productive, by allowing them to stay grounded with their existing implementation model, i.e. no conversions to and from JSON, XML, CSV. If you already have objects in your model such as UserAccount, LineItem, etc., you don't need to spend the extra effort building a mapping to and from JSON or XML.
Taking advantage of GWT RPC requires no additional libraries outside of the standard GWT SDK, and it is straightforward to use, making it a great solution for serialization.
My extension to GWT RPC takes advantage of the underlying foundation of how GWT RPC is designed, but swaps out the standard GWT “serialization engine” with one that uses simple Object serialization via java.io.ObjectStream.
The design of the code-base is naturally separated into two distinct parts:
The following requirements were part of the design goals when I started working on the project:
All three of these requirements were met, which will hopefully encourage developers to not only try this library out for themselves, but perhaps even contribute to the development of further enhancements and functionality.
The basic premise of the design follows the same design pattern used by GWT RPC, but instead of using a delimited/ASCII format, I simply swapped that out with Java's standard Object serialization. Since both GWT RPC and Java RPC mandate that Objects intended to be serialized must implement the java.io.Serialization interface, the process was straightforward.
Additionally, I took took advantage of the Java Reflection API which allows for runtime compilation of “proxy” classes. Using reflection, it is possible to shield the developer from any awareness of the “serialization engine”, which satisfied one of my three requirements: purity of syntax.
Below is a very basic diagram of (#1) how the GWT RPC interaction works and (#2) how the GwtRpcCommLayer interaction works. Keep in mind that from the developer's point of view, nothing changes in terms of how the code executes, both on the client and server side.
In order to take advantage of GwtRpcCommLayer, you can choose one of two options. Both options work well. The choice comes down to style more than anything else.
Create an instance of GwtRpcCommLayerServlet in your web.xml file. Specify your own servlet as an initialization parameter:
<servlet> <servlet-name>GwtRpcCommLayerServlet</servlet-name> <servlet-class>gwtrpccommlayer.server.GwtRpcCommLayerServlet</servlet-class> <init-param> <param-name>GwtRpcCommLayerServletImplClass</param-name> <param-value>example.server.GreetingServiceImpl</param-value> </init-param> </servlet>
Choose option 1 if you don't want to alter your servlet classes.
Servlet classes which extend com.google.gwt.user.server.rpc.RemoteServiceServlet should instead extend gwtrpccommlayer.server.GwtRpcCommLayerServlet. Since GwtRpcCommLayerServlet itself extends RemoteServiceServlet, all the same methods are available to your servlet and your server code will continue to operate normally. Upon review of the associated source code, you will observe that the main service method has been overridden to provide branch logic to handle both normal GWT RPCs and the newly supported GwtRpcCommLayer RPCs.
Client implementation is simply a matter of instantiating a “proxy class” and making the same remote service calls your client code would normally make. Here is a simple example:
//STEP 1: create the URL that points to your service/servlet URL url = new URL("http://127.0.0.1:8888/example/greet"); //STEP 2: create an instance of GwtRpcCommLayerClient GwtRpcCommLayerClient client = new GwtRpcCommLayerClient(url); //STEP 3: ask the client for a reference to the client-side proxy of your remote service GreetingService stub = (GreetingService) client.createRemoteServicePojoProxy(GreetingService.class); //STEP 4: any call you execute against this proxy will ultimately execute on your servlet String echoResponse = stub.greetServer("hello world");
As you can see from the above fictitious service, it only takes 3 lines of code to gain access to your remote service and it will behave just as if these were regular GWT RPC calls.
It’s been a busy week for the GWT team. We released an updated GWT Gadgets library, GWT 2.0.4, and to cap things off pushed the second milestone release of GWT 2.1 today. In this milestone we simplified the process of configuring a RequestFactory, made record creation within a RequestFactory more extensible, and properly moved ourselves out of bikeshed. A full list of features and fixes can be found here.
With the release of GWT 2.1 M2, we’re continuing to evolve the integration between Google and VMware that was announced at this year’s Google I/O. Each milestone release of GWT, Spring Roo, and STS fleshes out more of the envisioned feature set, and overall stability of the stack.
GWT 2.1 M2 is available on our Google Code download site. We’d love to hear your feedback and thoughts on this release, and our GWT Developer Forum would be the best place to post this information.
Recently Apple released Safari 5, which included a bug where non-integral right-shifts were not being evaluated properly. There were several reports, both internally and externally, of GWT-based applications unexpectedly crashing when running in Safari 5 (including Google Wave). Upon further inspection of the crash, we determined that the bug is triggered when calling several of GWT's array sorting methods, which in turn perform non-integral right-shifts as part of the compiled code.
That's the bad news. The good news is that we have a fix for this issue, plus several other house keeping items that we've rolled into a 2.0.4 release, which can be downloaded from GWT’s main download site.
If you’re experiencing the Safari crash, you’ll need to recompile and deploy your GWT app. The changes in 2.0.4 are completely compatible with your existing 2.0 app, and should have no negative impact. To that extent we’ve already dogfooded 2.0.4, verifying that it fixes the Wave crash that was originally reported.
Although its only been a few weeks since the previous release of the open source gadgets library for Google Web Toolkit (GWT), a major overhaul to the gwt-gadgets project has been underway and we are excited to announce that these changes are ready to be released as gwt-gadgets-1.2.0.
Gadgets allow a developer to create applications that can be embedded in another website. Sites that support gadgets include iGoogle, My Space, Orkut, Linked In or Google Wave. These sites all adhere to the Open Social Foundation specifications for gadgets and the Open Social API. This release incorporates the following features into the GWT bindings:
We would like to recognize Hilbrand Bouwkamp for helping update the GWT-RPC support in the library. Hilbrand is the author of cobogwave which adds Google Wave specific support for GWT based gadgets.
This new release is now available for download at Google Code
The Google API Library for GWT Team
Update: Patrick Chanezon, Google Developer Advocate, has supplied us with a video interview with Matthias, which can be found here.
Today's guest blog post comes from Matthias Büchner, Software Engineer at digital security company, Gemalto along with his colleagues: Colin Gormley, Jonas Pärt and Ella Segura. Here they discuss their Device Administration Service, and the recent port to GWT.
Introduction
The Device Administration Service (DAS) solution allows you to manage the personalization and lifecycle of smart card devices. It was developed using ASP .NET and native JavaScript as a hosted web application. Our team was asked to port the solution for deployment as both a hosted and an offline standalone system.
We had three major goals for the re-design:
Here was our strategy:
GWT was the obvious choice. It addresses all the goals we had outlined, plus we really looked forward to writing Java code again after living and breathing complex native JavaScript for so long. The prospect of using JUnit had us practically salivating. In this article, we will discuss how we designed our application with GWT and give a few tips that we learned while developing it.
A Smart Card Driven Architecture
A smart card is a secured electronic chip typically embedded in a plastic card or inside a USB dongle. Two examples of what a smart card can do are managing physical and logical access, and securing electronic transactions. Despite their small size, they offer a self-contained operating system and can run very advanced applications. The card is connected to the PC using a smart card reader and the low level communication between the reader and the smart card is done via an APDU.
Traditionally, you are required to install some platform-specific software on your computer before you can communicate with a smart card. This software is known as middleware, and typically takes up a large footprint and must be developed for specific environments. Gemalto developed a browser extension, called SConnect™ , which allows communication with a smart card using JavaScript. SConnect is available on most major operating systems and browsers. SConnect™ is to the smart card what AJAX is to the web. SConnect communicates asynchronously with a smart card, eliminating latency problems on the user interface. We anticipated that this feature would have a strong impact on our design approach.
We investigated the GwtEvent class and its callback mechanism to manage the asynchronous communications. An event is fired just once, and it is handled by one or more handlers. The one-to-many model fits perfectly with how we wanted to manage the notification mechanism when the card is either inserted or removed from the reader. We created card insertion and removal events and utilized an event bus to manage the event firing. Unfortunately, we found difficult to follow and debug event-driven code.
Callback mechanisms are better suited for one-to-one relationships between the callers and the callees. We opted to use callbacks to manage most of the business and low level logic, since they are mostly one-to-one relationships.
When several callbacks, that required data sharing, were chained in sequence things got a little ugly. We started with nested callbacks. As you can see in the AsyncCallbackExample class, the code flow can be difficult to follow and decipher. To solve the problem, we created the following Wrapper class. This class allows us to create a final instance of the data we need to share. Separate callbacks no longer had to be nested to access and change the data we are passing around.
public class Wrapper { private T value; public Wrapper() {} public Wrapper( T value ) { this.value = value; } public void setValue( T value ) { this.value = value; } public T getValue() { return value; } }
This class allowed us to improve the readability and ease the maintenance of our code. You can see in details how to use it in our class example.
Rebuilding the User Interface
Our goal was to move all our source code to Java/GWT; this includes the entire user interface that was designed originally with ASP controls. We looked for an existing widget library since we did not want to spend a lot of time developing custom components. ExtJs GWT was a library that some of us were already familiar with, so it was a natural choice.
From a bird's eye view, most of the interface looks the same. Take a closer look, and you'll find that much of the details have been improved.
Data are loaded and updated asynchronously. Status messages and popup dialogs are now more like a desktop application. One of our goals was to keep the source code modular and easy to maintain. We were all excited at the prospect of writing code in a single language. The benefits of moving from source code written in ASP .NET + native JavaScript + CSS + HTML to Java are many. We especially were attracted to compile time checks, unit tests and writing all our code in a professional IDE.
We knew we wanted to structure our code in a way that would allow us to decouple the interface from the business logic. The video from Google I/O 2009 on best practices for architecting GWT app pointed us in the right direction. We adopted the MVP pattern and divided our UI code into presenters and displays using the gwt-presenter library.
In the DAS application, there is more than one presenter at work on any single screen. We needed the presenters to interact with each other but did not want them too tightly coupled. To address this issue, we brought in the event bus. Instead of presenters listening to events being fired by other presenters, now everyone alerts the event bus when something significant happens and registers themselves to the event bus for any events they are interested in.
The DAS application is currently localized for three languages. Implementing the Constants and Messages interfaces was very straightforward. We put all the text in an Excel spreadsheet for delivery to our translators and converted it into Property files.
We hit a small bump in the road when we realized that GWT does not take language settings of the browser into account for localization. You have to pass in ?local=xx in the URL when launching the application. To solve this problem, we had to take two approaches. For the hosted solution, we can easily parse the request header for language information and pass that into GWT using the Meta tags. For the standalone solution, where we cannot send any HTTP request, we settled for reading the system language settings from JavaScript and passing that information into GWT.
A Testing Strategy
There is a consensus in the developer community on the great benefits that unit tests provide. Unfortunately there is no good JavaScript unit test framework. In the ASP .NET version of the project, validation was done manually. A device configuration issue or similar problem would put the result off its intended target. Achieving measurable test coverage was not possible. Porting our application to GWT helped solve this problem. We just lost our last argument for not writing unit tests.
One aspect of the DAS user interface which is different from traditional web applications is that we have to interact with a smart card. Almost every function of the application requires a smart card to be inserted and some features require two smart cards. The smart card itself is a difficult device to test, it needs to be inserted into a smart card reader and much of the website is driven by smart card removal and insertions. Automating the device would require some sort of smart card or reader emulator that would trick the system into believing that the device was inserted. The technology involved is very low level, and emulating the interface is not a trivial task. We had to look for another solution.
Here is an overview of our application architecture.
We abstracted the Smart Card Layer to mock device interactions to higher layers and kept some of the manual (or semi-manual) tests for the lower layers. It divided out tests into two categories; unit tests and integration tests. Unit tests would use mocked Smart Card layer while the integration tests would require real smart cards to be inserted into readers during test execution.
Designing the Smart Card Layer
To enhance the testability of our code, we wanted to be able to mock parts of it that requires a smart card. To be mock-able, the Smart Card Layer needed a contract with the upper layer, we put in place an abstract base class that would expose functional methods and at the same time lock down how the result and potential errors were to be reported. Any class inheriting from the base class would be responsible for the device interaction.
Here is an extract of the base class:
protected abstract void getSerialNumber(); public final void getSerialNumber(AsyncServiceCallback callback) { ... getSerialNumber(); ... } protected void onGetSerialNumberFailure(ServiceError error) { getSerialNumberCallback.onFailure(new GetSerialNumberResult(error)); } protected void onGetSerialNumberSuccess(String serialNumber) { getSerialNumberCallback.onSuccess(new GetSerialNumberResult(serialNumber)); }
This contract would allow us to write an implementation for every type and variation of smart cards we needed to support, with the added bonus of allowing us to add a mock smart card layer implementation. The mock smart card implementation doesn't actually perform any smart card operations. Instead, we configure in the setup code of a unit test the expected input and return values for the test case.
Here is an extract of the mocked class extending the abstract class shown above.
public MockConfiguration getSerialNumberConfig = new MockConfiguration(); @Override protected void getSerialNumber() { getSerialNumberConfig.execute(new RunMe(){ @Override public void run() { if (getSerialNumberConfig.isSuccess()) { onGetSerialNumberSuccess(getSerialNumberConfig.returnValue); } else { onGetSerialNumberFailure(getSerialNumberConfig.serviceError); } } }); }
Unit tests
A unit test sets up the underlying mock classes for the test scenario and then makes the call to the subject of the test. These tests allowed us to validate our business logic in different use cases independent of a smart card. In effect we were able to make sure that our application would fail gracefully if the smart card behaved in an unexpected manner.
We used the code coverage tool EMMA to assert that every anticipated (and unanticipated) failure condition worked properly.
Here is how we configure the mocked class:
ConfigurableMscmMock mscmMock = new ConfigurableMscmMock(); mscmMock.getSerialNumberConfig.returnValue = "112211221122112211221122";
Using the above techniques, we exceeded our expectations of automated test coverage.
Conclusion
Overall, we are impressed and excited about what is possible with GWT. We were able to rebuild a complex browser-based application and deliver a consistent product for both the offline and hosted solutions with improved user experience and testing methodology.
The new DAS is one of the first smart card applications built with GWT at Gemalto. This project has proved to be a great learning experience for the team. We hope the foundation we built here will be a spring board for many more GWT applications to come.
Thank you for reading our article - for more information about DAS, please visit http://www.gemalto.com.
We are pleased to announce the Google Maps API for the Google Web Toolkit 1.1.0 release. The Google Maps API library provides a way to access the Google Maps API from a GWT project without having to write additional JavaScript code. The library gives you full control using the standard Maps components such as InfoWindows, Markers, MapTypes, Overlays, StreetviewPanorama and Geocoding service. You can even use advanced features such as adding GWT widgets to the Map, creating custom overlays, custom map types, and other components.
The changes since 1.0.4 include:
This release is now available for download at the Google API Libraries for GWT project, hosted on Google Code.
With GWT 2.1 Milestone 1, you are one step closer to being able to build business apps for the cloud as easily as ever. Using GWT’s new data presentation widgets and MVP framework, you can create great looking web apps that run fast, whether you’re interacting with 25 records or 25 million records. This is accomplished by designing the widgets to be extremely lightweight, using DIVs and HTML instead of composites and widgets, and an app framework that makes it easy to fetch only the data you need, when you need it.
To make building web apps even faster, you can now use VMware’s Spring Roo to create a functional app with a few commands. All of these tools are available, including the Google Plugin for Eclipse and App Engine SDK, within SpringSource Tool Suite (STS) -- providing you an integrated development environment.
And since it’s written using GWT, your resulting app is an HTML5 app that is cloud ready from the beginning.
To get started, check out our GWT for Business and What’s coming in 2.1? sections on the GWT codesite.
We are pleased to announce updates to the Google API Libraries for the Google Web Toolkit project. The Google API Libraries for GWT project allows GWT developers to access some of Google's popular JavaScript APIs. This release includes updates of five libraries: Visualization, Gears, Gadgets, Search, Language, and AjaxLoader.
Highlights of this release include:
Visualization:
Gears:
Gadgets:
Language:
AjaxLoader:
For more detailed information please refer to the release notes.
These updates are now available for download at the Google API Libraries for GWT project hosted on Google Code.
Robert Cooper gave a great lightning talk at our recent Atlanta GTUG meetup, where he discussed using a single codebase to target multiple mediums (e.g. Android, Facebook, Wave, etc.). This post was taken from his original post, which is a good read, providing sound pointers as to how you can maximize audience reach with minimal code changes.
Robert's original post
I love crossword puzzles.
In the time before time, I would stop at my local coffee shop and purchase a copy of the New York Times. I would flip to the crossword and with the classic "double fold" begin the crossword puzzle. Mobile devices soon took over the world, and subscribing to the electronic version soon made much more sense than killing all those trees. Last fall, I switched from the orchards of Cupertino to an Android device, alas, there was no good way for me to do the New York Times puzzle on my way to work anymore. Time to start a project.
I developed the original version of Shortyz for Android (named in honor of, and with apologies to, Will Shortyz of the NYT) in about three weekends. It had a number of usability issues and was rough around the edges, but it was "Good Enough for Me." Unfortunately, because of stolen laptop I lost some progress on the source and my market signing key (yeah, I know). So I decided to "do it right." Forgoing the Android classes I implemented my own two-dimensional scrolling, touch handling and rendering code. Now I am quite happy with the results.
The new Shortyz code was much cleaner. I had implemented a Playboard class as the Controller of my MVC application and was completely independent of the UI code. I moved my IO classes out of the same package as my
Model classes, created a .gwt.xml file, and like that, I had the core of a GWT application. Implement a new UI and I am good to go.
Starting with my Android code, I had a playable web application in about five hours. Not bad, but like the first version of the Android code, I had some annoying usability issues and it was a little sluggish. After another day of work, I changed the UI code from using a play->render cycle like the Android app to use a more traditional MVC data binding system (based on Gwittir), and the performance problems were mitigated.
The next step was to take the web app and make it work everywhere! This is where Gin, a Google Guice DI for GWT apps, was key. My initial web app used a client side persistence mechanism to store play data (HTML5 LocalStorage, Gears, DOM Persistence, Flash). This works great for a standalone web app or a gadget, but for a Facebook version or Wave, I need alternative strategies. For my iGoogle version and Wave, I also need to make requests through the gadget.io API. Gin and Guice made this a breeze. Each of my versions simply becomes a new EntryPoint (or Gadget) class, a new Injector, and a new Module definition.
The real challenge came developing the Wave version. While Apache Shindig makes doing local development of Gadgets easy, there isn't an equivalent local harness for Wave gadgets, so you end up having to do a full build and deploy cycle to work on it. There are also some things that aren't clear from the Wave API docs that creep up, such as the maximum size allowed for the State object. After a solid 40 hours of work, though, I had a co-op play Wave gadget with player colors, remote cursors and nice playback support on the Wave.
So what is the take away here? "Extreme Source Compatibility" is a real thing. This is a Java application running on "Everything But The Java Platform" with the bulk of the code easily reused. Each subsequent version of the app took only a few hundred lines of code to get running. There are some important things to keep in mind. First, making sure your business logic and data models without dependencies on lots of external code is important. Since my Model layer was simple POJOs and my Controller layer pretty much just java.lang and java.util, there was a zero-hour ramp up time to make it work. Cleanly separating this code is also important. Since my input handling code and UI code was cleanly separated, this was much easier than it could have been to do the port. Finally, Guice rocks. While a lot of us in the "enterprisey" world understand the testability advantages of using a DI framework, many rarely have to provide lots of alternate implementations of classes. When you need it, though, it is amazingly handy to have a simple way to re-compose your whole application. Best of all, bugs I fixed in the core library while working on the web version rolled right into the original Android version unmodified.
As an interesting aside: GZipped, the GWT version is about the same size as the Android version; both are less than ~100K for the download. Custom code for each version makes up about 10% of the total LoC, with the exception of the Wave version where it is closer to 25%.
Quick colophon: Wave for GWT via CoboGWave: http://code.google.com/p/cobogwave/ Gadget Support: http://code.google.com/p/gwt-google-apis/ Gin, Guice for GWT: http://code.google.com/p/google-gin/ Data binding, local storage and JSON serialization: http://code.google.com/p/gwittir/
If you're in the Atlanta, GA area and interested in Google technologies, you should come down/over/up to the Google Midtown office for tonight's GTUG meeting. The first meeting was fun and positive, with lots of great discussion around GWT, App Engine, Android, and the state of technology overall. Tonight should be just as good, with the following agenda sketched out:
When: 04/27 @ 7pm EDT Where: Google Atlanta
If you're interested in building large scale applications the MVP way, you may want to checkout the latest addition to our articles section: Large application development and MVP - Part II.
In this follow-up article, we look into how techniques such as UiBinder and code splitting work in conjunction with an MVP-based app, as well as how to create complex and optimized UIs, without moving too much code into your views.
The new crop of HTML5 web browsers are capable of some pretty amazing things, and several of our engineers decided to take some 20% time to see how far we could push them. The result? An HTML5 port of Id's Quake II game engine!
We started with the existing Jake2 Java port of the Quake II engine, then used the Google Web Toolkit (along with WebGL, WebSockets, and a lot of refactoring) to cross-compile it into Javascript. You can see the results in the video above -- we were honestly a bit surprised when we saw it pushing over 30 frames per second on our laptops (your mileage may vary)!
It's still early days for WebGL, so you won't be able to run it without a bleeding edge browser, but if you'd like to check out the code and give it a whirl yourself, you can find it here. Enjoy!
It's been a while since we've put together what's been going on in the GWT community, and there's no time like the present to do so. Below are a handful of updates and new releases that have taken place over the past few months.
Smart GWT 2.1: Smart GWT, a framework that provides enhanced widgets that can coexist on both your client and server, has released a 2.1 version. Below are some of the key features of this release:
RaphaelGWT: The Hydro4GE team has open sourced their RaphaelGWT project. RaphaelGWT allows you to integrate GWT with Raphael, a lightweight JavaScript library for cross-platform vector graphics.
Gilead Update: Gilead, an Open-Source framework for seamless integration of Hibernate and GWT, has released an updated version of its project that contains the following features:
GWT MVC 0.4: The GWT MVC project, aimed at creating a layer on top Google Web Toolkit's widget library capable of implementing RIAs in easier and more conceptually guided way based on Model-View-Controller design pattern, has released version 0.4.
GWT Service Resolver: The gwtserviceresolver project has been added to Google code. Similar to gwt-dispatch, gwtserviceresolver allows you to minimize the code changes that are necessary as you add new RPC services.
GWT Mosaic: The GWT Mosaic project has added some tutorials to help developers wire up UiBinder-based elements with GWT Mosaic Actions.
GWT 2.0.3 has been released and is available for download here:
This was a minor release that includes the following fixes:
GWT 2.0.2 has been released and is available for download here:
Inevitably, as your app grows, you will find areas that involve consuming large amounts of textual data and performing some action as a result. You may be handling a JSON response, a serialized GWT RPC payload, or HTML that has been rendered on the server. In any case, you're a test-driven developer and you know that you have a handful of automated tests just wanting to be applied. The example below is one way of constructing such tests. And while it's not rocket science per say, it's so simple and useful that we felt compelled to tell others about it.
So let's say you're doing some server-side rendering, and somewhere in your code you most likely have a permutation of the following:
DOM.createDiv().setInnerHTML(foo);
Once inserted, you might apply some style, inject some values into the resulting HTML, etc.. Basically with the DOM structure in place, the rest of your app can move and do its thing. And "its thing" is often the more complex part, which begs for a test case. You want to make sure the "thing" it's doing is the right thing.
So at this point you happily code up a few GwtTestCase(s) and suddenly realize two things. One, "foo" can be really long, is a pain to maintain in code, and is ultimately polluting your test cases. Two, "foo" is most likely to change as your app grows, whereas your test cases shouldn't. Wouldn't it be nice if you could abstract "foo" away into a file that you load into your test cases, just as you do with other non-GWT test cases? Well, the good news is that you can. Much like other resources (e.g. ImageResource, CssResource, etc...), GWT has a mechanism for embedding text files into your app by specifying an associated TextResource within a ClientBundle. For example:
public interface TestResources extends ClientBundle { @Source("com/google/gwt/example/test/ExampleTest.dat") TextResource foo(); }
Here Example.dat would contain the HTML that I want load into my test case, and given that it's strictly for testing purposes you'll notice that I've added it under the "example/test" folder. At this point we have a ClientBundle from which we can grab the contents of our Example.dat file. In order to do something meaningful with this, we'll use it in a newly constructed GwtTestCase:
public class ExampleTest extends GWTTestCase { TestResources resources; public String getModuleName() { return "com.google.gwt.example.Example"; } public void gwtSetUp() { resources = GWT.create(TestResources.class); } public void testFoo() { DOM.createDiv().setInnerHTML(resources.foo().getText()); /* * insert complex code to be tested * */ } } }
Using this technique we've managed to keep our test cases clean, and centralized any test data changes within ExampleTest.dat rather than the ExampleTest source code. So clean, so simple, and hey, it even works when you want to load up some JSON data to test with.
We already have quite a few Google Web Toolkit I/O sessions and Developer Sandbox demos lined up, and we expect this number to grow over the coming months. Here's a partial list of the GWT sessions that are already listed on the I/O website:
Over the next couple of months, we'll be adding new GWT sessions and more GWT Developer Sandbox participants to the I/O website. For updates on when new content is added, follow @googleio on Twitter.
Registration for Google I/O (at the early bird rate of $400) is open as of today. We hope you'll be as excited about this year's I/O as we are, and we look forward to seeing everyone in May.
Google I/O May 19-20, 2010 Moscone West, San Francisco http://code.google.com/io
