Deliver an exceptional mobile web experience using WebSphere Portal and IBM Worklight V5.0, Part 2: Integrating multiple device support for WebSphere Portal pages

IBM WebSphere Portal and IBM’s Exceptional Web Experience solutions have been the market leader in web experience for more than a decade. IBM Worklight is a new, complete mobile enterprise application platform for delivering native, hybrid, and web applications. This article explains how to enable support for both Android and iOS applications during the enablement of WebSphere Portal and Worklight integration. This exercise augments the sample presented in Part 1 and demonstrates how to build an iOS application and dynamically include the appropriate Worklight resources.

This article applies to IBM Worklight V5.x. Another version of this article is available for IBM Worklight V6.0.

Share:

Jonathan Lidaka, WebSphere Portal Front-end Engineer, IBM

Jon Lidaka is a Front-end engineer based at IBM's Research Triangle Park Development Lab.During his time in Portal development he has primarily contributed to theme development, focusing on accessibility and globalization, and to various components including the administration portlets and Web application integrator. Currently he leads the mobile development mission for Portal. Jon has spoken at multiple IBM conferences on user interface design and optimizing Portal themes for mobile devices.



07 August 2013 (First published 21 November 2012)

Also available in Chinese Russian Portuguese Spanish

Introduction

Get Worklight now

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

The IBM Worklight platform enables you to create applications for many device environments, including iOS, Android, and Blackberry. Through the use of technology like Apache Cordova, which Worklight uses and ships, you can call native features via JavaScript™ from your web markup.

This article guides you through the process of creating a hybrid iOS application that integrates with IBM WebSphere Portal. It discusses the process for determining the device that has accessed the portal, and for including the appropriate resources — for either for iOS or Android — to enable support for native capabilities within the application.

Prerequisites

This article augments the information that was presented in Part 1 of this series. Complete the sample solution from Part 1 before continuing through the steps outlined here.

In addition to the prerequisites defined in Part 1, you must have Apple Xcode installed to build the sample hybrid application described here. This article builds upon the Worklight hybrid application with support for the Apple iPhone. This sample was tested with Apple Xcode version 4.4.1 and is only available for Apple OS X.


Create the iOS environment in Worklight

  1. To create a new environment for the iPhone in Worklight, open the Project Explorer and right-click on WLPortalApp in the apps folder, then select New > Worklight Environment (Figure 1).
    Figure 1. Create a new Worklight environment
    Figure 1. Create a new Worklight environment
  2. The New Worklight Environment panel displays (Figure 2). For this particular sample, select iPhone. If you needed to create environments for other iOS devices, such as iPad, this is the panel where you would specify those additional options. Click Finish.
    Figure 2. Worklight environment displayed in Eclipse
    Figure 2. Worklight environment displayed in Eclipse
  3. Worklight Studio updates the project with a native application for iPhone devices (Figure 3).
    Figure 3. The iPhone native app is added to the project
    Figure 3. The iPhone native app is added to the project
  4. Next, open the main class file for the iOS native application (Figure 4). This file is located at \WLPortal\apps\WLPortalApp\iPhone\native\classes\WLPortalApp.m. This is the file that will be modified, similar to the WLPortalApp.java file in Part 1. All iOS applications are written in Objective-C (see Resources).
    Figure 4. The main class file for the iOS native application
    Figure 4. The main class file for the iOS native application
  5. To display the portal within the iOS application, the launcher method will need to be modified to load the portal URL. The method in Worklight version 5.0.5 that will be modified is called didFinishLaunchingWithOptions (Listing 1a), and in version 5.0.6 it is called didFinishWLNativeInit (Listing 1b). Basically, the method launches an internal HTML file that is created by default.
    Listing 1a. didFinishLaunchingWithOptions method in WLPortalApp.m with Worklight version 5.0.5
    /**
     * This is main kick off after the app inits, the views and Settings are setup here.
     */
    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:
    (NSDictionary *)launchOptions 
    {
        BOOL ret = [super application:application didFinishLaunchingWithOptions:
    launchOptions];
       
        /*
         * If you need to do any extra app-specific initialization, you can do it here.
         **/
        
        return ret;
        }
    Listing 1b. didFinishLaunchingWithOptions method in WLPortalApp.m with Worklight version 5.0.6
    /**
     * This is main kick off after the app inits, the views and Settings are setup here. 
     */
    -(void) didFinishWLNativeInit:(NSNotification *)notification {
        /*
         * If you need to do any extra app-specific initialization, you can do it here.
         * Note: At this point webview is available.
         **/
    }
  6. Replace the block of code in Listing 1 with the code in Listings 2a and 2b. The new code will launch the application automatically in a web view directed at the portal.
    Listing 2a. didFinishLaunchingWithOptions method directing application to Portal URL in Worklight version 5.0.5
    -(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:
    (NSDictionary *)launchOptions
    {
        BOOL superResult = [super application:application didFinishLaunchingWithOptions:
    launchOptions];
        NSURL* remoteURL = [NSURL URLWithString:@"http://9.99.999.999:10039/wps/portal”];
        NSURLRequest* request = [NSURLRequest requestWithURL:remoteURL];
        [self.viewController.webView loadRequest:request];
        return superResult;
        }
    Listing 2b. didFinishLaunchingWithOptions method directing application to Portal URL in Worklight version 5.0.6
    /**
     * This is main kick off after the app inits, the views and Settings are setup here. 
     */
    -(void) didFinishWLNativeInit:(NSNotification *)notification {
        NSURL* remoteURL = [NSURL URLWithString:@"http://9.99.999.999:10039/wps/portal"];
        NSURLRequest* request = [NSURLRequest requestWithURL:remoteURL];
        [self.viewController.webView loadRequest:request];
    }

    The IP address in this example should be the address of the WebSphere Portal server you want to render in the hybrid application.
  7. Open the file Cordova.plist (for Worklight version 5.0.5) or worklight.plist (for Worklight version 5.0.6) located at \WLPortal\apps\WLPortalApp\iphone\native.
  8. Find the attribute key called OpenAllWhitelistURLsInWebView and set it to “true” (Listing 3).
    Listing 3. OpenAllWhitelistURLsInWebView set to true
    <key>OpenAllWhitelistURLsInWebView</key>
    <true/>
  9. Now that you have the application set up, you should verify that it will build and deploy. As you can see in Figure 5, the Build All and Deploy command means the native applications will be redeployed based on the web application changes. Execute the Build All and Deploy command by right-clicking on the application and selecting Run As > Build All and Deploy.
    Figure 5. Selecting build and deploy
    Figure 5. Selecting build and deploy
  10. As the build process begins, you can see the progress in the lower right status banner in Eclipse. When the process completes, you should see the message Application 'YourApp' deployed successfully with all environments in the Worklight console. Both the iOS and Android applications have been updated.
  11. Next, you want to view the application in the iOS simulator. To do this, first right-click iphone under the project in Eclipse, then select Run as > Xcode project (Figure 6). This will launch Xcode and your application will be displayed in the console (Figure 7).
    Figure 6. Running application as Xcode project
    Figure 6. Running application as Xcode project
    Figure 7. Your application displayed in Xcode
    Figure 7. Your application displayed in Xcode
  12. Since the application was created for iPhone devices, change the simulator to iPhone by clicking on the down arrow, next to the Run icon in the top left of the console, and select iPhone 5.1 Simulator (Figure 8).
    Figure 8. Change the simulator to iPhone
    Figure 8. Change the simulator to iPhone
  13. Select the Run icon in the top left (Figure 9) and the simulator will launch your application (Figure 10).
    Figure 9. The Run button in Xcode
    Figure 9. The Run button in Xcode
    Figure 10. Your application running in the iPhone simulator
    Figure 10. Your application running in the iPhone simulator

Update the WebSphere Portal theme for both iOS and Android

The WebSphere Portal theme now requires an update to identify the mobile device operating system and to include the correct set of files to pull in the Worklight resources. The identification of the mobile device operating system will be determined by the device class mechanism in WebSphere Portal. Out-of-box the smartphone clients for Android and iOS are combined into one device class called smartphone. It is required to separate the clients to load resources based on the operating system.

  1. To update the iPhone client so it is identified differently than Android, run the xmlaccess script in Listing 4.
    Listing 4. XMLAccess script to change the device class for iPhone and Adroid Mobile
    <?xml version="1.0" encoding="UTF-8"?>
    <request type="update" 
    		 version="8.0.0.0" 
    		 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    		 xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd">
        <portal action="locate">
            <client action="update" domain="rel" manufacturer="Apple" markup="html" 
    uniquename="wps.client.iphone">
                <useragent-pattern>.*iPhone.*</useragent-pattern>
    	<client-capability update="remove">com.ibm.portal.devicesupport.deviceclass=
    smartphone</client-capability>
    	<client-capability update="set">com.ibm.portal.devicesupport.deviceclass=
    smartphone-ios</client-capability>     	
                <client-capability update="set">HTML_4_0</client-capability>
            </client>
        </portal>
    </request>

    If you were previously using the smartphone device class, you will have to update any custom logic or static templates to use the new class smartphone-ios.
  2. In Part 1, you created a custom theme and part of that theme was creating a new web application EAR that includes custom dynamic resources. Open the head.jsp file, located at /<wp_profile>/installedApps/<node>/<custom_ear>/<custom_war>/themes/html/dynamicSpots/. At the bottom of the head.jsp file, add the code in Listing 5, which will retrieve the device class and set it in a JSP variable.
    Listing 5. Retrieve the device class
    <c:set var="deviceClass" scope="request" value="${wp.clientProfile['DeviceClass']}"
    />
  3. After the line of code to retrieve the device class, use the retrieved information to check for iOS or Android smartphone devices (Listing 6).
    Listing 6. Logic to check for iOS or Android smartphones
    <c:if test="${deviceClass == 'smartphone'}">
    <!--android devices -->
    <c:if test="${deviceClass == 'smartphone-ios'}">
    <!--ios devices -->
    </c:if>
  4. Now that the theme is ready to determine the device that is accessing the portal, you can move the iOS specific files from Worklight to WebSphere Portal. Many files used in Part 1 will be the same between devices, but the ones that are not shared will include the namespace ios. The file that defines the JavaScript that needs to be included in WebSphere Portal is WLPortalApp.html, located at \WLPortal\apps\WLPortalApp\iphone\native\www\default\.
  5. The first file that needs to be created specifically for iPhone is the static properties file. The static properties are defined at the top of the HTML file (Listing 7).
    Listing 7. Static properties for iPhone devices
    	var WL = WL ? WL : {};
    
    	/**
    	 * WLClient configuration variables.
    	 * Values are injected by the deployer that packs the gadget.
    	 */
    
    	 WL.StaticAppProps = {
    	"APP_DISPLAY_NAME": "WLPortalApp",
    	"APP_SERVICES_URL": "\/apps\/services\/",
    	"APP_VERSION": "1.0",
    	"ENVIRONMENT": "iphone",
    	"LOGIN_DISPLAY_TYPE": "embedded",
    	"WORKLIGHT_ROOT_URL": "\/apps\/services\/api\/WLPortalApp\/iphone\/"
    };
  6. Take the JavaScript from this HTML file (Listing 7) and include it in a usable fashion within a new JavaScript file named staticprops.ios.js. Place this new file at this location: fs-type1:themes/<customTheme>/worklight/common/js/ (Figure 11).
    Figure 11. New file staticprops.ios.js is created
    Figure 11. New file staticprops.ios.js is created
  7. Another file that needs to be renamed and copied over to the common JavaScript folder is wlcommon.js, located at: \WLPortal\apps\WLPortalApp\iphone\native\www\default\common\js\.
    Figure 12. wlcommon.js renamed to be iOS specific
    Figure 12. wlcommon.js renamed to be iOS specific
  8. The next set of files that needs to be copied from Worklight to Portal is located in the wlclient folder. These files need to be renamed with the “ios” namespace:
    • checksum.js
    • cordova.js
    These files, located at: \WLPortal\apps\WLPortalApp\iphone\native\www\default\wlclient\js\, can be copied over as is:
    • json2.js
    • wpgap.ios.js
    After the renaming is done, copy all four files to WebSphere Portal at this location: fs-type1:themes/<customTheme>/worklight/wlclient/js/.
    Figure 13. The new files in the wlclient JavaScript folder
    Figure 13. The new files in the wlclient JavaScript folder
  9. All of the required files for the Worklight API are now in place and need to be included on the page, based on the device that is accessing WebSphere Portal. The JavaScript that needs to be included for Android can be taken directly from the wl_client module created in Part 1. Add the appropriate script include elements to head.jsp for Android mobile devices (Listing 8).
    Listing 8. JavaScript for Android mobile devices added to head.jsp
    <c:if test="${deviceClass == 'smartphone'}">
    <!--android devices -->
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/common/js/staticprops.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/cordova.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/common/js/wljq.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/common/js/base.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/messages.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/common/js/wlcommon.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/diagnosticDialog.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/deviceAuthentication.js" 
    allowRelativeURL="true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/window.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/worklight.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/wlclient.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/wlfragments.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/encryptedcache.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/checksum.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/wlgap.android.js" allowRelativeURL="
    true" mode="download" lateBinding="false"/>'></script>
    </c:if>
  10. Next, add the appropriate JavaScript for iOS devices to head.jsp. This is essentially the same list as Android mobile devices, which you can verify based on the script includes defined in the WLPortalApp.html, located at \WLPortal\apps\WLPortalApp\iphone\native\www\default\. However, the files with the “ios” namespace are substituted in place of the corresponding Android files, and json2.js has been added (Listing 9).
    Listing 9. Javascript for iOS mobile devices added to head.jsp
    <c:if test="${deviceClass == 'smartphone-ios'}">
    <!-- ios devices -->
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/common/js/staticprops.ios.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/cordova.ios.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/common/js/wljq.js" allowRelativeURL="true" mode=
    "download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/common/js/base.js" allowRelativeURL="true" mode=
    "download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/messages.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/common/js/wlcommon.ios.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/diagnosticDialog.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/deviceAuthentication.js" 
    allowRelativeURL="true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/window.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/worklight.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/wlclient.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/wlfragments.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/encryptedcache.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/checksum.ios.js" allowRelativeURL=
    "true" mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/json2.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    	<script type="text/javascript" src='<r:url uri="dav:fs-
    type1/themes/customTheme/worklight/wlclient/js/wlgap.ios.js" allowRelativeURL="true" 
    mode="download" lateBinding="false"/>'></script>
    </c:if>

    When going into production, it would be worthwhile to create JavaScript layers for each device specific set of files. This would reduce the requests on page render and help improve performance.
  11. Now that the Android JavaScript files are included via the head.jsp file, you should remove the wl_client module from the profile_worklight.json file, located at fs-type1:themes/<customTheme>/profiles/.
    Listing 10. Original profile_worklight.json set of modules
    	"moduleIDs": [
    		"wp_theme_portal_80",
    		"wp_portlet_css",
    		"wp_one_ui",
    		"wp_one_ui_dijit",
    		"wp_legacy_layouts",
    		"wp_client_ext",
    		"wp_status_bar",
    		"wp_theme_menus",
    		"wp_theme_skin_region",
    		"wp_theme_high_contrast",
    		"wp_layout_windowstates",
    		"wl_client",
    		"wl_init"
    	],
    Listing 11. The profile_worklight.json file after wlclient removed
    	"moduleIDs": [
    		"wp_theme_portal_80",
    		"wp_portlet_css",
    		"wp_one_ui",
    		"wp_one_ui_dijit",
    		"wp_legacy_layouts",
    		"wp_client_ext",
    		"wp_status_bar",
    		"wp_theme_menus",
    		"wp_theme_skin_region",
    		"wp_theme_high_contrast",
    		"wp_layout_windowstates",
    		"wl_init"
    	],
  12. Because the wl_client module was removed from the profile, you must remove the prerequisite from the wl_init module. To do this, open the worklight.json contribution file and remove the prereq definition, located at fs-type1:themes/<customTheme>/contributions.
    Listing 12. Original wl_init module definition
    {
    	"id":"wl_init",
    	"prereqs":[{
    		"id":"wl_client"
    	},{
    		"id":"wp_client_main"
    	},{
    		"id":"wp_client_ext"
    	}],
    	"contributions":[{
    		"type":"config",
    		"sub-contributions":[{
    			"type":"js",
    			"uris":[{
    				"value":"/worklight/common/js/init.js"
    			}]
    		}]
    	}]
    }
    Listing 13. The wl_init module with the wl_client prereq removed
    {
    		"id":"wl_init",
    		"prereqs":[
    		{
    			"id":"wp_client_main"
    		},{
    			"id":"wp_client_ext"
    		}],
    		"contributions":[{
    			"type":"config",
    			"sub-contributions":[{
    				"type":"js",
    				"uris":[{
    					"value":"/worklight/common/js/init.js"
    				}
    				]
    			}]
    		}]
    	}

Everything is in place for your portal to detect the device that is accessing WebSphere Portal and include the set of files required to integrate correctly with Worklight.


Test the application

Since this exercise continued from Part 1, there is a sample already in place to test the Worklight API. This sample will display the device name and version at the top of the page. The test will be to confirm that this information is shown correctly for both the Android emulator and iOS simulator.

  1. Once again, build and deploy the application by right-clicking on the application and selecting Build All and Deploy. You can see the progress in the lower right status banner in Eclipse.
  2. When the process completes, right-click WLPortalWLPortalAppAndroid and select Run As... > Android Application. This will launch the Android Emulator and the application will display your WebSphere Portal.
  3. After the application has rendered the WebSphere Portal application, navigate to the page to which you applied the custom theme and Worklight profile. If this page does not have anonymous access, then login and navigate to the page. It will take a few seconds for the device settings to load, but you will see them appear at the top of the page, as shown in Figure 14.
    Figure 14. The Android emulator showing Portal with the Worklight API sample
    Figure 14. The Android emulator showing Portal with the Worklight API sample
  4. Right-click on iphone under the WLPortalApp and select Run As > Xcode project. This will launch the Xcode application, and you will need to run the application in the iOS simulator. Once running, the application will display your WebSphere Portal.
  5. After the application has rendered the WebSphere Portal application, once again navigate to the page where you applied the custom theme and Worklight profile. You will see the device name and version appear at the top of the page, as shown in Figure 15.
    Figure 15. The iOS simulator showing WebSphere Portal with the Worklight API
    Figure 15. The iOS simulator showing WebSphere Portal with the Worklight API

Conclusion

IBM WebSphere Portal makes it easy to tailor the native device capabilities available to your multi-channel web applications. The Worklight shell created for both Android and iOS can also be packaged into a deliverable that can be published to either app store or deployed via MDM, if needed. The result is that you get the full WebSphere Portal multi-channel website management capabilities extended to include native device services tailored for multiple devices. The next articles in this series will discuss the configuration for single sign-on authentication, and integrating Worklight and Web Exeperience Factory, respectively.


Download

DescriptionNameSize
Sample applicationPart2-sample_files.zip9 KB

Resources

Learn

Get products and technologies

Comments

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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Mobile development, WebSphere, Lotus
ArticleID=843671
ArticleTitle=Deliver an exceptional mobile web experience using WebSphere Portal and IBM Worklight V5.0, Part 2: Integrating multiple device support for WebSphere Portal pages
publish-date=08072013