Contents
Previous
Next
| UIX Developer's Guide |
Contents |
Previous |
Next |
One of the goals of UIX is to provide the same technology to write pages for different devices. This chapter discusses how to write a mobile application using UIX.
UIX is currently supported on Internet Explorer on a Pocket PC. We will be supporting Palm browsers in the future. There is not currently phone/pager support. In the future this will be supported in conjunction with iAS Wireless.
This chapter contains the following sections:
<ctrl:page xmlns="http://xmlns.oracle.com/uix/ui"
xmlns:ctrl="http://xmlns.oracle.com/uix/controller">
<ctrl:content xmlns:ui="http://xmlns.oracle.com/uix/ui">
<form name="demoForm"
xmlns="http://xmlns.oracle.com/uix/ui">
<contents>
<pageLayout title="New Expense">
<privacy>
<link text="Privacy"
destination="http://www.oracle.com"/>
</privacy>
<about>
<link text="About"
destination="http://www.oracle.com"/>
</about>
<globalButtons>
<globalButtonBar>
<contents>
<globalButton text="Home"
destination="http://www.oracle.com"/>
<globalButton text="Portal"
destination="http://www.oracle.com"/>
</contents>
</globalButtonBar>
</globalButtons>
<corporateBranding>
<image source="images/pdaOracle.gif"/>
</corporateBranding>
<pageButtons>
<pageButtonBar>
<contents>
<submitButton text="OK" ctrl:event="error"/>
<submitButton text="Cancel"/>
<submitButton text="New Expense"/>
</contents>
</pageButtonBar>
</pageButtons>
<contents>
<labeledFieldLayout>
<contents>
<messageTextInput required="yes"
id="amount"
name="amount"
prompt="Amount"/>
<messageDateField required="yes"
name="date"
prompt="Date" />
<inlineMessage prompt="Have Receipt">
<contents>
<flowLayout>
<contents>
<radioGroup name="receipt">
<childData>
<option text="Yes" value="yesReceipt"/>
<option text="No" value="noReceipt"/>
</childData>
</radioGroup>
</contents>
</flowLayout>
</contents>
</inlineMessage>
</contents>
</labeledFieldLayout>
</contents>
</pageLayout>
</contents>
</form>
</ctrl:content>
</ctrl:page>
The following images show how the page is displayed on a destop browser and pda.
Figure 23-1: Desktop Browser
Figure 23-2: Pda Browser
It should be apparent that a page designed for a pda will look best if it is relatively simple, and that most pages designed with a desktop in mind will look overwhelming on a pda. This is an example of why the goal of UIX is to provide a single technology to write pages for different devices, not to use the same UIX pages on every device.
Looking at the example given in the Introduction section above shows that output is modified depending on the device making the request, for example page buttons are repeated and right aligned on a desktop browser, but rendered once and left aligned on a pda. Devices are grouped into the following three types:
Agent.TYPE_DESKTOP: Devices with a full-sized screen, like a desktop or laptop.Agent.TYPE_PDA: Devices with a medium-sized screen, like a pda.Agent.TYPE_PHONE: Devices with a small-sized screen, like a phone or pager.Developers should write pages with a specific agent type in mind. In fact while many pages can run on multiple agent types, this is not always the case. For a given agent type, a bean may not be supported at all, or certain attributes or children may not be supported. In general what's supported on a desktop machine is a superset of what's supported on a pda, which is a superset of what's supported on a phone. This reflects the fact that in general the functionality on a desktop machine is a superset of the functionality of a pda, which is a superset of the functionality of a phone.
Developers can determine the agent type in uiXML with the <agent> tag. An example:
<ctrl:page xmlns="http://xmlns.oracle.com/uix/ui"
xmlns:ctrl="http://xmlns.oracle.com/uix/controller">
<ctrl:content>
<dataScope>
<contents>
<flowLayout>
<contents>
<styledText styleClass="OraInstructionText" text="You are looking at this on a "/>
<styledText styleClass="OraInstructionText" >
<boundAttribute name="text">
<if>
<agent type="desktop"/>
<fixed text="desktop or laptop."/>
<if>
<agent type="pda"/>
<fixed text="pda."/>
<fixed text="um, well, let's see, not a desktop machine, laptop, or pda. You're wild!"/>
</if>
</if>
</boundAttribute>
</styledText>
</contents>
</flowLayout>
</contents>
</dataScope>
</ctrl:content>
</ctrl:page>
Developers should not rely on javascript support. While pda browsers are moving toward supporting javascript, many still don't. The script bean is supported to enhance the user experience on javascript-enabled browsers, but an application should not fail if scripting isn't available.
Typically, this means not relying on javascript to do client-side validation. While developers should always be doing server-side validation, this is an absolute must for a mobile application.
Below are lists of some of the differences between what is supported on a desktop machine and a pda. This is not a complete list. The componenent specific documentation has information about any attribute(s) and/or child(ren) that aren't supported on a pda.
The following components aren't supported. Neither the component nor its children are rendered and a warning is written to the error log.
The following components are ignored. No warning is written to the log as these should not be essential to the correct behavior of the page.
The following components render nothing themselves, but do render their indexed children.
The following components are supported on a pda. Their behavior, however, deviates sufficiently from the behavior on a desktop machine as to be worth mentioning.
Developers used to the page navigation of the Browser look-and-feel (BLAF) probably were surprised by the following:
Due to limitations in a pda, multiple parameters may be encoded as a single parameter, and thus need to be decoded. Developers using the UIX Controller do not need to worry about this as parameters are decoded by the controller automatically. Otherwise the developer has several options to decode the parameters.
If using a javax.servlet.ServletRequest, then developers can use it to create an instance of oracle.cabo.share.data.ServletRequestParameters, and then call on it any method found on ServletRequest to access parameters. For example, suppose request is an instance of ServletRequest and the code is as follows:
String fooValue = request.getParameter("foo");
....
ServletRequestParameters params = new ServletRequestParameters(request)
String fooValue = params.getParameter("foo");
....
java.util.Dictionary. For example:
Dictionary d = ServletRequestParameters.createRequestDictionary(request);
String fooValue = (String)d.get("foo");
java.util.Dictionary and have a Dictionary returned.
For example, suppose dictionary is an instance of Dictionary:
Dictionary d = ServletRequestParameters.createRequestDictionary(dictionary);
String fooValue = (String)d.get("foo");