Background

In a very simplified view, web applications consist of a customer-facing user interface (UI) and server-side code that executes business logic. The UI part of the puzzle is solved with a widget library, which is a set of controls and actions that a customer interacts with. In recent years there has been a great surge in activity in this area, and today there are dozens of widget libraries from which to choose. But the second part of the puzzle -- the server side -- has largely been neglected, with developers being directed to "roll their own" solutions for server-side code execution in response to client-side events, validation, and value conversion, to name a few things.

In this article, we will introduce DojoServerFaces, a Java Server Faces (JSF) widget library that combines the server-side power of JSF and Java EE with the client-side richness and accessibility of the popular Dojo widget library.

What is DojoServerFaces?

DojoServerFaces, or DSF, is a JSF widget library that wraps standard Dojo widgets and attaches the necessary plumbing to have those widgets interact with the JSF 2.0 server-side model. This means that all the Dojo widgets you know and love -- and even your own custom widgets -- can easily leverage the power of JSF 2.0, including server-side validation, value conversion, AJAX, managed beans, and more.

Getting Started

In order to use DSF, you must first download the library from its Github open source repository. You can either build DSF from source using Maven or you can download a prebuilt binary from https://github.com/downloads/kennas/DojoServerFaces/DojoServerFaces-beta-0.0.1.zip. For this example, we will use the prebuilt binaries. They need to be extracted from the downloaded ZIP file and added to a new web project's WEB-INF/lib directory. Also note that, for the purposes of this article, we will be using WebSphere Application Server version 8, though any application server with support for JSF 2.0 and Bean Validation should work.

For any DojoServerFaces application, keep in mind that you must provide a copy of Dojo and refer to it using a web.xml context parameter:

In this case, the use of a single slash before "dojotoolkit" indicates that we will bundle Dojo in our web application under the directory "dojotoolkit". A double slash, or "//dojotoolkit" would indicate that Dojo will be deployed in a separate web application with context root "/dojotoolkit".

Writing a Simple DojoServerFaces Application

Let's consider a very simple application: one that asks for a value between a certain range and validates it. In either pure JSF or pure Dojo we can very easily create this application, but each approach has its own strengths and weaknesses.

With a pure JSF approach, very little code is needed and we can easily manage the value on the server side using a managed bean coupled with Bean Validation to easily validate that the submitted value is not invalid by the time it reaches the server. However, unless we want to write a set of custom widgets, the default JSF widgets aren't going to look very pretty and certainly won't have rich client-side interaction, such as prompts and warning messages.

If we use a pure Dojo approach, again we find that very little code is needed. In addition, our widgets will look very nice and have rich client-side interaction and built-in accessibility features. But what about the server side? We'll have to write backend code that validates our value (remember, you can never trust a value submitted by a client, even if your widget library validates it!) and keeps track of it based on our scoping requirements. While not a daunting task for this simple application, in a larger application the amount of work necessary is considerable.

With DojoServerFaces, we can get the best of both worlds: the server-side richness of JSF coupled with the client-side richness of Dojo. To begin, let's create the managed bean that will hold our value:

Note the power that JSF 2.0 and Bean Validation gives us -- with a few simple annotations we can have our bean persist throughout the user's session and automatically perform validation on our input values. Rolling our own solution would be considerably more work. Now let's finish with our JSF 2.0 Facelet code to complete the user interface:

Let's take a look at what's happening here. We have a prompt widget that displays a prompt message and the current bean value (using the bean expression #{dsf.value}) and a DSF textbox which both displays and updates the current bean value. We also have a button that, when clicked (i.e., the "click" event occurs), will use JSF 2.0's AJAX capabilities to "execute" or update our textbox and re-render the prompt and a standard JSF message widget. If an invalid value is given, the JSF message widget will contain the error message. Otherwise, the prompt will contain the new value. Here's a look at this page in action:

Note that DSF has automatically included all the typical Dojo boilerplate (Javascript, CSS files, and import statements) and as a result, we have a boring yet visually appealing (at least, more so than normal) JSF application. But we want to leverage more of Dojo's client-side functionality, so let's make a change to our text box:

By using a DSF numberTextBox, we can leverage the functionality of the Dojo numberTextBox, including value ranges, prompt messages, and warnings when values are missing or invalid:

Conclusion

With this simple example, we can begin to see the usefulness in using DSF to write web applications. By using DSF, we can fill the gaps that exist between pure JSF development and pure Dojo (or any other client-side widget library) development. Future articles will explore more advanced topics, such as integrating custom Dojo widgets with DSF and doing mobile application development with DSF.

Introduction

Nearly every mobile device available today has a camera. Given their easy use and instant availability, cameras are increasingly being used to share photos with friends and family, document activities and even deposit checks. Paramount to sharing or saving photos is uploading the photo to a server so it can be used by a web service. Utilizing mobile hybrid technologies, PhoneGap provides mobile applications access to device features and capabilities using only standards-based web technologies HTML and JavaScript - instead of requiring the application be written using native device code.

This blog post will demonstrate how the PhoneGap API can be used to write a simple Android application that either takes a picture with the camera, or selects a photo from the photo album, and uploads it to a web server. Figure 1 shows the application that will be developed. Source code is provided for readers who want to build and run the application.

Figure 1: Picture upload application.

Getting the Picture

One of the many features included in PhoneGap's API is the Camera object. The Camera includes a getPicture() method which takes a picture using the camera or retrieves a photo from the device's photo album. It can be called from JavaScript as follows:

Some platforms like Android have only one album or library, so PHOTOLIBRARY and SAVEDPHOTOALBUM both display the photo album chooser.

The cameraSuccess function is called with the URI of the photo when a picture is taken or a photo is selected from the album. The src attribute of an <img> tag can be set to this URI to display the photo in an HTML page. The URI can also be used to identify the photo to upload to a server.

First we start with an HTML page that includes an <img> tag and several buttons for obtaining and uploading a picture:

For more information about the navigator.camera.getPicture() method see the PhoneGap Camera API documentation.

Uploading the Picture

PhoneGap also includes a File API that has a FileTransfer object. FileTransfer can be used to upload a file represented by a local URI to a web server using HTTP or HTTPS multi-part POST. A file can be uploaded by calling:

The last parameter is the options object which consists of the following keys:

fileKey: The name of the form element. (default="file")fileName: The file name you want the file to be saved as on the server. (default="image.jpg")mimeType: The mime type of the data you are uploading. (default="image/jpeg")params: A set of optional key/value pairs to be passed along in the HTTP request.

The URI of the picture returned by the takePicture() or selectPicture() functions can be used by FileTransfer to upload the picture to a server. Referring to the HTML code above, clicking on the Upload Picture button calls the uploadPicture() function. This function uploads the selected photo to the server:

For more information about the FileTransfer object see the PhoneGap File API documentation.

Picture Server

To save or share the picture, it needs to be uploaded to a server. Most servers accept HTTP multi-part POST requests. Using an Apache web server with PHP enabled, a simple PHP application can be used to receive a photo and save it on the server.

The $dirname variable is set to a directory that can be written to by the web server. When an upload request is received, the $_FILES variable contains the details of the uploaded file and it's temporary location. This temporary file is copied into $dirname.

Figure 2: Selecting a photo and uploading to server.

Before uploading a photo to the server for our application, the server URL input text field must specify where upload.php is located.

Viewing Pictures

Photos saved on the server can be retrieved using PHP code that generates HTML for displaying on the device. Clicking the View Uploaded Pictures button will call the following viewUploadedPictures() function.

Since the successful response is already formatted as HTML, it can be rendered directly by setting innerHTML of the server_images <div> tag as shown in Figure 3.

Figure 3: Viewing uploaded pictures on server.

Summary

This blog post showed that device features not normally available to mobile web applications can be easily accessed from JavaScript using PhoneGap. We discussed how to use the PhoneGap APIs to take a picture or select a photo from the device's album, upload it to a PHP application on the web server, and display the photos saved on the web server - all without having to write any native device code.

Summary: The IBM WebSphere Feature Pack for Web 2.0 and Mobile provides the IBM Dojo Toolkit (IDT), an Ajax framework built on open-source technology. IDT developers internally test the IDT widgets using the Dojo Objective Harness (DOH), which ships with IDT. In this post, I describe DOH test patterns the IDT team has developed, explore how DOH testing has evolved internally since its introduction to the IDT testing process, and discuss future directions.

Background

For the uninitiated, DOH is a functional test framework for testing HTML and JavaScript code. Tests are written in HTML and JavaScript and execute in any IDT-supported browser; this format makes it easy for developers already working with in languages to verify their code. DOH shares much of the JUnit style:

Provides setUp/runTest/tearDown interface to construct tests

Tests arbitrary JavaScript code

Provides assert methods to manually verify the resulting data state is correct

DOH also provides the doh.robot API, which enables tests to interact with the Web page under test using native input events.

Common test patterns

In this section, I enumerate some common test patterns I see in IDT and describe how they have evolved. I often advise developers to examine our test cases for examples of how to use IDT and how to test IDT-based code; I summarize what I've noticed here.

Visual inspection

Prior to IDT 1.1, we didn't have a test framework like DOH at all! In those days, we primarily focused on making the widgets look and behave the same on ALL browsers (looking at you IE6!); functional correctness was of secondary concern and was just assumed. While today we place greater emphasis on verifying functional correctness, we still run visual inspections to make sure our widgets still flow with the page.

Visual inspection tests are all over Dojo; they are HTML pages with names that start with test_, like test_Slider.html. When you load a visual inspection test, it creates instances of the widget under test (such as Slider in test_Slider) with various parameters applied.

Evolution

Our visual inspection tests have evolved over time. As we add new features to widgets, we add new test instances exercising those features. And while some of the instances we test still remain in the form they were first created in way back in Dojo 0.4, the way we test them has changed. In particular, all of our Dijit visual inspection tests take GET parameters to change the page's CSS theme, locale, and text direction (to test right-to-left languages). We reuse these tests to construct our GUI tests.

Not all of our testing revolves around inspection of the GUI; sometimes we just like to make sure our JavaScript logic works. The next section describes a common pattern we use to verify our JavaScript.

Functional Testing

To test JavaScript code that runs independently of any particular HTML document, we use the Functional Testing pattern. This pattern most closely resembles JUnit testing and characterizes IDT's internal testing of the core dojo package. These tests are written almost entirely as JavaScript files with no supporting HTML. The Functional Testing pattern consists of two steps:

Perform computation

Assert computation matches expected value

For example, we use the Functional Testing pattern to test our JSON deserialization:

Evolution

Our Functional Testing for our core Dojo has not significantly changed since its inception. As we develop more complicated widgets in other areas, we try to separate DOH from the test page so we can still manually inspect them without waiting on DOH. The next pattern utilizes this approach.

Robot-Sequence-Assert

To test the functional correctness of our GUI code, each of our test cases typically undergoes several steps:

Create the widget to test

Use the doh.robot API to interact with the widget

Wait for the robot to finish

Assert that the resulting state is what we expected

This pattern characterizes IDT's internal testing of the dijit package. We typically instantiate the widgets we want to test by loading the corresponding visual inspection test into DOH, like this:

Evolution

As we started writing lots of tests like this, we noticed that we ended up copying and pasting a lot of the same test code; we often needed to drag Sliders, open ComboBoxes, etc. Thus, over time we refactored our test code to use a parameterized test function. For example, in ComboBox we found we were writing a lot of tests to browse the menu and select an item, so we generalized that class of tests into a generating function this:

// this function arrows through the list of choices until it can verify the one we specified was in the UIvar robot_a11ySelectValue = function(combo, text, value, expectedText){ if(!value) value = text; if(!expectedText) expectedText = text; var d = new doh.Deferred();

}; // first time, wait for the data to come in doh.robot.sequence(repeat, 3000); return d;};

Also, a lot of people ask me about capture-playback tools, like those found in dojox.robot, to automatically write doh.robot tests. While at first we used them extensively, in practice we stopped using the automation to write tests for several reasons. First of all, test maintenance became difficult as we rewrote our widgets' templates; widgets' insides both moved around the screen and moved with respect to the DOM, so our tests became obsolete as soon as we made even minor changes to the templates. Second, we still had to manually write assert conditions. While other playback tools can verify the screen looks the same as before, it is inherently very difficult to verify the correctness of a widget in IDT just by its appearance because a) different browsers and OSes will render components differently no matter how hard you try and b) the widget's appearance doesn't reflect the entire data state. These factors led us to just manually write DOH tests for our GUI testing and as a result we achieved cleaner and more maintainable tests.

Performance testing

A few performance-sensitive pieces of code in IDT, like the graphics package, have performance tests associated with them. The owners periodically run the tests on their machines to prevent performance regressions. We first constructed these tests identically to Functional Tests. For example, one of our oldest performances tests comes from CsvStore:

As you can see, the test shares a lot of the same semantics as Functional Tests; it performs a computation (a datastore query in this case) , then verifies the results are correct. Our DOH performance testing harness runs this computation some multiple of 50 times (trialIterations), the magic multiple defined during calibration until the combined runs exceed 100ms (trialDuration).

Evolution

Over time however, we realized we could much more efficiently construct performance tests by separating the functional and performance aspects of the tests; we ran performance tests many times to get a good sample, so it made sense to strip out the redundant assertions. The dojox.gfx tests offer new examples of how we write performance tests:

Future work

With IDT 1.7, we are introducing new mobile widgets and with it mobile testing. We created a DOH mobileRunner to display visual tests and DOH Functional Test results on mobile devices. We are prototyping some new mobile testing technologies to re-use our existing doh.robot APIs in a mobile environment. Unfortunately, the way we interact with mobile devices is fundamentally different than the way we interact with desktops; this change will require testers to re-think their favorite desktop tests. For now, we use a mix of manual mobile verification and desktop doh.robot tests to test mobile widgets.

Also, I personally am finding that the JavaScript world is still lacking static analysis tools like Control Flow Graphs, Data Flow Graphs, and coverage metrics beyond just line coverage. While these features would be outside the capabilities of a framework like DOH, I would still like to see more research in this area in the future. Although we do static analysis manually for IDT, I think having automated static analysis is important for driving IDT users' testing efforts toward a reachable goal.

We continue to evaluate the progress of external open-source testing frameworks, notably Selenium with its 2.0 release, looking for areas to improve or revamp our DOH technologies. Now that we have established a large and maturing regression test bucket in IDT, we will continue to address the needs of developers looking to test their IDT code by writing IDT code through our DOH framework.

As mentioned in previous blog posts (for instance Displaying attractive diagrams: quick hints for choosing a graph layout algorithm from Dojo Diagrammer), Dojo Diagrammer provides a comprehensive set of layout algorithms for laying out nodes and links in graphs. In the present post I will provide more in-depth information that may help for configuring the link layout in a tricky case of graphs: nested graphs. Nested graphs are graphs where nodes contain another graph, as opposed to flat graphs which do not contain other graphs. An example of nested graph:

In Dojo Diagrammer, there are several ways to get the links laid out. Link layouts can be performed by:

Node layout algorithms that also have extensive built-in link layout capabilities: HierarchicalLayout, TreeLayout. These provide various link styles and many configuration options.

Node layout algorithms that only support a straight link style: CircularLayout, ForceDirectedLayout. These provide support for self-links (links connecting a node to itself) and multi-links (several links that connect the same pair of nodes).

Specialized link layout algorithms: ShortLinkLayout and LongLinkLayout. These can be used in conjunction with a node layout.

All these algorithms can be applied to flat or nested graphs. The case of nested graph is the trickiest, mostly because of two reasons:

The layout algorithms being applied locally to each subgraph in a bottom-to-top traversal of the graph hierarchy, the result is optimal locally (for each subgraph) but is suboptimal globally (for the entire nested graph).

Most node layout algorithms (TreeLayout, CircularLayout, ForceDirectedLayout) are not able to lay out intergraph links, that is links that interconnect nodes from different subgraphs. (The reason being the one mentioned above: the layout being computed individually for each subgraph, it cannot treat links that traverse the boundaries of subgraphs.)

To deal with intergraph links, the node layouts such as TreeLayout, CircularLayout, and ForceDirectedLayout need to be combined with a link layout (ShortLinkLayout or LongLinkLayout) configured such that it only lays out the intergraph links, while the regular links are laid out by the node layout:

Remains the happy case of HierarchicalLayout. This node layout is the only one that is able to handle intergraph links by itself, and to optimize the layout for the entire nested graph. That is, for laying out nested graphs using Hierarchical, the configuration is much simpler: you only need to set the Hierarchical as node layout. No link layout is needed.

This feature of HierarchicalLayout is enabled by default. It can be disabled (but in this case do not forget to combine it with a link layout for intergraph links in nested graphs):

hierarchicalLayout.setRecursiveLayoutMode(false);

Note for users of Dojo Diagrammer 1.0: this feature is new in Dojo Diagrammer 1.1.The picture below shows a nested graph laid out with this feature of HierarchicalLayout disabled, plus LongLinkLayout configured for the intergraph links:

For comparison, here is the same graph laid out using only HierarchicalLayout with the recursive mode enabled (which is the default mode):

Besides the simplification of the layout configuration (no need to combine the node layout with a link layout), the recursive mode of HierarchicalLayout provides a better quality. As you can see by comparing the two screenshots above, the number of link crossings is smaller, and the links are laid out in a more uniform manner, pointing from left to right (the direction of the hierarchical flow). This is the benefit of the global optimization of the layout for the entire nested graphs.

Using web technologies to develop native mobile applications has become a popular solution when writing applications for multiple smartphone platforms. Such applications are typically labeled as "hybrid", referring to the mix of native code and web code running inside the application. As far as development tools are concerned, different options exist for different platforms. In this post I focus on a method for developing in the hybrid model for the Android platform because of the easy integration between the tools for native development on the Eclipse platform. More specifically the Android Development Tools (ADT) plug-ins for Eclipse will be used for native Android development, Rational Application Developer (RAD) tools for web development. Lastly the Phonegap JavaScript library will be used for native Android SDK to JavaScript integration. Both RAD and ADT are Eclipse based and can be installed into, and live happily together in, the same Eclipse platform. Such integration also exists for BlackBerry development. We might revisit that in a possible future post.

Note that the information provided here regarding using Rational Application Developer for hybrid development is not an officially supported scenario. In RAD 8.0.3 ifix1, only purely web-based mobile solutions are officially supported. However, as you will find out below, the existing tools do actually lend itself nicely to the hybrid development needs.

First let's see what it takes to get the necessary stuff installed. You should start by installing Rational Application Developer 8.0.3 ifix1. If you are going to stay in this hybrid development mode for awhile, consider reducing the installed features to the minimum required for this task, to reduce the UI clutter and improve performance. In the Installation Manager's "Install Packages" panel, click the root entry twice to clear all selections (first click selects everything, second click clears everything), and then select only the "Web development tools" -> "Ajax, Dojo toolkit and HTML development tools" feature. This gives you all the tools that are needed, including all the web resource editors (HTML, JavaScript, CSS, JSON), a true WYSIWYG editor (Rich Page Editor beta), the Mobile Browser Simulator, and a fast testing server (Ajax Test Server). Next, follow the steps to install the Android SDK and the Eclipse tools for Android native development, including the emulator. Make sure to go through "Step 4. Adding platforms and other components" so that the necessary Android platform will be installed to compile the native application against.

At the end of the install, you will be prompted to restart RAD. Click "Restart Later" to close the dialog. You should manually shut down RAD and restart it because an additional step must be preformed before RAD can be successfully started after the Android tools are installed. This additional step involves making the necessary changes to launch RAD with a Sun Java 1.6 JDK. The Android SDK requires a Sun-specific JCE provider in order to add the digital signature to the .apk during the build. This class is not included in IBM JDKs that come with RAD installs. To get around this problem RAD must be configured to launch with a Sun JDK. Replace the parameters in the eclipse.ini file, in the same folder as eclipse.exe, with the following:

Now you are ready to write some code! At a high level three types of code are typically developed for a hybrid solution. First, the bulk of the application should be written in web code, HTML/JavaScript/CSS, which is the beauty of the hybrid approach. This covers most of the UI and business logic. In order to invoke device services, such as the camera or the contact list, a JavaScript-to-Java bridge library, in this case, PhoneGap, is needed. Second, there might be situations that require the writing of native code, Java for Android and BlackBerry, Objective C for iOS. For instance, if you need to have an overlaying frame on the camera viewfinder screen, you would write your own native control that extends from the native camera control class. Last but not least, there might be device specific services that are not directly supported by the PhoneGap API. In order to invoke the services from JavaScript, you need to write PhoneGap extensions, which is a fairly simple task and requires a minimum amount of JavaScript and native coding.

My suggestion is that you break this process into three steps:

1. Develop the web code using the full browser as the target environment. The environment in the full browser is almost identical to the embedded browser that gets packaged in the hybrid application, with some minor differences mainly in page load events. For instance, in full browsers dojo code is kicked off by the dojo.ready() event. When running in the native application, the code must be changed to listen to the DOM "deviceready" event which is fired by PhoneGap when it's fully loaded. More than 95% of the code should work the same way. The advantage of developing as much as possible in this environment is that with a fast and light-weight server, such as the Ajax Test Server, changes can easily be made and then quickly reloaded in the browser for instant testing. This saves the time of waiting for the build and sitting around until the emulator catches up. With the Mobile Browser Simulator you can get a sense of the look-and-feel of your UI in the target phone's specific form factor and in different orientations. In addition, using the Rich Page Editor (beta) you can easily put the UI together with markup. RAD also provides one-click publishing of your web projects onto the target server.

2. Develop the native code and PhoneGap code in the Android project. There's no need to go into details about native development here. For the PhoneGap part, the typical tasks are listed in the Getting Started guide. What about the web code? I suggest for this phase you keep the web code in its original web project, separate from the Android project, especially if the project contains a lot of code, taking into account any dependent libraries such as Dojo. Doing this saves time by avoiding lengthy builds.

And there's a specific reason for doing this if Dojo is used. If Dojo itself is put inside the Android project, it will not work due to a problem with the Android build tool. The problem is that all folders and files starting with "_" are not included in the .apk (http://code.google.com/p/android/issues/detail?id=5343). A work around is to produce custom layers so that the code is consolidated into larger js files. Performing custom Dojo builds will occur in step 3 after fully testing the application. As such, keeping the web resources in their separate web projects and loading them from the web server (using http:// URLs instead of file:// URLs) will make Dojo work without custom builds.

In order to get the web resources loaded into the native Android Application, built using the PhoneGap tools, you can use the PhoneGap API like this, in the Application class that extends DroidGap:

super.loadUrl("http://<link to the deployed web resources>");

Note that the link can't be "localhost" because on the device emulator that maps to the device itself instead of the development machine that is running the emulator and webserver. Use the IP address for the development machine instead.

3. Move the necessary code into the Android project. Once the code is well tested both in the Mobile Browser Simulator (in step 1) and the emulator (in step 2), the web resources, including any libraries such as Dojo, can be moved into the Android project. If Dojo is used, a custom build needs to be produced for three reasons: 1) reduce size, 2) better performance, and 3) getting around the excluded resources problem (see step 2). This custom build can be created by using the Dojo Custom Build wizard provided in RAD. Make sure to thoroughly test the consolidated layers by continuing to load them with the http:// URL. After the custom layers have been well tested the web resources can be moved into the Android project.

Create a folder "www" inside the "assets" folder which should have been created by the Android project wizard. Then start moving the web resources into that folder. Because of the custom layers (large js files consolidating multiple dojo modules), most of the Dojo source files can be left behind. You should never copy the entire Dojo source tree into the Android project for the reasons already mentioned.

Finally, to start loading the web resources inside the Android package, change the Android application class to something like the following:

super.loadUrl("file://android_asset/www/<link to the target file>");

From this point on, all coding and testing is done exclusively in the Android development environment. Most of the web development tools are not supported in Android projects, except for the CSS editor and JSON editor which can continue to be used.

Although the current release of RAD does not claim support for hybrid development, it does offer value if a process such as the one described here is leveraged. From searching the Internet many have already started using Android Development Tools with Rational Application developer to develop in the hybrid model. Some have run into problems, and I hope this article will provide a method for solving these problems. Happy coding!

HTML5 offline web application is a wonderful technology that let web applications work without network connection, which is especially useful for mobile web applications since wireless network is not as stable as wire network is.

According to W3C specification of offline web application, developers needs to provide a manifest file if they want to enable the offline cache capability. The manifest file lists all the resources that will be offline cached and needs to be referenced in HTML page like this. <html manifest=”cache.appcache”>The cache.appcache needs to be served as “text/cache-manifest” content-type and the browser will fetch all of the resource files in the manifest during the first load or whenever the content of manifest is updated.

When the network is unavailable, the browser will detect cache error when trying to communicate with server for the latest manifest and then fetch the resources on the manifest list from local offline cache.

Problem

However, if you are developing a web application with offline capability in the coming Dojo 1.7 (either from scratch or migrated from previous version), you might meet with XHR errors when loading the application in offline mode in Safari mobile on iOS (or maybe in other mobile browsers as well). That is because of:1. By default in Dojo 1.7, the loader is not in true asynchronous mode and will use XHR to load resources2. The XHR loading and offline cache manifest detection are in parallel in Safari mobile, and JavaScript codes are loaded and being executed during the manifest detection.3. In Safari mobile, the XHR sent before manifest detection is completed will not fall back to offline cache. So the request is sent to network, and thus will fail in loading. That's why you get XHR errors even if the target resources are defined in offline cache manifest and preserved in local.

The content of cache.appcache manifest file is very simple. You can get the latest build version from http://archive.dojotoolkit.org. By September 1st, the nightly build can still re-produce the problem.

Below is the content of “cache.appcache” manifest file which just includes some basic resource files.

CACHE MANIFEST

CACHE:test.htmldojo/dojo.jsdojo/selector/acme.js

NETWORK:*

Here is the steps for trying the test in offline mode.

First, let us load the test page in Safari mobile. The author is using an iPhone with iOS 4.3.1. This step allow the browser to load the web resources and cache them in offline cache.

As you can see in Figure 1, the XHR error happens before cache “checking” event is popped up, which means an XHR is sent before manifest detection is completed. That XHR is sent when dojo.js is being executed and it will fetch acme.js.

However, the same test case will not fail on the desktop browser like Chrome. Below is a network log captured in Chrome desktop. It might be because the Chrome browser organize the resource loading after the manifest detection is over or it is much faster for desktop browser to finish the manifest detection than the mobile browsers do. Anyway, the network log in Figure 1 proves that an XHR request for acme.js is sent when executing dojo.js, which fail in Safari mobile.

Figure 2

Solution

So how can we we enable HTML5 offline web application with Dojo 1.7?

The solution is to use asynchronous module loading and honor the web browser in loading resources. Asynchronous module loading will insert <script> tags in HTML document to load modules, instead of sending XHR. That means that the loader delegate the resource loading to web browser and Safari mobile will take the responsibility of loading the content in <script> tag. In this way, Safari mobile can decide the loading sequence, load resources after the manifest detection is over, and prevent any loading conflict.

To enable asynchronous module loading, you have to set “async:true” in djConfig, like below:<script src=”dojo/dojo.js” djConfig=”asyn:true”></script>And you need to follow AMD and use “require()”to load all other Dojo modules or JavaScript files instead of manually coding the <script> tag directly into HTML. For example, if I need to load my own src.js (src.js needs to use AMD way to define the module) which is under the same directory with index.html. I can use the this piece of code right after <script> tag which load dojo.js<script> require([“./src.js”], function (moduleName){ //call back to execute after src.js is loaded });</script>

After the above changes are applied to the code, the test case can now work on safari mobile in offline mode.

Here is the screen capture of the safari mobile log.

Figure 3

Note: the cache error log on Line 9 in the screen capture (Figure 3) means the browser cannot get any update information in the checking of manifest file from the server, it will then force to use the resources in the local offline cache. It is not the error thrown by the browser and is different from the JavaScript error in Figure 1.

In this previous post I introduced the new IBM ILOG Dojo Diagrammer component included in the WebSphere Application Server Feature Pack for Web 2.0 & Mobile v1.1.

In this new developerWorks article, Emmanuel Tissandier and I give an end-to-end description on how to use Dojo Diagrammer and Rational Application Developer to create a web application that displays an organization chart from data retrieved from the server through a REST service. The step-by-step article explains how to create both parts of the web application: the server-side REST service and a client-side page based on the Dojo Diagrammer widget.

Here is the final application described in the article:

We think this article shows well how the new WAS Feature Pack for Web 2.0 & Mobile visualization components (along with Rational Application Developer Web Tooling) allow you to easily create innovative web applications.

In my article, User interface design for the mobile web, I recommended UI design patterns as a resource for designing applications. In a series of posts,I'll survey UI design patterns for mobile devices starting with the list family of designs. But first, I'll say a few words about UI design patterns. I like Jennifer Tidwell’s definition of a pattern:

Patterns capture a common structure, without being too concrete on the details, which gives you flexibility to be creative

Unlike programming design patterns, UI design patterns define the externals of an application - the user interactions and visual structure of the interface. UI design patterns intentionally omit details about the implementation so that the designer can concentrate on the user experience. UI design patterns are often grouped into collections ("libraries") that are organized by user goals, task or use of specific UI elements.

I'm covering list patterns first because of their pervasiveness in mobile applications. In a sample of 100 popular mobile web applications, I found almost 40% used lists as the central organizing UI feature.

Lists are widely used because they are flexible. They are used for navigation, layout, and option selection. Furthermore, because they are taller than wide, they are well-suited for portrait mode presentation on phones.

The following are some of the most common elemental list patterns. Most of these can be combined to create hybrid patterns.

Navigation

Single Window Drill-Down: A simple list with a ">" symbol on the right edge of each item is used to direct the user forward through a hierarchy of options. Because it is bad form to take a user somewhere without supplying a way out (other than exiting the application!), navigation lists also must supply a way for the user to navigate backwards.

This usually isn't much of an issue for native applications on Android devices because this platform provides a built-in, hardware "Back" button. However, if you are developing a mobile web application that will display on multiple device types, you will usually need to define a software Back button. The Back button usually appears in a page title or heading bar. If the parent page doesn't have a title, use the label "Back" for this button. When the parent page has a title, you should use it as the label for the Back button.

Split View Navigation: The Split View layout is a useful option for organizing a hierarchy of pages on tablets. The left-hand pane consists of a navigation list and the right-hand view displays the contents of the selected item in the list. Because the navigation list is always visible, users can quickly flip through options while remaining visually oriented to the overall navigation structure. Subsequent navigation appears in the right-hand pane. The Settings application on the iPad is a good example of Split View Navigation.

Split View and Single Window Drill-Down Navigation differ in a few details. In split view, the Back button can be omitted in the first level down from the home page because the user can navigate out of this page by selecting another option in the navigation pane. At lower levels, a Back button should be supplied labeled with the title of the parent view. In addition, because the destination page and navigation list are visible together, the ">" icons are unnecessary and can be removed to create a simpler, cleaner appearance.

Search List: Search Lists provide navigation through large, non-hierarchical sets of pages. The search field is used to generate a list of results. If the items in the search result represent links to pages, ">" icons may be provided to indicate that there is additional content to be seen.

Organization

Lists provide a linear structure for options or values. Vertical lists work well with structured textual information.

Rich Lists: Good user interface design presents information in a hierarchy that allows the user to quickly scan through a page to determine which items to attend to in order to reach his or her goals with minimal physical and cognitive effort. The designer accomplishes this by balancing information overload - presenting too much detail and information underload - presenting insufficient information for accurate choices. Rich Lists manage information load by providing multiple types of information of varying detail and emphasis. The user can glance at an image or title and quickly decide whether to continue to scan the item or proceed to the next. Examples of rich list applications abound. Music stores such as iTunes, YouTube, the Apple App Store, and Facebook all make good use of the rich list pattern.

Highlight Lists: Highlight Lists include an expanded view of one of the list items. Typically the expanded view is at the top of the page with the list immediately below it. A common application of a highlight list is to advertise a specific item. For example, music store applications often use Highlight Lists to call out new releases. Another application is to provide additional detail about a selected item.

Table Lists: A Table List is a simple table created with a list widget. Because of limited space on phones, Table Lists often have no more than two columns. A common use case is the display of name-value pairs. For example, a weather app might employ a list with city names as item labels and current temperatures as values. Tables with drill down capability can be created by using "badges" preceding the navigation icon to summarize data in the subsequent page.

List Forms: Lists provide a straightforward and aesthetically pleasing way to organize settings. A List Form is simply a table in which widgets replace values on the right side of each item label.

Category lists: Category Lists organize items into sub-lists. They are often used in List Forms. Category Lists can used with or without category labels.

Selection

Choice Lists: Choice Lists are similar to selection lists in desktop GUIs. On phones, long Choice Lists often appear as their own page. This can be a more usable solution than an HTML drop down control because it insures that each list item is large enough to serve as an adequate touch target. Short Choice Lists on phones may also appear in slide-up overlays.

In a single-selection Choice List, item selection is complete when an item is touched. For example if the list is transient, it should automatically dismiss after a choice is made. Multiple selection Choice Lists must supply a "Back" or "Done" button for the user to mark selection completion.

On tablet devices, choice lists are often embedded in dialog boxes. This is preferable to full view lists because they visual context of the current page is maintained during selection.

Editable Lists: Some applications need lists in which the user can add, remove or change the order of items. The Editable List pattern indicates editabilty with an "add" button (using a "+" icon), "remove" buttons (using a "-" icon) and "grab" icons to indicate that items are movable.

Because removing items in a list is destructive, it is important to prevent accidental changes to the list. An interlock is provided by defining a default non-editable mode. The user must explicitly enter edit mode to expose edit controls on the list.

Leveraging the power of Dojo in your application can take it to the next level. However, developers need to keep in mind that Dojo is a large toolkit, so it is important to take the steps of creating an optimized Dojo build rather than including all of it. This step enables an app to limit the number of Dojo files included to just those that are required. By reducing the number of files, the download of the app is dramatically faster.

An ideal way to organize your Dojo references can simplify your app and make it easy to generate the optimized Dojo build. The following blog, shows a great example.

In general, the article outlines a design pattern where the dojo.requires() statements are isolated to a single file. When doing the optimized Dojo build, build.sh references that file and replaces it with a single consolidated JavaScript file including the portions of Dojo specific to the dojo.requires() statements. The reference above provides further detail along with code samples.

With the explosion of mobile devices such as tablets and smart phones, the ability to be able to work in what is called disconnected mode becomes a requirement. In support of this requirement, HTML5 provides the ability for developers to define what is called an application cache manifest file. Inside of this application cache, developers can denote which files that are associated with the application can be cached indefinitely by the browser. By enabling this cache, the browser can now retrieve web resources from it's local cache without having to request these resources via the network to the web server that is hosting the web content.

The HTML5 specification provides an overview of how this cache can be defined. To demonstrate how this can be used, I am including the following example from this specification.

The author can instead provide a manifest of the three files:

CACHE MANIFEST

clock.html

clock.css

clock.js

With a small change to the HTML file, the manifest (served as text/cache-manifest) is linked to the application:

<!-- clock.html -->

<!DOCTYPE HTML>

<html manifest="clock.appcache">

<head>

<title>Clock</title>

<script src="clock.js"></script>

<link rel="stylesheet" href="clock.css">

</head>

<body>

<p>The time is: <output id="clock"></output></p>

</body>

</html>

Now, if the user goes to the page, the browser will cache the files and make them available even when the user is offline.

The one aspect of this document that is beyond the scope of the specification is how to actually configure the various application and web servers to serve these application cache files. In the following section I will provide basic configuration steps that can be used for a variety of servers.

WebSphere Application Server 8.0.X (WAS 8)

In WAS 8, the admin console allows administrators to configure additional MIME types based upon file extensions. To configure application cache for the example above, the MIME type would be configured as "text/cache-manifest" and the extension would be ".appcache".

WAS CE leverages Tomcat for it's Webcontainer implementation. As part of Tomcat's configuration support, there is a global web.xml that provides configuration for various aspects of the webcontainer. One of these configuration options is for mime-mappings. To configure application cache for the example above, the mime-type would be confgured as "text/cache-manifest" and the extension would be ".appcache".

Apache has the ability to configure mime types in many different ways (see this link, for more details). In this document, I will denote what I think is simplest which is the .htaccess file. The .htaccess file is a web resource that can be included in the same directory as the application manifest. To configure the webserver to send the appropriate content type header for appcache, the following directive would be used.

Black Hat [Black hat conference] was in Vegas was last week, so it made me wonder where people see mobile application development within the wider lens of web application development [XForce news] . And while there is still plenty to be done, technology shifts can be a great opportunity to rethink things and with mobile applications.... less may be more.

The push and pull of identity. User names and passwords are great until you have hundreds ofthem and this is the reality today with identity silos. When I worked on WebServices and in particular, WS-Federation we anticipated the need for bridging across these silos of identity. New waves are on the horizon as “social networks” and federated corporate id’s are intermixed and we are now seeing hybrid identities find their way to mobile devices and mobile applications. For some classes of mobile apps, it may be advantageous to let someone else manage the identity data ( for example, let a third party IDP manage the username & password and establish the first link in the security chain).The proliferation ofinternetservices (e. g.Facebook & Twitter) and the emergence of Open source Identity provider mechanisms like OpenId mean users want to merge their multiple identitiesand the line distinguishing a "social" Id (xxx@gmail.com ) and a “private” id (xxx@us.ibm.com) has begun to blur. This will present challenges to IT organizations that have not anticipated this change as these new mobile applications extend beyond traditional enterprise boundaries and embrace third party identity providers. The areas where application developers should concentrate on enhancing or controlling authentication and authorization is where reliance on 3rd party providers (having someone else handle end user authentication) has to be done in compliance with regulatory concerns aroundprivacy and credit. In regulated areas, the duediligence involved in compliance for maintaining privacy and user identity protection through establishing relationships with themanaging entities might be more difficult and costly than managing the user data yourself.I worked with a volunteer effort supporting the UN recently and we were looking at a campaign where I learned that at the end of the year there will be 7 billion people on the planet. Application owners should consider whether theyreally need to or want to track individuals on every possible mobile device that has been or will be created. That's a lot of information to protect. Instead of creating a new identity silo, it may be a better investment to review the fundamentals for establishing a long running relationship with your customer, whoever that is.

I attended a Workshop recently sponsored by the W3C (Identity in the Browser) where the goal was to look at the state of browser managed identities and the audience included a wide range of browser providers and interested security practitioners with a lot of energy. So there is new hope for navigating identity on the web. The topics for managing identity at the workshop crossed between "standard" web and mobile environments. It is evident that mobile apps will extend existing web patterns and include third party IDPs and web techniques like cookies (with appropriate protection hopefully -- XForce proposal on secure wireless) for collecting relevant stats on traffic and preference. A well designed layered security model where "re-authentication" or authorization of mobile users is triggered when an end user needs to pass from a public to a high value information domain can be a bridge between worlds and not only improve mobile application security but all application security. After all, managing identity & passwords isonly the first step to developing a digital profile for end users. A good investment for mobile development efforts is to rethink how application services are offered and to start to think about different profiles for "low value" and high value services tailored to augment existing account affinity and enabling a differentiation of requests by valued-repeatcustomers from those of random individuals or “bots”. A layered defense will enable the staging of services from entry level to higher value and take into account other factors of the mobile device ( location, biometrics, voice recognition) which can be used creatively to help you provide better overall service and manage the data that's most important to your business.

One of the hardest problems with mobile is the coexistenceof things like “Angry Birds” on the same device as my HR test resultsand my financial data. Until Angry Birds becomes an Olympic event, I don't think I have to worry much about how I do. My HR results on the other hand, I'm a little worried about, and having people be able to hack into my banking app and get my financial data....well you can see its a continuum of low to high value data and the costs and risk mitigation strategies need to be in place for the appropriate local protection ( if data is stored on the phone) and access. The expression of access policies and rules is not new to mobile application development [Polcy & Rules]. Many businesses already have strategies for web hosting, and many of the low to mid value mobile apps are fine running within these risk mitigation strategies. In many cases the scaling issues particularly around dynamic web content may be the first challenge for Mobile IT support. The high value data is where the mobile space gets interesting. For the highest value data you've got to look at the overall trust model including the device OS and be responsive to new threats like the ability to "jailbreak" a phone. Beginning with our feature pack, the focus is on educating and raising the awareness with regard to some of the risks involved in using dynamic web technologies. The tools and strategies to use to mitigate the threats both on laptops and mobile devices [Web 2.0 security ] are areas where we draw on the experience of our research teams to help us respond to these ever-evolving threats. [ more security pointers] What are you seeing? Give us your feedback.

On July 22, Rational Application Developer released Version8.0.3 Interim Fix 1. Source tools for mobile web application development and the Mobile Browser Simulator, formerly available as beta-level functionality, are updated and supported. Support for Dojo 1.3.2, 1.4.1, 1.5, and 1.7 Beta1 is provided. Come over to the Rational Application Developer developerWorks wiki to check it out as well as our latest demos.

Dojo Mobile takes an important role in Web 2.0 and Mobile Feature Pack to provide a powerful mobile application development environment. It has a lot of lightweight UI widgets, which smooth over browser differences not only for mobile devices such as iPhone, Android and BlackBerry but also for desktop browsers through the compatibility module. The existing widgets in Dojo Mobile 1.6 are already introduced in various ways, for example, in a good developerWorks article "Get started with Dojo Mobile 1.6" referred to in the previous post. In this post, I'd like to further expand on the new widgets that are part the Web 2.0 and Mobile Feature Pack and which will also be part of the Dojo Mobile 1.7 upcoming release.

SwapView (formerly FlippableView)

SwapView widget, formerly FlippableView widget but has been renamed, provides the capability to switch pages by swiping a view left and right.

Carousel widget displays images in a carousel style based on SwapView and PageIndicator widgets. It can use Dojo Data API to load image list data. The following sample has two Carousel widgets, and when you select an image in the upper carousel, the lower one loads image list depending on the selection and displays them dynamically through Dojo Data API.

EdgeToEdgeDataList and RoundRectDataList widgets are subclasses of simple EdgeToEdgeList and RoundRectangleList widgets respectively., They have the ability to use Dojo Data API to populate its data. You can easily switch data store and add/remove items as the following sample shows.

SpinWheel widget shows spinning wheels for users to select data. For the most popular usage, there are two sub widgets: one is SpinWheelDataPicker widget to show the date picker and the other is SpinWheeTimePicker widget to show the time picker in a spinning wheel style.

And in tablet size or desktop screen size, it shows a dialog with Tooltip widget as shown below.

I have just discussed new widgets, but there are a lot of other new features in Web 2.0 and Mobile Feature Pack and Dojo Mobile 1.7 such as new BlackBerry theme, new transition effects (cover, reveal, zoom in/out, swirl, etc), many widget enhancements, and so on. All these new widgets and other new features are available on Web 2.0 and Mobile Feature Pack as well as Dojo Mobile 1.7 which will be released soon, so please give it a try and enjoy it!

Thank you to all who attended thewebminar last week titled “Overview of the WebSphere Application Server Web 2.0 and Mobile Feature Pack“ , hosted by the Global WebSphere Community (GWC) . If you submitted aquestion during the webcast, please check the GWC's WebSphereand Mobile forum over the following weeks for the answers to yourquestion as well as new conversations.