User Interface

This demo showcases an app for an electric utility’s work orders. Service crews use the app to download their work orders in the morning instead of going into an office to pick them up. They update orders in the field, dynamically receive new ones, and complete their ”paper work” on the device while out in the field.

Authentication is easy to set up. Specify showLogon in the app’s configuration and Spark will require the user to enter their credentials before allowing access to the app. The content handler’s authenticate() method is called to validate their userid and password. The handler can use any authentication process (such as LDAP or Active Directory) for validation.

If authenticated, security constraints for the user are returned to Spark to control what business objects they can access and what actions are available (create, read, update, delete, etc).

This sample home screen has three business objects the user can access (their work, all work, and vehicles). The content handler provides record counts for each object (shown on a row’s right side).

Notice the name box at the top and the chart at the bottom… these are sample plugin widgets the developer can create to add to the screen’s header and footer sections. The top is a Android component while the bottom is a HTML web view using Google’s charting services.

Here is a list of work orders. Rows are sorted by touching a label in the header (Job # sorted ascending is shown). The list shows data specified in the content schema’s listAttributes XML… and in this example row icons and priority colors too. Both of those are easily provided by the content handler by including color and icon values for each row.

The list is shown in a card layout format. This optional layout is enabled with the cardLayout tag in the XML schema.

Long-pressing on the header label in a list presents a filter dialog to further refine which records are shown for that filtered data element (Job # in example). You can even filter the row’s color or icon by pressing on the box at the far left on the header bar.

Here is the filtered list… indicated by the yellow ball next to the Job # header label. This example also shows that Order Type has been hidden the list… indicated by the red line through the header. Swiping across a header hides/shows corresponding data.

Pressing on the blue information button on the right side of a row presents a details view of that record. In this example the user doesn’t have security permission to update the record, otherwise the fields would be editable.

Long-pressing on a row displays a list of tasks that can be performed on that record. This example shows three actions automatically provided by Spark (the top three) and the bottom three business tasks that were defined in the schema XML. Security permissions also determine whether a user is allowed to run tasks and specifically which ones.

Here is a task to update the order. Notice that empty fields show their labels as a hint, but when a value exists in a field the label will fade in as a floating label (see the Location field). Some fields have buttons on the far right to show a dialog used to enter data. Let’s press the compass on the Location field.

To enter location data (latitude/longitude or WGS84) a dialog opens and Spark turns on the GPS. Initially, the dialog’s map is centered on your current location to enter coordinates there. Or you can pan the map to center the reticle over another location instead.

This is just one of the field widgets Spark provides to enter data more easily.

The task to complete a work order shows another feature of Spark to capture the customer’s signature.

A distinct feature of Spark’s signatures is that they are stored as a Scalable Vector Graphics (SVG) text file instead of a bitmap image like other apps do. This makes it easier to store it in a database and then re-render it elsewhere at any scale with the same visual smoothness… you can’t do that with a bitmap.

Any business object that has geo-data (location coordinates or addresses) enables distance sorting and mapping. Since the work orders have been geo-coded you can press the icon on the bottom bar to sort the list by distance. It evens shows the bearing to the location in real-time as you rotate the phone. It also automatically updates and resorts as you move and the distances change.

Pressing the map pin button in the bottom bar brings up a map instead. The map shows markers for the records in the list (excluding any filtered ones). The developer can choose to show either a standard map pin or the representative icon from the row through the useImageOnMap tag in the schema. When the map first opens it automatically centers on the nearest map marker. Distance and even ETA times to a marker can be shown by Spark.

You can select different map items by pressing on its map marker or by sliding out a panel on the left to select from a list. Once selected the distance to the item is shown in the top center widget. That widget also has buttons to recenter on a selected item or your location. The bottom row of buttons allow you to change map type (street, terrain, satellite, etc), show routing info, and open Google Street View or Navigation on the item.

Another unique feature to Spark is displaying a compass while in map mode. This more precisely shows the distance and bearing to an item… useful in some situations where the user is trying to find the location of something when walking around.

The other button on the top bar turns on auto-rotate so that the map dynamically rotates depending on the direction you are facing. This allows you to orient the map to your direction of travel.

Pressing the overflow button (on the top bar far right with 3 circles) displays a menu for selecting app options. In this example there is a Logout selection (since authentication was configured for the app). The next two selections (Message and Status) are automatically shown by Spark when the app is connected to a SparkDash server. Those selections allow the user to send messages to others or to change their status. Online users show on the map along with their status.

This is the dialog shown when a user selects Status in the overflow menu. This is useful in some work situations where others need to see their status. Users and their statuses show up in the dashboard of SparkDash.

Spark has a predefined set of user preferences for the app. The developer can also configure a list of settings unique to the app by adding settingAttributes in the XML configuration.

Spark has a side loading drawer. By default it shows a selectable list of sub-apps available for the user. In this example there is only one. The developer can also define plugin widgets to go at the top or bottom of the drawer… either to display unique information or to perform some special action for the app.

This is list of Vehicles after selecting it on the home screen. The key thing to notice here is the available grouping of records into categories (along with counts). Grouping is easily done by adding a grouping category to each record returned in a list from the content handler.

Groups can be collapsed or expanded by touching the group label. In this example the Light Truck group is collapsed.

Because the Vehicles XML schema contained an Orders child node definition the user can drill-down into related data by pressing on a vehicle row and then open a list of orders assigned to the vehicle.

After drilling down through parent-child relationships you can go back up the hierarchy by pressing the Android back button or the app’s up button on the top left. Spark provides an even faster way to go back several levels with the history pop-down window. When you see a down pointing arrow next to the title in the top bar it means you can display a breadcrumb trail of screens you have traversed and then jump directly back to a previous level by selecting it from this menu.

If the schema XML for an object has defined searchAttributes, Spark displays a search icon on the right to present a search dialog. Search criteria is passed to the content handler to filter records returned via the onGetList() exit point.

Here is a sample search screen defined in XML for Orders. It is used to enter search criteria for the content handler to use when retrieving a list of orders to display.

Spark has built-in support for Floating Action Buttons advocated with Google’s Material Design. Developers can determine the button’s visibility, color, location, and action in the content handler. Spark will also present a floating button in certain situations (the example shows a button in the lower right corner to open a details view of the record).

And finally if the user performs a logout, the app will return to an empty home screen and indicate they must log back on to see their home items and to access the app again.