Defining Page and Layout Navigation

This topic describes how to define page navigation in mobile applications you create using the Mobile Application Platform.

Typically, in a mobile application built on the Mobile Application Platform framework, users navigate to other pages within a layout, to pages in other layouts, and to other resources not defined as layouts, such as external web sites. In most cases, users click a button, image, hyperlink, or some other page element to navigate to a different page. And the navigation logic is defined in the properties page of the element.

Note: In the discussion about page navigation in this topic the terms navigate, link and call are synonymous

Internal page types enable you to link to other pages in the same layout.

The system nests the internal page types within the same HTML document, and they are added as children to the body so that they can get accessed without any server call.

The advantage of using internal pages is that after the HTML document is loaded, no additional application server calls are necessary to navigate through the pages.

The disadvantage is that all the content data needs to be loaded as part of initialization. Moreover, if there are many pages the size of the HTML document can be quite large. If you think that some pages would not be frequently selected than one of the other options below might be more desirable.

If you don’t want to include a page inside the same HTML document as the first one (initial call), or if you need to dynamically create the content, then the best choice is defining navigation to external page types.

When navigating to external page types the framework makes the request, gets the external page, parses the content, adds the page to the current DOM, and makes a smooth transition to the new page. This is the typical selection for mobile applications.

For example, on a page you can call an external page and pass parameters as part of the request using layout initialization functionality.

If you have a list of items on a page and each item has a link to the same external page, the framework makes a call to the application server when the user selects an item, which in turn runs the initialization event. In the initialization event, the code checks the primitive(s) for each item and pulls the value(s) out. PeopleCode can then get information for the item(s) and populate the PeopleSoft Document object accordingly.

The framework builds the external page based on this data and the data presented back to the user is the information for the item(s). The user can select other items, which results in displaying the information for the item(s) on the external page.

The process to navigate to other layouts is similar to calling external pages within layouts.

Add a link on the properties page for a URL or button element. And instead of calling an external page, you call another layout. Based on the information defined in the Layout Initialization Parameter page, you can select the URI to use to build the link.

This section describes calling REST services from Mobile Application Platform applications.

Use PeopleSoft Integration Broker to build and manage REST services. See PeopleTools 8.55: PeopleSoft Integration Broker, “Managing REST Services” for more information.

Understanding Calling REST Services from Mobile Application Platform Applications

You can call REST services (provider or consumer) defined in your application database. When defining the page element properties for a URL or button, you can select a provider or consumer REST service.

REST Provider Services

The REST service provider builds the REST service using the Integration Broker framework and specifies the service in the properties page for the page element. The REST service provider can generate the WADL to furnish to the service consumer for use in building the consumer service operation. Using the Provide Web Service wizard, select to generate the WADL for the system-generated service name associated with the requested layout. To access the Provide Web Service wizard, select PeopleTools > Integration Broker > Web Services > Provide Web Services.

Note that the system-generated REST service name displays on the Layout Designer – Security page.

REST Consumer Services

Since all Mobile Application Platform layouts are essentially REST services, you can request the WADL for a layout from the REST service provider, build the consumer REST service and the GET REST service operation based on the WADL. The GET REST service operation, must include a non-rowset based response message in html format. You can then call the service operation from the properties page for the page element.

In situations where a PeopleSoft fluid page or a PeopleSoft classic application page calls a Mobile Application Platform application you can use the several PeopleCode properties to provide navigation back to the calling fluid or classic application page:

MAP Class Property

Description

PSBackURL

Use this property to obtain the URL that made the request (fluid, PeopleSoft classic, and Mobile Application Platform). Create a button and assign the URL as a button property to provide navigation back to the page.

PSBackLabel

Use this property to obtain the PeopleSoft component page name or MAP application/page that made the request and use the return value as a button label.

Moreover, set this property to provide to the target system the proper label name to use for its back button to call the MAP application/page.

PSBackOrigin

Use this property to obtain the origin of the calling application, Mobile Application Platform, fluid or classic PIA.

PIAOriginURL

Use this property to obtain the last fully qualified PIA URL from the requesting page.

PIAOriginlabel

Use this property to obtain the label associated with the PIA URL.

To call other documents and sites not defined as layouts, add the fully-qualified standard URL on the properties page for the element.