Mobile Device Configuration

ExtraView supports mobile platforms.  Mobile clients can be downloaded from the Apple App Store, or from Google Play, depending on the device you are running.  Given that layouts designed for desktop usage may well be too wide and too tall to be used without a significant amount of scrolling on a mobile device, ExtraView provides the capability to create layouts for different display targets as follows:

  • Desktop - these layouts are the default and will always be presented to a user if no Tablet or Phone layout exists.  Given that there are always a set of default Desktop layouts in a system, this means that a layout will always be presented to a mobile user, even if it has not been optimized for use
  • Tablet - these layouts will be presented to a user when they have been configured, and ExtraView detects it is running on a tablet-sized device.  These layouts may have fewer rows and fewer columns than a Desktop layout, depending on how many fields need to be placed on the layout.  The end user can override the Tablet display target selection and elect to use either the Desktop or Phone layouts, if they desire, within the sign on information for the connection
  • Phone - these layouts will be presented to a user when they have been configured, and ExtraView detects it is running on a smart phone-sized device.  Typically these layouts will have fewer rows and only one or two columns.  The end user can override the Phone display target selection and elect to use either the Desktop or Tablet layouts, if they desire, within the sign on information for the connection.

Mobile configurations may also be implemented to be more restrictive than the desktop configuration, for example to only allow the end user to add a specific issue and no more, often without the need for the user to sign on with a valid User ID and password.  See the section further down this page, entitled Configuring Limited Access.

Implementation Considerations

You can globally turn mobile access on and off with the behavior setting named ALLOW_MOBILE_CLIENTS

Given the smaller screen sizes of Tablet and Phone devices, you will almost certainly want to configure different layouts for these.  Here are some recommendations:

  • Do not configure the mobile layouts until you have completed the configuration of the Desktop target layouts.  This allows you to debug your workflow and other logic first, then simply do a "save as" type of operation to create the Tablet and Phone layouts from the Desktop layouts.  Then it is a relatively simple exercise to alter the presentation of the layouts, while retaining the underlying logic.  If your Desktop layout does not have more than 3 columns and more than about 10 rows, then Tablet users may often be able to use this as their layout.  It is recommended that you configure your Phone layouts with a single column and perhaps 5 or 6 rows per screen.  See here for instructions on creating layouts
  • Consider the introduction of screen pages within your mobile layouts.  These are configured using the PAGE_PRE_xxx and PAGE_POST_xxx fields.  These provide a neat interface to the user, only displaying a screenful of fields with next and previous page buttons to move between the different parts of a layout.  These are most useful on Phone layouts.  See here for instructions on using pagination
  • Many reports will be overly large to display on mobile devices, particularly on mobile phones.  For each report type that is enabled for mobile working, you can choose within the individual report editor screens to allow or disallow the user to see and run that report on a mobile device.  While you may allow the end user to decide for themselves which personal reports they should be able to view, consider the Public reports and whether they are suitable for mobile viewing.  You might create some reports just for mobile working.  You can also use the Administrative Report Management utility to review and update all the reports to decide which you want to make available to mobile users.  If you are familiar with the public reports, this is a faster way to turn on reports for mobile working, compared to individually reviewing the reports
  • It is worthwhile introducing specific navigation bars for mobile working.  These can direct users to the specific pages that are important for their use.  In addition, you might introduce a report menu, with access to a limited number of reports specifically designed for mobile working, and not allow access to reporting in general
  • Do not use the inbuilt ADMIN user account to test the mobile interface.  This account should only be used on desktop interfaces
  • There are some limitations with mobile clients, principally because of design limitations of the devices.  For example, Apple iOS devices do not allow access to their file system to be able to upload documents.  See here, for a full list of limitations
  • Although there are some limitations, there are also opportunities to introduce new features into your workflow with mobile devices.  For example, you can directly access the camera and photo albums within mobile devices.  You can also use a canvas to capture a user's signature on the screen and upload this directly into an image display type field.  The opportunity to configure these items present new features that cannot be met from a desktop computer.

Configuring Limited Access

A typical use case for limiting user access within the mobile client is to allow users to simply report issues, as opposed to having access to all of ExtraView's functionality.  The following configuration options allow for up to five screens within the mobile client to be configured, with optional access to the sign on screen, to reports and to other functions:

Behavior Settings

MOBILE_DIRECT_ACCESS_1 to MOBILE_DIRECT_ACCESS_5 These are 5 separate behavior settings that allow for the optional placement of five separate buttons on the Sign On screen of the mobile client.  If not configured, no button appears.  If configured, the entry should be of the form:

Button Title:URL

The Button Title will appear on the Sign On screen and the URL must be a valid URL within ExtraView to which the user is directed when the button is pressed.  It is assumed that a User ID and password are parameters within the URL.  Typically this URL will also have an AREA, a PROJECT and ROLE defined and be directed to an add screen within ExtraView. 
HIDE_MOBILE_SIGNON_SCREEN This setting may have the value of YES, NO or SIGNON_BUTTON.

When the value is NO, the User ID and Password fields are always visible.

When the setting is YES, the input fields for the User ID and Password are never viewable and the client is reliant on one or more of the behavior settings named MOBILE_DIRECT_ACCESS_1 through MOBILE_DIRECT_ACCESS_5 providing direct access to screens within ExtraView. 

When the value is SIGNON_BUTTON, there is a button with the title Sign On and when this is clicked, the User ID and Password fields become visible.

The default value for this setting is NO, so that the user has the ability to sign on.

Security Permission Keys

MENU_MOBILE_NAV_BAR This allows the navigation bar that is configured to only appear when there is read and write access to the permission key.  The most frequent use of this setting is to suppress the navigation menus for users within the mobile client, locking them into the functionality provided by the behavior settings named MOBILE_DIRECT_ACCESS_1 to MOBILE_DIRECT_ACCESS_5
PR_ADD_PROBLEM.CONFIRM_ALLOW_EDIT This security permission key will remove the Edit button from the confirmation screen displayed to the user following the successful addition of an issue through an add screen.