Файл: book-of-vaadin.pdf

Mobile Applications with TouchKit

You also need to define a MIME type for the manifest in the web.xml deployment descriptor as follows:

<mime-mapping> <extension>manifest</extension> <mime-type>text/cache-manifest</mime-type>

</mime-mapping>

22.7.2. Enabling Offline Mode

To enable the offline mode, you need to add the OfflineModeSettings extension to the UI.

OfflineModeSettings offline = new OfflineModeSettings();

...

offline.extend(this);

You can extend the OfflineModeSettings extension to to transfer data conveniently from the offline UI to the server-side, as described in Section 22.7.4, “Sending Data to Server”.

22.7.3. The Offline User Interface

An offline mode is built like any other client-side module, as described in Chapter 13, Client-Side Vaadin Development. You can use any GWT, Vaadin, add-on, and also TouchKit widgets in the offline user interface.

Most typically, a client-side application builds a simplified UI for data browsing and entry. It stores the data in the HTML5 local storage. It watches if the server connection is restored, and if it is, it sends any collected data to the server and suggests to return to the online mode.

Please see the Vornitologist source code for an example implementation of an offline mode user i n t e r f a c e . T h e com.vornitologist.widgetset.client.VornitologistOfflineMode.java is the main module of the offline application.

22.7.4. Sending Data to Server

Once the connection is available, the offline UI can send any collected data to the server-side. You can send the data from the offline UI, for example, by making a server RPC call to a serverside UI extension, as described in Section 16.6, “RPC Calls Between Clientand Server-Side”.

22.7.5. The Offline Theme

Normally, client-side modules have their own stylesheets in the public folder that is compiled into the client-side target, as described in Section 16.8, “Styling a Widget” and Section 13.3.1, “Specifying a Stylesheet”. However, you may want to have the offline mode have the same visual style as the online mode. To use the same theme as the server-side application, you need to define the theme path in the widget set definition file as follows.

<set-configuration-property name='touchkit.manifestlinker.additionalCacheRoot'

value='src/main/webapp/VAADIN/themes/mytheme:../../../VAADIN/themes/mytheme />

You need to follow a CSS style structure required by the Vaadin theme in your offline application. If you use any Vaadin widgets, as described in Section 15.3, “Vaadin Widgets”, they will use the Vaadin theme.

Mobile Applications with TouchKit

22.8. Building an Optimized Widget Set

Mobile networks are generally somewhat slower than DSL Internet connections. When starting a Vaadin application, the widget set is the biggest resource that needs to be loaded in the browser. As most of the Vaadin components are not used by most applications, especially mobile ones, it is beneficial to create an optimized version of the widget set.

Vaadin supports lazy loading of individual widget implementations when they are needed. The TouchKitWidgetSet used in TouchKit applications optimizes the widgetset to only download the most essential widgets first and then load other widget implementation lazily. This is a good compromise for most TouchKit applications. Nevertheless, because of the high latency of most mobile networks, loading the widget set in small pieces might not be the best solution for every case.With custom optimization, you can create a monolithic widget set stripped off all unnecessary widgets. Together with proper GZip compression, is should be quite light-weight for mobile browsers.

However, if the application has big components which are rarely used or not on the initial views, it may be best to load those widgets eagerly or lazily.

You can fine-tune a widget set by using a custom WidgetMapGenerator implementation. It needs to be defined in the .gwt.xml widget set definition file as follows:

<generate-with class="com.myprj.WidgetLoaderFactory">

<when-type-assignable class="com.vaadin.client.metadata.ConnectorBundleLoader" /> </generate-with>

The WidgetMapGenerator should override TouchKitWidgetMapGenerator and its getUsedPaintables() method. The method returns an array of user interface component classes used by the application. Many largeish component implementations can be left out. The list of used components can be built manuall. You can also, for example, use a debugger to dig into the CommunicationManager class in Vaadin, which opens all the views of the application. It contains a set of all components that have been used.

public class WidgetLoaderFactory

extends TouchKitBundleLoaderFactory {

private final ArrayList<Class<? extends ServerConnector>> eagerWidgets;

public WidgetLoaderFactory() { eagerWidgets =

new ArrayList<Class<? extends ServerConnector>>(); eagerWidgets.add(SwitchConnector.class); eagerWidgets.add(EmbeddedConnector.class); eagerWidgets.add(NumberFieldConnector.class);

...

The getLoadStyle() method should return the widget loading style, which should be EAGER to get a monolithic widgetset.

@Override

protected LoadStyle getLoadStyle(JClassType connectorType) { if (eagerWidgets.contains(connectorType)) {

return LoadStyle.EAGER; } else {

return super.getLoadStyle(connectorType);

}

}

}

Mobile Applications with TouchKit

You can find a working example in the VornitologistWidgetset.gwt.xml and WidgetMapGenerator.java in the Vornitologist sources.

Note that you need to enable GZip compression for your deployment if you wish to optimize the startup time and minimize the amount of transferred data. The best method for doing that highly depends on your hosting setup, so we do not cover it here.

22.9. Testing and Debugging on Mobile Devices

Testing places special challenges for mobile devices. The mobile browsers may not have much debugging features and you may not be able to install third-party debugging add-ons, such as Firebug.

22.9.1. Debugging

The debug mode, as described in Section 11.3, “Debug and Production Mode”, works on mobile browsers as well, even if it is a bit harder to use.

The lack of FireBug and similar tools can be helped with simple client-side coding. For example, you can dump the HTML content of the page with the innerHTML property in the HTML DOM.

TouchKit supports especially WebKit-based browsers, which are used in iOS and Android devices. You can therefore reach a good compatibility by using a desktop browser based on WebKit. Features such as geolocation are also supported by desktop browsers. If you make your phone/tablet-detection and orientation detection using screen size, you can easily emulate the modes by resizing the browser.

Chapter 23

Vaadin TestBench

This chapter describes the installation and use of the Vaadin TestBench.

23.1. Overview

Quality assurance is one of the cornerstones of modern software development. Extending throughout the entire development process, quality assurance is the thread that binds the end product to the requirements. In iterative development processes, with ever shorter release cycles and continuous integration, the role of regression testing is central. The special nature of web applications creates many unique requirements for regression testing.

In a typical situation, you are developing a web application with Vaadin and want to ensure that only intended changes occur in its behaviour after modifying the code, without testing the application manually every time. There are two basic ways of detecting such regressions. Screenshots are the strictest way, but often just checking the displayed values in the HTML is better if you want to allow some flexibility for themeing, for example. You may also want to generate many different kinds of inputs to the application and check that they produce the desired outputs.

Vaadin TestBench

Figure 23.1. Controlling the Browser with WebDriver

Vaadin TestBench utilizes the Selenium WebDriver to control the browser from Java code, as illustrated in Figure 23.1, “Controlling the Browser with WebDriver”. It can open a new browser window to start the application, interact with the components for example by clicking them, and then get the HTML element values.

You can develop such WebDriver unit tests along your application code, for example with JUnit, which is a widely used Java unit testing framework. You can also use a recorder that runs in the browser to create JUnit test case stubs, which you can then refine further with Java.You can run the tests as many times as you want in your workstation or in a distributed grid setup.

Figure 23.2. TestBench Workflow

The main features of Vaadin TestBench are:

•Record JUnit test case stubs in browser

•Develop tests in Java with the WebDriver

•Validate UI state by assertions and screen capture comparison

•Screen capture comparison with difference highlighting

•Distributed test grid for running tests

•Integration with unit testing

•Test with browsers on mobile devices

Execution of tests can be distributed over a grid of test nodes, which speeds up testing. The grid nodes can run different operating systems and have different browsers installed. In a minimal setup, such as for developing the tests, you can use Vaadin TestBench on just a single computer.

Vaadin TestBench

Based on Selenium

Vaadin TestBench is based on the Selenium web browser automation library. With the Selenium WebDriver API, you can control browsers straight from Java code. The TestBench Recorder is based on the Selenium IDE.

Selenium is augmented with Vaadin-specific extensions, such as:

•Proper handling of Ajax-based communications of Vaadin

•Exporting test case stubs from the Recorder

•Performance testing of Vaadin applications

•Screen capture comparison

•Finding HTML elements using a Vaadin selector

TestBench Components

The main components of Vaadin TestBench are:

•Vaadin TestBench Java Library

•Vaadin TestBench Recorder

The library includes WebDriver, which provides API to control a browser like a user would. This API can be used to build tests, for example, with JUnit. It also includes the grid hub and node servers, which you can use to run tests in a grid configuration.

The Vaadin TestBench Recorder is helpful for creating test case stubs. It is a Firefox extension that you install in your browser. It has a control panel to record test cases and play them back. You can play the test cases right in the recorder. You can then export the tests as JUnit tests, which you can edit further and then execute with the WebDriver.

Vaadin TestBench Library provides the central control logic for:

•Executing tests with the WebDriver

•Additional support for testing Vaadin-based applications

•Comparing screen captures with reference images

•Distributed testing with grid node and hub services

Requirements

Requirements for recording test cases with Vaadin TestBench Recorder:

•Mozilla Firefox Requirements for running tests:

•Java JDK 1.6 or newer

•Browsers installed on test nodes as supported by Selenium WebDriver