Before we discuss the tools that are available for mobile stores, let's first look at what a mobile store is, why it is important, and common considerations. Additionally, we will cover common mistakes and items that are not well-known, such as browser detection, JSP selection, and device mapping. The article assumes that most users will not have access to all of the devices available.
A mobile store is any store that you are planning to be accessible via a mobile device. In reality, this includes all B2C commerce sites because, in the current market with the proliferation of smartphones and tablets, customers will access your store via a mobile client whether you plan for it or not. To that end, it is smart to include at least unit testing of your site with some mobile devices to ensure your site provides a pleasant shopping experience. Because if they can find it when they want it on their phone, they are more likely to buy it then, rather than trying to remember it later.
So what differentiates a mobile store from just a store that is capable of being viewed on a mobile browser? The distinction lies in setting up your store so that you provide a different markup based on the device making the request. The goal is to provide a richer customer experience to entice them to buy from you. This means that the markup provided is better suited to viewing on a smaller screen and for user interaction than a traditional Web site. Keep these things in mind as you customize the store for your mobile site.
When making your store into a mobile store, there are few options. First off, you can use the mobile starter store that comes with WebSphere Commerce, or you can grow your own by using the mappings in the various tables, such as DISPCGREL and DISPENTREL, to control what JSPs are displayed for mobile requests. With Feature Pack 4 and later, there are also reference native and hybrid applications available. These native and hybrid applications require your customers to install something instead of just using the mobile Web application. These reference applications show how they work with the rest of the services to provide a richer experience for the mobile device user.
Next, let us look at a few items to understand the common points of failure and flow of the request once it reaches the server. The starter store chooses the JSPs to render based from the mappings in the Struts configuration files, as shown below:
<global-forwards> <forward className="com.ibm.commerce.struts.ECActionForward" name="CompleteOrderView/201/-3" path="/AuctionArea/Messages/CompleteOrder.jsp"> <set-property property="implClassName" value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommandImpl" /> <set-property property="interfaceName" value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommand" /> </forward>
The syntax of the name attribute of the forward element is a "docname/storeID/deviceFormatID" triplet, where the third constituent defaults to "-1". However, in this case, you can see it is a "-3". Keep this in mind when it appears that the request is going to be a different JSP than you planned on. This can happen because the request bypassed the device detection, the user agent string does not map to the one you have defined, or a mapping is missing for the view being requested.
If you decide to grow your own mobile store and use the DISPCGREL and DISPENTREL tables to control which pages are displayed, be aware of how the mapping actually works. Let's say you have sample entries like the ones shown in Table 1.
Table 1. Sample DISPENTREL table
The rank attribute is ascending, so that zero (0) is the highest rank for an item. Additionally, you need to set the rank on your mobile page to be higher than the default because the default view is always selected as well. To illustrate this further, when a request is made to the table for the views for that device, (-11) in this case, the query also includes the default device ID (-1). If a separate view is not defined for the device (-11), then a view will be returned. Therefore, if both ranks are zero(0), then the default view is returned.
Finally, if you are working with your own custom native or hybrid applications, you need to test on the emulators or on the device itself. These require installation, which is more than a browser emulator can do by itself. If you use an emulator, even though it tries to mimic the device, it may not match the rendering of the device itself. Additionally, when accessing a mobile store, you need to first come in via the storeview URL. The servlet filter that is running determines which device you are running and redirects appropriately. If you bypass this URL, then the browser detection does not happen. The storeview URL looks like this:
For more information about the limitations, see the Information Center.
For this article, we used the following products and browsers:
- IBM® WebSphere Commerce V188.8.131.52 Toolkit with Feature Pack 3
- IBM Rational® Application Developer V184.108.40.206
- IBM Rational Application Developer V8.0.3
- Fiddler2 V220.127.116.11
- Mozilla® Firefox® 10.0.2
- Internet Explorer® 9.0.8112.16421
- UserAgent Switcher V0.7.3
- Firebug® V1.9.1
- WebDeveloper Toolbar V1.1.9
- Android® SDK Tools Revision 16
- Android 4.0.3
- Android 3.1
- Android 2.3.3
First, inspect the request and responses flowing to and from the server. This is helpful to see things like cookies and other header information that are usually only seen by the browser engine when viewing a Web site.
The first of these tools is called Fiddler. This tool is a proxy that sits between the running browser or device and the network stack for your machine. You can use it when you are using emulators or user agent switchers on your workstation to emulate or simulate your mobile browsing experience. With this tool, you can see requests for every resource going to the server and the response, as shown in Figure 1.
Figure 1. Example requests in Fiddler
With these requests, you can examine each response via the tool as shown in Figure 2.
Figure 2. Examining the request
Another request or response viewer is the "Live HTTP Headers". This is a plugin for the browsers and FireFox. This tool shows a little less, but it can still be helpful. Figure 3 shows an example of the items that you can see. You can still see items such as cookies and responses, but it is just a little harder to read and parse.
Figure 3. Example of Live HTTP Headers
All this information allows you to see what the application is telling to the browser to do, not just what you are seeing. When you match this up with the tracing from the server, you get a complete picture of what is going on between the browser and the server.
First off, let's look at what is available for Firefox. We use a combination of two tools, Firebug and WebDeveloper toolbar. With these two add-ons, you can easily manipulate the markup by disabling styles, inspecting styles, and changing them. See Figure 4 on how you can inspect the HTML and CSS for an item.
Figure 4. Example of Firebug
Looking at some of the tools available in Internet Explorer, you have Firebug lite, which has many of the features you have in Firefox that allows you to use them in other browsers. Then starting with Internet Explorer 8, you have the option of the built-in developer tools. These tools are helpful, but we have found them to be much slower than Firebug, causing whole page refreshes and long parse times.
Finally, there is the server side tooling, which is mostly tracing. This tracing gives you details on how the server is processing the request and what items are sent to the server. You need to enable the following trace string:
With this trace string, as shown below, you can see the device ID that it is mapping to as well as the specific JSP it is going to load.
Entry Request [2/21/12 14:04:02:382 EST] 0000007d WC_SERVER 3 com.ibm.commerce.webcontroller.RuntimeServletFilter doFilterAction URLINFO - Method = GET ServletPath = /servlet PathTranslated = C:\IBM\WCDE_ENT70\workspace\Stores\WebContent\StoreView RequestURI = /webapp/wcs/stores/servlet/StoreView Device ID resolution [2/21/12 14:04:02:407 EST] 0000007d WC_SERVER 3 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper. locateView(String,ViewCommandContext,ActionMapping,TypedProperty,ServletContext) storeId = 10051 [2/21/12 14:04:02:407 EST] 0000007d WC_SERVER > 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper. findForwardConfig(ViewCommandCOntext,String,ServletContext) Entry [2/21/12 14:04:02:407 EST] 0000007d WC_SERVER 3 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper. findForwardConfig(ViewCommandCOntext,String,ServletContext) context.device= -11 [2/21/12 14:04:02:407 EST] 0000007d WC_SERVER 3 52e3019f:135a13f532e:-7ff6 LRUDynamicHashtable.get Cache misses: 5 The missing key: StoreView&10051&-11 hits: 1 evictions: 0 [2/21/12 14:04:02:407 EST] 0000007d WC_SERVER 3 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper. findForwardConfig(ViewCommandCOntext,String,ServletContext) context device=-11 defaultDevice= -1
Finally, this section of the tracing shows the engine finding the forward for a specific device.
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER > 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper. findForwardConfigForDevice Entry [2/21/12 14:04:02:407 EST] 0000007d WC_SERVER > 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper. findStoreSpecificForwardConfig Entry [2/21/12 14:04:02:407 EST] 0000007d WC_SERVER 3 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper. findStoreSpecificForwardConfig look for view StoreView/10051/-11 [2/21/12 14:04:02:407 EST] 0000007d WC_SERVER < 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper. findStoreSpecificForwardConfig Exit
This tracing determines why you are getting one view, versus the view you expected. It can determine if the device ID is resolving to something besides what you expect, or if the JSPs are mapped incorrectly in your Struts files. If you are not getting what you expect, enable this trace first, then see what device ID it is mapping to, what view it is looking for, and what view it finds.
The first scenario is using a tool to switch the user agent string. The user agent string is what your browsing device actually sends to the server to tell the server about itself. An example of a user agent from Firefox 10 is:
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0
You can tell a good bit about the machine and the user agent from this line. It is Firefox 10, it is on a 64-bit operating system, and it is Windows® 7. To get an add-on that lets you switch the user-agent, see the Firefox add-ons page. You need to apply the add-on, then load the add-on with a list of user agents. If you so choose, you can also type them in by hand. In the following steps, we have loaded the user agents into the add-on, then chose to emulate an Apple® iPad®.
- Download the useragent list.
- Go to Tools > Default User Agent > User Agent Switcher > Options.
- Click the Import button.
- Select the file from Step 1.
- Click OK.
- Go back to Tools > Default UserAgent > Mobile Devices
> Devices > Tablets, as shown in Figure 5.
Figure 5. Changing the user agent
- Now choose the correct iPad that you want to test. We chose "iPad 2".
While doing this testing, start Fiddler to capture the traffic. If you refresh the page, you see this as the user string in Fiddler as shown below:
User-Agent: Mozilla/5.0 (iPad; U; CPU OS 4_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8F190 Safari/6533.18.5
The tracing described above is enabled on the server. Look on the server and see the following in the trace log. You can see the request coming in for the stores here.
[2/10/12 14:32:40:176 EST] 00000072 WC_SERVER 3 com.ibm.commerce.webcontroller.RuntimeServletFilter doFilterAction (HttpServletRequest,HttpServletResponse,FilterChain,Integer) URLINFO - Method = GET ServletPath = /servlet
Then under that string, you see:
HeaderNames: User-Agent Header = Mozilla/5.0 (iPad; U; CPU OS 4_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8F190 Safari/6533.18.5
You can see in this base store that it has mapped the user agent to the mobile devices by looking at the following trace string:
[2/10/12 14:32:41:346 EST] 00000072 WC_SERVER 3 -7f9224f7:13568b8e136:-7ffc com.ibm.commerce.struts.StrutsActionHelper. findForwardConfig(ViewCommandCOntext,String,ServletContext) device!=servletContext. defaultDevice, set viewDevice=-11
This ID matches what is in the
wc-devices.xml file. Next, it tries to find the
view for that device.
2/10/12 14:32:41:347 EST] 00000072 WC_SERVER 3 -7f9224f7:13568b8e136:-7ffc com.ibm.commerce.struts.StrutsActionHelper.findForwardConfig(ViewCommandCOntext, String,ServletContext) call findForwardConfig with: baseName,storeId,device, fallbackDevice=TopCategoriesDisplayView,10101,-11,null [2/10/12 14:32:41:347 EST] 00000072 WC_SERVER 3 -7f9224f7:13568b8e136:-7ffc com.ibm.commerce.struts.StrutsActionHelper.findForwardConfig(ActionMapping,String, Integer,Integer,Integer) storeId= 10101
It then looks for a view in the Struts config, such as
TopCategoriesDisplayView/10101/-11. If one is
not defined for the device, it looks for a specific mapping for the store.
If there is no mapping for the store, it looks for the general view
mapping. Looking for these traces will help you to see what is being
looked up, what is being found, and the view that was found. You can then
troubleshoot if the wrong device was mapped, or if the wrong JSPs were
In Rational Developer V8.0.3 and later, you can use the mobile browser simulator. This requires you to have two installations of Rational Application Developer, given the current requirements for WebSphere Commerce if you are testing it against your local Developer install. This simulator is designed to test items running on the sample server included with that version of the Developer. However, it allows you to easily point to other hosts and test with them as well so you can run this against other systems.
This simulator is a powerful tool for debugging mobile applications. One of the features is allowing you to rotate the device, so that you can see how it works when flipped, and to change devices on the fly without having to open another browser or another device emulator (see Figure 6).
Figure 6. Mobile Browser Simulator
- To set this up, first install Rational Application Developer V8.0.3 or
later. Then create a generic Web project to use to launch the tool. Create
a static Web project similar to the one shown in Figure 7.
Figure 7. Creating a new project
- Once the static Web project is created, create a simple HTML file to use as
your test bed. Right-click on WebContent > New >
WebPage, as shown in Figure 8.
Figure 8. Creating a new HTML file
- Now insert the generic "Hello World" in to the HTML as shown in Figure 9 to
verify it is loading the right file and working correctly.
Figure 9. HTML with text
- With the scratch project created, now change the Web browser that Rational
Application Developer uses to launch the application because it is better
to use the external browser for this than the default internal one. To
change that, go to Window > Web Browser > FireFox
as shown in Figure 10.
Figure 10. Changing the browser to display
- Once you have done this, right-click on the sample HTML file you created
above and choose Run As > Run On Mobile Browser Simulator
as shown in Figure 11. We have the Mobile Browser Simulator set
up for the AJAX test server that comes with Rational Developer Developer
V8.0 to keep things lightweight.
Figure 11. Running the dummy file in the simulator
- This then opens a browser as shown in Figure 12.
Figure 12. Sample file in the simulator
- After verifying that all is working, change the Web page URL to the URL of your WebSphere Commerce store. Ensure that you are pointing to the storeview URL as discussed previously. You receive a message that items are limited since it is not running on the same server as the store, and it is safe to ignore that for our purposes.
- Now that you are pointing to your store, change the device by clicking on
the blue icon to the left of the browser simulator. This lets you choose
other devices like "Apple iPad2" shown in Figure 13.
Figure 13. Switching devices in the simulator
- One of the nice features of using an external browser is that you can use
the previously discussed tools in the browser to help review the mark up
returned and using Fiddler to inspect the request and response sent from
the browser. This is helpful for content that is changed dynamically. We
use Firebug to inspect an element inside the mobile browser as shown in
Figure 14. Using add-ons within the simulator
Next, let's look at using a device emulator to test the store. This provides a lighterweight testing environment compared to using Rational Application Developer V8.0.3. Additionally, this provides an environment to test native and hybrid applications instead of just using the mobile browser. The device emulators we will explore are the Android device emulators that come with the Android SDK. There is also an emulator for iOS devices, but those require more specific environments than we are able to test with here.
Follow these steps to download and setup the Android SDK:
- Download the SDK.
- Unpack or install the SDK starter packager.
In this example, we are using the
installer_r16-windows.exefile and installing the SDK. While installing, we took the defaults.
- Next, decide what to download with the Android SDK Manager. We chose
- Android SDK Platform-tools
- 4.0.3 Android package
- 3.1 Android package
- 2.3.3 Android package (This is what we have on our personal phone.)
- USB driver package
- WebDriver Package
- When it is done, close the Manager.
- Download and install the ADT plugin for the Rational Application
Developer 8.0.3 environment:
- Select Help > Install New Software.
- Click Add in the top right corner.
- Give it a name, and use this as the address:
- Click OK.
Note: It may take a few seconds for this to resolve and get the tools back.
- Click the check box beside "Developer Tools".
- Click Next.
- Click Next when it displays "Install Details".
- Accept the License Terms.
- Click Finish.
Note: You may receive a message that you are installing unsigned content. Click OK to continue.
- Wait for it to install and when done and restart Eclipse.
- When it restarts, it asks you to install an SDK, but you already did that in Steps 2 and 3. Instead, select the already installed SDK, and point it to where you unpacked or uninstalled the SDK before.
Before you can start using the emulator, you have to create a profile or an AVD so that you can set up the emulator with the various settings. Follow these next steps to do that:
- Open the Android Virtual Device Manager.
- Click on New. Fill out your information as shown in the AVD
creation screen in Figure 15.
Figure 15. AVD creation screen
Note: Our computer became unresponsive during this time and took a while to finish this.
- Now that you have your AVD created, select it, and then click
Start. It then gives you a few options to change,
then click Launch. This brings up a device with a phone
and a browser. Next click on the browser icon(Globe).
This opens a browser that you can enter your site's URL to test against, as
shown in Figure 16.
Figure 16. Testing your mobile store
This article explored the different tools that you can use to unit test a custom store. These tools are helpful to reproduce problems seen on production without the need for adding expensive hardware for all the developers. Additionally, you can use all of these tools together to ensure everything is working as designed. Often times, you use the emulator to enable tracing on the server and to debug the problem yourself.
WebSphere Commerce V7 Information Center
Rational Application Developer 8.0.3 Mobile Browser Simulator
developerWorks WebSphere Commerce zone
James Barnes is currently a Level 2 Support Engineer for the WebSphere Commerce team. He joined IBM in 1999, first working at the Lucent outsourcing account and then moving to Level 2 Support in 2003, where he focused on development-related issues. Other works include the WebSphere Portal 5.1 Handbook and extensive articles for the Support site on migration and development. He holds certifications for WebSphere Portal development (5.1, 6.0, 6.1, 7.0) and WebSphere Portal Administrator (5.0, 5.1, 6.0). Jim has a B.Sc. degree in Agriculture and Applied Economics from Virginia Tech University. He is based at IBM's Research Triangle Park in North Carolina.