This appendix describes how to implement web-based applications for touch devices.
This appendix includes the following sections:
Section D.1, "Introduction to Creating Web Applications for Touch Devices Using ADF Faces"
Section D.2, "How ADF Faces Behaves in Mobile Browsers on Touch Devices"
Section D.3, "Best Practices When Using ADF Faces Components in a Mobile Browser"
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.
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 4.1, "About Using ADF Faces Architecture").
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 6-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 |
---|---|---|---|
Click |
Tap |
Mouse down |
Execute a button |
Select |
Tap |
Selected |
Select a table row |
Multi select |
Tap selects one, tap selects another, tapping a selected object deselects it |
Selected |
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 |
Hover |
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 |
|
Pan |
One finger swipe (when no conflict with other gestures). Otherwise, two finger swipe |
Enabled |
Pan map |
Zoom in/out |
Double tap (browser zoom). When in maximized state, pinch in/out can perform zoom |
Enabled |
Zoom browser screen Zoom graph or map |
Double-click to set anchor in the Hierarchy Viewer component |
Double tap. |
When the |
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 |
Selected |
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 |
---|---|---|
|
Selection |
Select boxes are displayed that allow users to select the item(s) to shuttle. |
|
Selection |
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. |
|
Scroll |
Instead of scroll bars, the table component is paginated, and displays a footer that allows the user to jump to specific pages of rows, as shown below. The number of rows on a page is determined by the |
ADF Faces dialog framework |
Windows |
When a command component used to launch the dialog framework has its |
|
Detachable menus |
Detachable menus are not supported. The |
|
Geometry management |
On touch devices, When the |
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.
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(); return 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: "iphone".equalsIgnoreCase(agent.getPlatformName()) ) ); }
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 |
For the root panel component on a page, set the |
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 8.4, "Using Partial Page Navigation." |
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 |
Table |
By default, when rendered on tablet devices, tables display a footer that allows the user to jump to specific pages of rows. For all tables to display on a tablet device, you should:
If the table is not in a flowing container, or if those attributes are not set correctly, the table will display a scroll bar instead of pages. For more information about table attributes, see Section 12.3.2, "Formatting Tables." For more information about flowing layouts and tables, see Section 12.2.7, "Geometry Management and Table, Tree, and Tree Table Components." |