D Creating Web Applications for Touch Devices Using ADF Faces

This appendix describes how to implement web-based applications for touch devices.

This appendix includes the following sections:

D.1 Introduction to Creating Web Applications for Touch Devices Using ADF Faces

The ADF Faces framework is optimized to run in mobile browsers such as Safari. The framework recognizes when a mobile browser on a touch device is requesting a page, and then delivers only the JavaScript and peer code applicable to a mobile device. However, while a standard ADF Faces web application will run in mobile browsers, because the user interaction is different and because screen size is limited, when your application needs to run in a mobile browser, you should create touch device-specific versions of the pages.

This appendix provides information on how ADF Faces works in mobile browsers on touch devices, along with best practices for implementing web pages specifically for touch devices.

D.2 How ADF Faces Behaves in Mobile Browsers on Touch Devices

In touch devices, users touch the screen instead of clicking the mouse. The native browser then converts these touch events into mouse events for processing. In ADF Faces. component peers handle the conversion. To better handle the conversion differences between touch devices and desktop devices, for each component that needs one, ADF Faces provides both a touch device-specific peer and a desktop-specific peer (for more information about peers, see Section, "Client-Side Components").

These peers allow the component to handle events specific to the device. For example, the desktop peer handles the mouse over and mouse out events, while the touch device peer handles the touch start and touch end events. The base peer handles all common interactions. This separation provides optimized processing on both devices (for more information about the touch event, see Table 5-3, "ADF Faces Client Events").

The touch device peers provide the logic to simulate the interaction on a desktop using touch-specific gestures. Table D-1 shows how desktop gestures are mapped to touch device gestures.

Table D-1 Supported Mobile Browser User Gestures

Mouse Interaction Touch Gesture Visual State Example



Mouse down

Execute a button




Select a table row

Multi select

Tap selects one, tap selects another, tapping a selected object deselects it


Select multiple graph bars

Drag and drop in a simple interface

Finger down + drag

Mouse down

Drag a slider thumb or a splitter

Drag and drop for use cases requiring both drag and drop as well as data tips

Finger down + short hold + drag

Mouse down

Move a task bar in a Gantt chart

Hover to show data tip

Finger down + hold

Hover (mouseover)

Show graph data tip

Hover to show popup

Finger down + hold

Hover (mouseover)

Show a popup from a calendar

Line data cursor on graph

Finger down + hold


Trace along the x-axis of a graph and at the intersection of the y-axis, the data value is displayed in a tip.

Right-click to launch a context menu

Finger down + hold or finger down + hold + finger up (when gesture conflict exists with another finger down + hold gesture)


Show graph or calendar activity context menu Context menu on finger up examples: Graph: finger down + hold = data tip; finger up = context menuGraph (bubble): finger down + hold + move = drag and drop; finger up = context menuGantt (task bar): finger down + hold = data tip; finger down + hold + move = drag and drop; finger up = context menu


One finger swipe (when no conflict with other gestures). Otherwise, two finger swipe


Pan map

Zoom in/out

Double tap (browser zoom). When in maximized state, pinch in/out can perform zoom


Zoom browser screen

Zoom graph or map

Double-click to set anchor in the Hierarchy Viewer component

Double tap.

When the setAnchorListener has a value, causes the node to be the root of the tree. When the value is not set, double tap causes a browser zoom.

Double tap a node within a hierarchy causes it to become the root node.

Click the isolate icon on the Hierarchy Viewer component

Tap node, then tap isolate icon

Panel card is isolated

Tap the top of the card and then the isolate icon to view only that card and any direct reports.

Click the collapse icon on the Hierarchy Viewer component

Swipe up on card

Collapsed panel card

Collapse a panel card

Click the expand icon on the Hierarchy Viewer component

Swipe down on card

Expanded panel card

Expand a collapsed panel card.

Hover to show fly out buttons on Hierarchy Viewer

Tap card

Fly out buttons display

Tap a card to display the fly out buttons

Click right or left arrow buttons on Hierarchy Viewer component

Swipe left or right on card

Switch panel cards

Swipe left to view address, or swipe right to view content.

Click navigation buttons to laterally traverse the hierarchy

Swipe left or right on the lateral navigation line, or tap the arrow, or touch and short hold + finger up to display the navigation buttons

Traverse the hierarchy

View more descendants of the root node.


Single tap the Maximize icon

Maximizes the component


Double-tap the Maximize icon or double-tab the hierarchy viewer background

Maximizes the component and zooms to fit


Use circle, square, or polygon tool on a map to drag and select a region

Finger down, draw shape


Use finger to select an area on a map

Use measurement tool on a map to click start point and end point

Tap measurement tool, finger down, draw line

Line drawn and calculated distance displayed

Use finger to select measurement tool, then tap to select point A and draw line to point B.

Use area tool on a map to click start point and end point

Tap area tool, finger down, draw line

Line drawn and calculated area displayed

Use finger to select area tool, then tap to select point A and draw line to point B, and so on.

For further optimization, ADF Faces partitions JavaScript, so that the touch device JavaScript is separated from the desktop JavaScript. Only the needed JavaScript is downloaded when a page is rendered. Also, when a touch device is detected, CSS content specific to touch devices is sent to the page. For example, on a touch device, checkboxes are displayed for items in the shuttle components, so that the user can easily select them. On a desktop device, the checkboxes are not displayed.

Using device-specific peers, JavaScript, and CSS allows components to function differently on desktop and touch devices. Table D-2 shows those differences.

Table D-2 Component Differences in Mobile Browsers

Component Functionality Difference from desktop component

selectManyShuttle and selectOrderShuttle


Select boxes are displayed that allow users to select the item(s) to shuttle.



Users select a row by tapping it and unselect a row by tapping it again. Multi-select is achieved simply by tapping the rows to be selected. That is, selecting a second row does not automatically deselect the first row.



Instead of scroll bars, the table component displays a footer that allows the user to show more rows, as shown below.

table displays a navigation footer

The number of rows on a page is determined by the fetchSize attribute.

ADF Faces dialog framework


When a command component used to launch the dialog framework has its windowEmbedStyle attribute set to window (to launch in a separate window), ADF Faces overrides this value and sets it to inlineDocument, so that the dialog is instead launched inline within the parent window.


Detachable menus

Detachable menus are not supported. The detachable attribute is ignored.


Geometry management

On touch devices, iFrame components ignore dimensions, and are always only as tall as their contents. Therefore, if the inlineFrame is stretched by its parent, the content may be truncated, because scroll bars are not used on touch devices.

When the inlineFrame is stretched by its parent, 40 pixels of padding and overflow are added to the inline style.

Various components

Icons, buttons, and links

Icons and buttons are larger and spaces between links are larger to accommodate fingers

Because some touch devices do not support Flash, ADF Faces components use HTML5 for animation transitions and the like. This standard ensures that the components will display on all devices.

D.3 Best Practices When Using ADF Faces Components in a Mobile Browser

When you know that your application will be run on touch devices, the best practice is to create pages specific for that device. You can then use code similar to that of Example D-1 to determine what device the application is being run on, and then deliver the correct page for the device.

Example D-1 Determining Platform

public boolean isMobilePlatform()
  RequestContext context = RequestContext.getCurrentInstance();
  Agent agent = context.getAgent();
  Agent.TYPE_PDA.equals(agent.getType()) ||
  Agent.TYPE_PHONE.equals(agent.getType()) ||
  Agent.AGENT_WEBKIT.equals(agent.getAgentName()) &&
// iPad/iPhone/iPod touch will come in as a desktop type and an iphone platform:

While your touch device application can use most ADF Faces components, certain functionality may be limited, or may be frustrating, on touch devices. Table D-3 provides best practices to follow when developing an application for touch devices.

Table D-3 Best Practices for ADF Faces Components in a Mobile Browser

Component/Functionality Best Practice

Geometry management

Set the oracle.adf.view.rich.geometry.DEFAULT_DIMENSIONS web.xml parameter to auto.

This setting ensures that the page will flow instead of stretch. For more information, see Section A.2.3.25, "Geometry Management for Layout and Table Components."

Partial page navigation

Using partial page navigation means that the JavaScript and other client code will not need to be downloaded from page to page, improving performance. For more information, see Section 7.4, "Using Partial Page Navigation."


Provide more direct access to individual pieces of content. A good rule is to have only one task per page, instead of using many regions on a page, separated by splitters. For example, instead of using a panleSplitter with a tree in the left pane to provide navigation, provide a list-based navigation model.

Handling touch events on the richTextEditor component

When a user clicks the editable area in the richTextEditor component, the following happens:

  • Editable area has focus

  • Keyboard is activated

  • On all versions of iOS, any touch event listeners added to the document are disabled

When a user clicks outside the editable area, the following happens:

  • Editable area loses focus (blur)

  • Keyboard is closed

  • The cursor position is lost (and will not be retained upon clicking back into the editable area)

  • On iOS, touch event listeners are added back to the document (on blur)

If you add any touch event listeners to the document, you must use the AdfAgent.addBubbleEventListener() to ensure that the touch event listeners are removed and restored properly.

richTextEditor edit window size

Set the rows attribute. If this attribute is not specified, when in WYSIWYG mode, the edit window will grow with the content added.


By default, when rendered on tablet devices, tables display a link that allows the user to load more rows. For all tables to display on a tablet device, you should:

  • Place the table components within a flowing container (that is, a component that does not stretch its children).

  • Set the autoHeightRows attribute to 0. Better, is to set the oracle.adf.view.rich.geometry.DEFAULT_DIMENSIONS parameter to auto, as described for geometry management in the first row of this table.

  • Set the scrollPolicy attribute to auto (if the page may also run on a desktop device) or loadMore (if the page will only run on a tablet.

If the table is not in a flowing container, or if those attributes are not set correctly, the table will display a scroll bar.

For more information about table attributes, see Section 10.2.2, "Formatting Tables." For more information about flowing layouts and tables, see Section 10.1.6, "Geometry Management for Table, Tree, and Tree Table Components."