Deliver an exceptional mobile web experience using WebSphere Portal and IBM Worklight, Part 4: Using IBM Web Experience Factory with Worklight to create hybrid applications

IBM® Web Experience Factory is a powerful model-based tool for rapidly developing custom portlets and web applications that are optimized for mobile and desktop devices. IBM Worklight® is a complete mobile enterprise application platform for delivering native, hybrid, and web applications. This article shows how you can use the two together to easily build a highly functional application that can be installed on a mobile device, providing transactional functionality along with access to device features, such as the camera. The resulting example application could be part of a complete multi-channel web site that is built and managed using IBM WebSphere® Portal.


Jonathan Booth, Senior Architect, IBM Web Experience Factory and Portal Tooling, IBM China

Author photoJonathan Booth is lead architect for Web Experience Factory and WebSphere Portal tooling. He was the lead architect at Bowstreet, Inc. prior to its acquisition by IBM in 2005. Prior to that he was the lead architect for Lotus Freelance Graphics.

Jaye Fitzgerald, Technical Lead for Mobile Portal Accelerator, IBM China

Author photoJaye Fitzgerald is the technical lead for Mobile Portal Accelerator at IBM's Littleton Development Lab. He has contributed to Portal's mobile products and has delivered consulting services as a member of the WebSphere Portal lab services team. Jaye has presented WebSphere Portal's mobile offerings at Lotusphere and the IBM Exceptional Web Experience Conferences.

16 January 2013

Also available in Japanese


With the exploding mobile device market, organizations are faced with the task of extending their web sites to a new world that includes hundreds of types of mobile and Internet-connected devices. The first article in this series described three basic approaches to mobile application development: native, pure web, and hybrid. The pure web application approach using the device's browser is the simplest, and for many scenarios it is an ideal way to reach a range of mobile and desktop devices.

However, there are just as many scenarios where it's desirable to have an application that is installed onto a mobile device and that has complete access to the device’s functions. The earlier article discusses how a hybrid approach can provide the “best of both worlds” benefits of the pure web and native approaches. By combining IBM WebSphere Portal with IBM Worklight V5.0, you can create an application that's installed on a mobile device, provides access to a complete web site, and includes access to device functions. Part 1 describes the basic steps for building this kind of hybrid application.

This article continues the application development piece of this story. When developing a hybrid application, much of the application is often made up of the same type of functionality that you'd have in any web application: you need to access data and services, and you need to provide attractive user interface screens with forms, views, user interaction elements, and so forth. In addition to that core application functionality, you will have selected places where you need access to native device functions.

For example, many organizations have a need to provide applications that use a device camera as part of the application; a bank might want to let customers deposit a check by taking a picture of it, an insurance company might want to let a user take a picture of an accident scene, or (as in the example used in this article) a city government might want to let citizens report an issue such as graffiti or a pothole with an accompanying photo. In all of these situations, camera access is typically just one piece of the entire application.

This article shows the development of a complete example hybrid application, including access to data and services, all the mobile user interface screens, and the hybrid functionality for accessing the device camera.

Solution components

The components and other considerations involved in creating the example described here include:

Alternative tools

The purpose of this article is to describe the use of IBM Web Experience Factory and IBM Worklight Developers Edition V5.0 for building and deploying a hybrid application to IBM WebSphere Portal V8.0. Other IBM products, such as IBM Rational® Application Developer, might also fit your requirements for building web or hybrid applications.

  • IBM Web Experience Factory V8.0

    IBM Web Experience Factory is a development tool and framework for the rapid development of multi-channel portlets and web applications that can run on desktop browsers, tablets, and smartphones. It uses a model-based development approach, enabling developers of any skill level to rapidly create highly functional applications with a great-looking user experience.

    See the IBM Web Experience Factory product information for complete details on product features, and the wiki for documentation and additional information.

  • IBM Worklight V5.0

    The IBM Worklight platform is a set of components for managing the complete lifecycle of native, hybrid, and web applications, delivered to multiple mobile platforms, including iOS, Android, BlackBerry, and Windows® Phone. IBM Worklight Developer Edition V5.0 is the development environment you will use in this article to build a sample to access WebSphere Portal.

    See Getting started with Worklight for information on using IBM Worklight V5.0.

  • IBM WebSphere Portal

    WebSphere Portal is the market leader in delivering a web site framework for both desktop and mobile devices. WebSphere Portal provides site navigation and branding to customize your site to your business. The framework can deliver targeted content with analytics to measure your site's effectiveness. Role-based access and context to your web sites is another key feature. WebSphere Portal's strengths derive from its foundation in IBM WebSphere Application Server. WebSphere Portal has a rich list of features that include security, integrated web content management, personalization, virtual portals, and more. WebSphere Portal's value is aggregation of applications on your site with this backdrop of features.

    See the WebSphere Portal product information for complete details on product features.

  • Topology choices

    There are server topology options to consider when planning your Worklight and WebSphere Portal deployment. A proxy will be required for IBM Worklight Server to access WebSphere Portal. This sample has been tested with the WebSphere Portal and Worklight servers co-located on the same development machine. You will see in Listing 2 that the IP address in the WebSphere Portal URL is used to access the initial page. A proxy will be needed to deploy this sample when the servers are not on the same system. IBM Worklight education module 45 discusses how to use a remote website, such as one hosted on a WebSphere Portal server.


To follow the instructions in this article to build the example mobile hybrid application described, you will need to have these components properly installed and operational:

Eclipse with Oracle JRE

Oracle Java JRE is a prerequisite for the Android SDK. Once installed, you can configure your Eclipse instance to use the JRE by navigating to Window > Preferences > Java > Installed JREs.

  • IBM WebSphere Portal (V8.0 recommended)

    The information included here about including Worklight JavaScript™ code in the portal theme applies to WebSphere Portal V8.0. However, the Web Experience Factory sample application can run on any of the server platforms supported by Web Experience Factory V8.0, which also include IBM WebSphere Portal V7 .0, IBM WebSphere Application Server V7, V8 and V8.5; for developer testing only, you can also use IBM WebSphere Application Server Community Edition or Apache Tomcat.

    For more information, see the IBM WebSphere Portal V8 Product Documentation.

  • Eclipse

    This sample is based on Eclipse 3.7.2 (Indigo). This sample was tested with Eclipse 3.7.2 Java™ EE Developers but Classic or Java Developers should work too.

  • Android SDK

    The next step after you have Eclipse installed is to add the Android SDK. This sample was tested with Android SDK 2.3.3 (API 10).

Worklight version requirement

This exercise requires IBM Worklight V5.0 or later and will not work with earlier versions.

  • IBM Worklight 5.0 plugin for Eclipse

    The Worklight plugin for Eclipse is the component that enables you to build the IBM Worklight hybrid application. An evaluation version is available in the Resources section of the IBM Worklight documentation.

    Worklight installs the server as part of Eclipse. You might need to update eclipse.ini to change the port from 8080 to another value; for example, 8085 . The Worklight Server automatically starts when you start Eclipse. Listing 1 shows example eclipse.ini file content with -Dworklight_port set.

    Listing 1. Example eclipse.ini
  • WebDAV client

    There are two options for integrating the Worklight JavaScript code. You can either update the WebSphere Portal theme with the Worklight JavaScript, or you can include the files in the Web Experience Factory application. If you decide on the first option, you will need a WebDAV client; if you update the Web Experience Factory application, WebDAV is not needed. Both options will be discussed later in this article. Part 1 of this series used AnyClient as the WebDAV software to update the theme. You can see that article for details on updating the WebSphere Portal theme if you use that option. You can use any WebDAV client that WebSphere Portal supports.

    If you decide to update the WebSphere Portal theme, be sure to review the article on Connecting to the Portal WebDAV with 8.0.

  • Custom theme

    You need to create your own custom theme before applying the Worklight JavaScript to your theme. Creating a copy of the WebSphere Portal V8.0 theme ensures that your theme has all the required elements for the theme to function, and that changes will not be overwritten by a fixpack. Do not modify the WebSphere Portal V8.0 theme directly because this theme can be updated by service fix packs. To create a new custom theme, follow the instructions outlined in the article Create a copy of the theme

IBM Web Experience Factory and hybrid applications

Get Worklight now

Download IBM Worklight Developer Edition 5.0 now at no cost, and with no expiration date!

IBM Web Experience Factory provides support for building mobile and multi-channel web applications that run on WebSphere Portal or WebSphere Application Server. The tool's model-based development approach enables very rapid development with minimal coding. Typically this is done using a "data-driven" approach: you point to some kind of data source, select the UI pattern you want to use, configure various options using a point-and-click interface, and the application is generated for you. You can then use any of the customization tools in Web Experience Factory to refine the appearance and functionality as much as you want.

Web Experience Factory also includes multi-channel support, enabling you develop a single source model that generates optimized renderings for different device types (smartphone, tablet, and desktop, for example). This lets you provide an optimal experience for any device while maintaining a single source code base. (See Resources for more information on Web Experience Factory mobile and multi-channel capabilities.)

You can now use Worklight along with the mobile and multi-channel support of Web Experience Factory to build hybrid applications. These hybrid applications are installed onto a device and have the ability to access native device functions, such as camera and notifications. With a hybrid approach, you can use all the mobile web features of Web Experience Factory to build the UI and data access pieces of your application. Then, with a little bit of JavaScript, you can access device features (such as the camera) that aren't available with a pure mobile web application. Plus, you can install the application to a device from an app store or market.

When you use Web Experience Factory to build this type of hybrid application, the application is installed on the device, but it's primarily a server-based hybrid application; nearly all of the functionality is generated by Web Experience Factory and loaded from the server. The application that's installed onto the device is a shell containing a browser window, but without any of the browser UI so users can't really tell it's a browser. The browser window points to the server where the Web Experience Factory application is running.

This hybrid approach, along with the pure mobile web application approach, enables you to meet a wide range of mobile application needs, all built using standards-based web technologies. And when you use the Web Experience Factory model-based tooling, you get a number of additional benefits:

  • You can develop applications very quickly with little to no coding, using a data-driven approach in which the application UI is generated automatically from your data sources.
  • You can use the multi-channel profiling feature of Web Experience Factory to generate different variations for different device types. This feature has proven very popular with users as they are faced with the dizzying array of mobile devices that are released on a continuous basis.
  • You have easy access to a wide variety of data sources (database, web services, REST services, Domino, SAP, and so on) using the point-and-click connectors (builders) of Web Experience Factory.

Developing for mobile applications and complete mobile web sites

When you develop with Web Experience Factory, any application model can run either as a portlet on WebSphere Portal, as a standalone web application, or both. This means that you can use the same tool and the same application code or models for both environments. If all you need is a single mobile application, you can deploy a Web Experience Factory model to WebSphere Application Server; when you need a complete mobile or multi-channel web site, your models are deployed as portlets on WebSphere Portal.

Sample application

The sample application included for use in this exercise, called Citizen Reports, is an application for reporting issues — such as graffiti, potholes, sign damage, and so on — to a city government. The application is installed onto a mobile device, and lets users file a new report and take a photo of the issue they're reporting (Figure 1). Users can also view existing reports that have been filed and see their status. Data about reports is stored in a database on the server.

Figure 1. Main screen and views of existing reports
Figure 1. Main screen and views of existing reports

To create a new report, tap on File New Report (Figure 1, first panel) to display the form for entering new report data (Figure 2, first panel). The entry automatically includes geo-tagging information (latitude and longitude) obtained from the device's GPS. The camera is invoked by tapping Take Photo. Once a picture is taken and approved, a thumbnail is displayed (Figure 2, second panel) and the remaining fields can be filled out. (Figure 2, third panel).

Figure 2. File New Report with picture
Figure 2. File New Report with picture

When the form is completed, the form is submitted. The image and the form fields are sent to the server, the database is updated, and the new report including the image is displayed. The updated list of reports from the database now includes the new report (Figure 3, third panel).

Figure 3. New Report with Picture added
Figure 3. New Report with Picture added

Using a hybrid application in the context of a portal-managed city government web site

The screen captures in Figure 4 show how the same Web Experience Factory model can be deployed as part of a complete web site that is built and managed using WebSphere Portal. The web site includes many different applications and web content. These images show a native application running on an Android device in which the application provides access to a complete government web site hosted by WebSphere Portal. When you navigate to the Citizen Reports portlet, the hybrid camera features are available.

Figure 4. Hybrid Android Citizens Reports application
Figure 4. Hybrid Android Citizens Reports application

Hybrid application architecture

This application is made up of two distinct pieces:

  • Hybrid shell application: Built using Worklight and installed onto the mobile device and deployed to a Worklight server.
  • Server-hosted application: Built using Web Experience Factory and deployed on WebSphere Portal or WebSphere Application Server.

Figure 5 shows the overall deployment topology of WebSphere Portal when used with Worklight. The installed hybrid application is at the top right, and it accesses both the portal server and the Worklight server. The pure web clients (desktop, tablet, smartphone) access only the portal server. Notice that the portal server and portlets are the same for the pure web clients and the hybrid client. However, when running in the context of the hybrid client, portlets can include additional native device functions. In this sample, the Citizen Reports portlet is available to all the clients, but it has the additional camera functionality when used in the context of the hybrid application.

Figure 5. WebSphere Portal and Worklight topology
Figure 5. WebSphere Portal and Worklight topology

How the Web Experience Factory application is built

The Citizen Reports application is built in Web Experience Factory using the provider/consumer model architecture which consists of these two layers:

  • The provider or data access model provides access to data and services.
  • The consumer or UI model uses the provider model to access data and services.

With this architecture, the UI model is built without any knowledge of the particular back end data sources being used; all the details of the back end data are handled by the provider model, which presents a clean service interface used by the consumer model. The provider layer can perform any necessary data manipulations and can access multiple services or data sources. Figure 6 shows how the provider and consumer models are combined to construct the application.

Figure 6. Web Experience Factory provider/consumer architecture
Figure 6. Web Experience Factory provider/consumer architecture

Data access and the service provider model

In the example provider model (CitizenReportProvider.model) a database table is used to store the report data.

The SQL Table Create builder in this model does all the work of generating the complete service provider functionality. This builder is used both to create the table, if necessary, and to provide CRUD (create, read, update, and delete) access to the database table. It will also pre-populate the table from a small XML file when the table is created. The list of column names is taken from the XML file containing the initial sample data.

This is an example of how you can easily access your back end data using Web Experience Factory builders. There are similar builders for accessing other types of data sources: web services, REST services, Lotus Domino, SAP, and so on.

One of the features you get with any service provider model in Web Experience Factory is the testing support. With a single checkbox, you can automatically generate a complete test harness for testing all of the operations of the service interface. With this testing support you can “run” the provider model to see a page with links for testing all of the operations.

Figure 7 shows the main page of the generated test harness, with links for testing each of the operations. Figure 8 shows the result of testing the listReports operation. You can see all the data from the sample database table.

Figure 7. Generated test harness page
Figure 7. Generated test harness page
Figure 8. Generated Test Harness list page
Figure 8. Generated Test Harness list page

User interface and service consumer model

The consumer, or user interface model in this example (CitizenReport.model), is where all the application UI is built. This model references the service interface defined in the provider model, and it is insulated from knowing anything about the implementation of the provider. In this example, three of the high-level UI builders of Web Experience Factory are used to generate all the application screens. The data views and forms are automatically generated based on the schema from the provider service. This demonstrates some of the rapid data-driven development features of Web Experience Factory:

  • The Page Navigation builder is used to generate the initial screen (mainMenu) with the actions for View Citizen Reports and Create New Report. Each action has an associated icon.
  • The View and Form builder generates the list and detail screens for viewing existing reports, using the schemas for the listReports and retrieveReports service operations. This builder also generates all the supporting code for retrieving and rendering the data using the desired formatting. It can also generate “update” functionality, if you desire.
  • The Input Form builder generates the form for creating a new report, using the schema for the createReports service operation. The builder also generates all the supporting code for storing and validating the form inputs and then calling the service operation with the collected inputs.

After those three builders are used to generate all the screens and the supporting code, other builders are then added to customize and enhance the application. Here are some of the key builders used for this customization:

  • The Theme builder is used to apply the mobile_gray UI theme to give the application a mobile look and feel. The same builder also uses the option for Override Theme Properties to apply a CSS file used to tweak the styles in the application. Know that the “theme” referred to here is a Web Experience Factory theme for controlling the look and feel within a portlet; this is distinct from the portal theme that controls the overall portal navigation, look, and feel.
  • The Data Layout builder is applied to the list page and converts the display into a nice-looking mobile display style, including a small thumbnail picture for each report. This builder can be used to generate a wide variety of displays using predefined data layout templates. Each layout template is based on a snippet of HTML with placeholder locations for data fields; in the Data Layout section of the builder you can see the placeholders in the Name column and the assigned field names in the Value column. Figure 9 below show the assignment of fields into locations for the selected layout.
    Figure 9. Data Layout builder field assignments
    Figure 9. Data Layout builder field assignments
  • The Data Field Settings builder (Figure 10) is used to control the appearance and behavior of all the data fields in the application. This builder references a shared Rich Data Definition library that defines all the appearance and behavior — formatting, validation, edit type, pickers, lookup tables, and so on — for common field types. This feature lets you define all those settings in one place; all the fields on all the pages in all your portlets will automatically take on the desired detailed behavior. In the Data Field Settings builder, you select the field type, and you can set other options, such as labels, sorting, visibility, and lookup tables.
    Figure 10. Data Field Settings builder
    Figure 10. Data Field Settings builder
  • The Geolocation builder (Figure 11) is used to provide access to the device GPS location so that new reports are automatically geo-tagged with the latitude and longitude where the report was filed. This geolocation support doesn't have any Worklight or hybrid dependency; it's implemented purely using the geolocation support of HTML5. The Client Event Handler builder is used to listen for the GeoLocationClient event; when the event is received, the latitude and longitude are set into hidden fields and into text fields for display.
    Figure 11. Geolocation builder
    Figure 11. Geolocation builder

Other builders such as HTML Data Layout, Display Manager, Data Field Modifier, and Attribute Setter are used to further customize the UI of the application.

This sample also includes support for deleting records. This is done with a simple Action List, which is invoked using a Button builder applied to the Details page.

With the builders described so far, you have a nice-looking, highly functional mobile web application that lets users view, create, and delete citizen report records stored in a database. Next, you will see how to access the device camera using the Worklight libraries. There are two parts to this: first, you need to make the JavaScript libraries available to your application, and then you need to add the appropriate JavaScript code to invoke the camera and upload the photo file to the server.

Making the Worklight and JavaScript libraries available to the application

The application access to native device functions such as the camera is done using the JavaScript APIs provided by Worklight. These APIs include Worklight APIs along with the Cordova open source library APIs. These JavaScript API libraries need to be loaded from the server-based pages of the application. To do this, you can either include the JavaScript libraries in the application WAR file (as is done in this sample), or you can include the JavaScript files in a WebSphere Portal theme, as described here. In this sample, all of these JavaScript files are under the WebContent/worklight folder of the project. Beneath that, there are folders for common and wlclient, corresponding to folders you have in a Worklight project. To include these files in a model, there is an HTML page, worklight_support.html, containing script tag references to all the needed JavaScript files. This worklight_support.html file is inserted into model pages using two builders:

  • An Imported Page builder creates a model page, worklight_js, from the worklight_support.html file.
  • An Inserted Page builder inserts the imported page into the HEAD tag of all the other pages in the model. It uses the Advanced option of the Page Location input to do this.

Using JavaScript and the Worklight API to access the device camera and upload the image

All the JavaScript used to access the Worklight APIs is in the file camera_support.js, brought into the model with the Client JavaScript builder. There are just two calls to functions in that file:

  • The action for the Take Photo button calls the function takePicture. This is specified in the Button builder.
  • On the Submit button, the Attribute Setter builder prepends a call to the function uploadPhoto, which will be called just before the input form is submitted.

The takePicture function puts the device into camera mode by calling the method getPicture (Listing 2)

Listing 2. getPicture, onTakePictureFail, 
	{ quality: 50, destinationType: Camera.DestinationType.FILE_URI });

The onTakePictureSuccess function is a callback method, called after the picture is taken and confirmed by the user. This function saves the image URL (which is a local URL on the device) into a JavaScript variable capturedImageURL, then displays a thumbnail of the image by setting the "src" for an <img> tag in the HTML.

The uploadPhoto function first sets a few hidden input values in the form, creates a FileUploadOptions object with some properties set, then calls the upload method to upload the image to the server (Listing 3).

Listing 3. upload
ft.upload(capturedImageURL, uploadUrl, onUploadSuccess, onUploadFail, options);

The uploadUrl value is a URL to the uploadAction Action List in the model. To obtain that URL, a Link builder referencing uploadAction is used in the model. The resulting tag is hidden (its style is set to display:none), but the JavaScript code uses it to get the URL with the line shown in Listing 4.

Listing 4. Set variable uploadUrl
var uploadUrl = document.getElementById("upload_link").href;

There's one more piece involved in enabling the file upload: the Java scriptlet shown in Listing 5 is inserted into the page using the Text builder. This call to allowFileUpload tells the server to enable upload actions for this session.

Listing 5. allowFileUpload
<% com.bowstreet.webapp.util.FileUpload.allowFileUpload(webAppAccess); %>

Installing and running the Web Experience Factory application

To install and run the Web Experience Factory application:

  1. Create a Web Experience Factory project that includes the mobile and Dojo feature sets, and publish it to your WebSphere Portal server.
  2. Right-click on the project and choose Import > Web Experience Factory Archive, and select the sample ZIP file.
  3. Open the CitizenReportProvider model in the samples/worklight folder. Open the SQL Table Create builder and click Fetch Data Source Names. From the drop-down menu for SQL DataSource, select jdbc/CloudscapeForWEF. If this data source doesn't exist, it will offer to create it for you. Scroll down in the builder and click the Create Table button. This should create and populate the database table.
  4. Open and run the CitizenReport model. Make sure you can view existing reports from the database.
  5. For testing in WebSphere Portal, publish the project to your test portal server, and add the portlet to a page.

At this point, you can run the model, but without the camera access. If you click the Take Photo button, you'll see a message indicating that you need to run the application in the context of an installed app. In the next section, you will see how to use Worklight to create an Android native shell application that points to your server-based application.

Building and running the Android native shell using Worklight Studio

You will build the native shell application with IBM Worklight Studio. The steps to do this are in Part 1 of this series. Complete all the steps listed there and continue with the additional steps for this sample from here.

This sample builds an Android application, but the process for Apple iOS application would be very similar. Once you've created the Worklight application as described in Part 1, you will want to make changes to the application permissions and the URL to the Web Experience Factory application deployed on WebSphere Portal.

You need to add permissions to the hybrid application. To do this, navigate in the Worklight application to the AndroidManifest.xml file. This example contains a Worklight application called WLWEFCitizen in the Worklight project. Navigate to WLWEFCitizen > android > native and open AndroidManifest.xml. Click on the fifth tab at the bottom of the file edit area and add the permissions shown in Listing 6.

Listing 6. Add Permissions to AndroidManifest.xml
	<uses-permission android:name="android.permission.CAMERA" />
	<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
	<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
	<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
Figure 12. Android permissions in AndroidManifest.xml
Figure 12. Android permissions in AndroidManifest.xml

The other change mentioned earlier is updating the URL in the Java code of the application.

Within Eclipse, open the Java class that initializes the application, located at \WLPortal\apps\WLWEFCitizen\android\native\src\com\WLWEFCitizen\ (Listing 7).

Listing 7. Contents of
package com.WLWEFCitizen;

import android.os.Bundle;

import com.worklight.androidgap.WLDroidGap;

public class WLWEFCitizen extends WLDroidGap {
	public void onCreate(Bundle savedInstanceState) {
	   <Use default ProvisioningDelegateImpl class or replace 
	   with your IProvisioningDelegate implementation>);

IP address

The IP address in this example should be the address of the WebSphere Portal server you want to render in the hybrid application.

The application uses this class to forward control to the HTML page located at \WLWEFCitizen\apps\WLWEFCitizen\common\WLWEFCitizen.html.

This file needs to be changed so it will forward to the server address and port. You can use the URL for the standalone Web Experience Factory model, or you can use the WebSphere Portal URL and access the application as a portlet. To do this, you can change the onCreate method to load the server URL and utilize the cookie manager (Listing 8).

Listing 8. onCreate method utilizing the WebSphere Portal URL
public void onCreate(Bundle savedInstanceState) {
   // For accessing via WebSphere Portal:
   // super.loadUrl("",false);
   // For the standalone Web Experience Factory model:

Be sure to add the import dependencies for the CookieSyncManager and CookieManager (Listing 9).

Listing 9. Import dependencies
import android.webkit.CookieSyncManager;
import android.webkit.CookieManager;

Because of the redirects, one other method needs to be defined to get authenticated pages to work. Add the loadUrl method shown in Listing 10. The final contents of is shown in Listing 11.

Listing 10. Add this loadUrl method
public void loadUrl(String url) {
Listing 11. The final contents of
package com.WLWEFCitizen;

import android.os.Bundle;
import android.webkit.CookieSyncManager;
import android.webkit.CookieManager;

import com.worklight.androidgap.WLDroidGap;

public class WLWEFCitizen extends WLDroidGap {
	public void onCreate(Bundle savedInstanceState) {
	   // For accessing via WebSphere Portal:
	   // super.loadUrl("",false);
	   // For the standalone Web Experience Factory model:
	public void loadUrl(String url) {
Figure 13. IBM Web Experience Factory application URL in IBM Worklight application
Figure 13. IBM Web Experience Factory application URL in IBM Worklight application

Testing the hybrid application with the Android Emulator

Now that you have adapted the hybrid framework with permissions and the application URL, you can test the sample using the Android emulator. To do this, you will once again build and deploy the application. You can do this by right-clicking on the application again and selecting Build All and Deploy. You can see the progress in the lower right status banner in Eclipse. When the process completes, right-click on WLWEFWLWEFCitizenAndroid and select Run As... > Android Application. This will launch the Android Emulator and the application will display your WebSphere Portal.

After the hybrid application has updated or installed the Citizen Reports portal application, it will take a few seconds for the device settings to load. You will see it display at the top of the page (Figure 14).

Figure 14. IBM Worklight application displaying the Web Experience Factory Citizen Reports application
Figure 14. IBM Worklight application displaying the Web Experience Factory Citizen Reports application


Using IBM Worklight V5.0 and the server-hosted hybrid mode described here, you can combine the mobile application features of Worklight with the unique benefits of IBM WebSphere Portal and IBM Web Experience Factory:

  • IBM WebSphere Portal provides you the premier framework for creating and managing complete web sites that include any number of applications and content and can be accessed from any mobile or desktop device.
  • IBM Web Experience Factory gives you very rapid development of complete mobile and multi-channel applications using model-based, data-driven tools.
  • IBM Worklight gets you applications that can be installed onto a device (for example, from an app store), with application access to native device features, notifications, and so on.

By using Web Experience Factory for your core application development, you can have a single rapid development tool and a single code base (models) for:

  • Hybrid and pure web applications
  • Desktop and mobile devices
  • Deploying to WebSphere Portal and WebSphere Application Server.


Sample applicationworklight_citizen_report.zip431 KB



Get products and technologies


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Mobile development on developerWorks

Zone=Mobile development, WebSphere, Lotus
ArticleTitle=Deliver an exceptional mobile web experience using WebSphere Portal and IBM Worklight, Part 4: Using IBM Web Experience Factory with Worklight to create hybrid applications