Our platform allows interactive solution builds when viewing data besides simply filling out and submitting forms. 

The capabilities of different screen types allow for a deeper user experience in displaying information, navigation, and flow, depending on your needs or the desired feel of your apps.

Data can also be passed between screen types by configuring user interactions and respective “Pass Parameters” depending on the target screen. These parameters can filter the screen being launched or prepopulate fields based on a prior selection, saving users time by reducing the information presented to process and automatically filling in form fields.

Greater value from this article can be achieved by installing the example used, “Inventory App“, from our Examples Catalog if you haven’t already.

Inventory App – Overview

Once you’ve installed the “Inventory App” in your account, a new folder will be created containing the following:

• 1x Custom Board of Icons
  Displays starting app screens.
• 1x Listing Screen
  Displays all linked data source rows or filtered data. (Inventory items)
• 1x Details Screen
  Displays all linked data source column data of a row. (Inventory item details)
• 1x Mapping Screen
  Displays all linked data source GPS column data or filtered data as pins on a map. (Inventory Items)
• 3x Data Entry Forms
  Forms to create new inventory items, update or delete.

The flow diagram below shows how the various screens operate and pass values as parameters from one screen to another, which makes this scenario possible.

Passing Parameters

When a User Interaction has been set to Open Screen, Passing parameters or values from one screen into another, i.e., the target screen being launched, can be achieved using syntax depending on the screen type.

Before diving in, it’ll be handy to know what this and target mean:

• this refers to the current screen’s linked data source and is generally followed by a column indicator, i.e., {{this[1]}}.
• target refers to the screen launched via the configured user interaction and is generally followed by a column indicator, i.e., {{target[1]}}.

For Detail and Task Details targets, pass the identifier of the target data row or Task. For data rows, the identifier must match the first column’s value.

Example:
{{this[2]}}

Note, {{this[2]}} is being matched up against {{target[0]]}} default.

For Listing & Map targets, you can pass in a formula for filtering the target rows. Use {{target[column]}} for target columns.

Example:
{{target[1]}} = {{this[1]}}
{{target[3]}} >= {{this[2]}}

For Data Entry Form targets, you can preset target fields with “dataname:value”, pipe separated.
The “dataname” here is a field from the target screen.
The “value” here is either static text or the current screen’s linked data source column reference, this.

Example:
field1:{{this[1]}}
field1:{{this[1]}}|field4:hello
orderNo:{{this[0]}}|customer:{{this[5]}

With the above syntax, screens can be chained together by sending parameters from the current screen to the target screen using the “User Interaction” property.

That was a fair amount of information; let’s look at individual use cases used in the Inventory App to clarify things.

Listing Screen to Details Screen

Passing a parameter from a Listing screen to a Details screen requires a value/row identifier from the Listing screen. This value must match a value in the 1st column of the details screen data source, driving the Details screen to display that row’s column data.

In this case, both screens share the same data source, and the 1st column is a unique identifier; hence, passing that parameter will find a match for the Details screen display. Displaying all column data based on the row selected on the Listing screen.

Syntax:

{{this[0]}}

Designer

In-App Flow

Our Best Practises – Data Sources article touches on the first column of a data source requiring a unique value for each row, effectively serving as a primary key.

Suppose you specify a column value as a parameter with the same value appearing on more than one row. In that case, If you select a column value as a parameter that has that same value appearing on more than one row, then the Details screen will not populate as it requires a unique value (does not appear on any other row in that column) to identify that particular row of data unambiguously in the column specified.

Details Screen to Listing Screen

Passing parameters from a Details screen to a Listing screen requires syntax that filters the number of rows displayed on the Listing screen.

In this case, the Details screen’s brand value filters the Listing screen to display only that brand’s inventory items.

Syntax:

{{target[1]}} = {{Brand}}

You’ll notice that o}xoxthis[1]}} isn’t used here but the data source’s column title, which is also applicable in some cases.

Designer

In-App Flow

This particular inventory brand only consists of one item. However, if a brand has more than one, all brand items would be displayed.

Details Screen to Data Entry Form

Passing parameters from a Details screen (that specifies a row from a data source) to a Data Entry Form, requires field data names from the target Form and column-identifying syntax from the Details screen to prepopulate fields in the form. 

Multiple values can be passed this way if separated by a pipe ‘|’ character.

In this case, a Details screen’s navigational action button is configured to launch a Data Entry Form and prepopulate fields that automatically select the item from a data source driven Choices field to be updated.

Syntax:

inventory_select:{{this[0]}}|id_flag:{{this[0]}}

Designer

In-App Flow

This particular interaction prepopulates two hidden fields. In turn, one filters the Choices field item to the one seen on the Details screen, and the other is a flag to make the field read-only, preventing the user from changing the item to update.

The reason for this is that this update Data Entry Form is also used elsewhere as a stand-alone item update form where the user can select an item from the drop-down.

Details Screen to Mapping Screen

Passing parameters from a Details screen (that specifies a row from a data source) to a Mapping screen requires a column containing GPS coordinates in the Details screen, which can filter and match the Mapping screen’s pins from its linked data source. 

In this case, the Details screen GPS coordinate is matched against the Mapping screen’s linked data source’s Geo Coordinate column, displaying only one pin from the Details screen. 

Syntax:

{{target[8]}} = {{GPS}}

You’ll notice that {{this[8]}} isn’t used here but the data source’s column title, which is also applicable in some cases.

Designer

In-App Flow

This interaction is two-fold: selecting a map pin will launch the Details screen displaying the inventory item’s details, as will navigating back in the app to the previous screen. However, this functionality is mainly intended for viewing all pins from the inventory’s data source on the Map of Inventory screen.

CRUD

The concept of CRUD is at the heart of any computer system capable of helping humans do meaningful work. 

CRUD is an anagram for (Create, Read, Update, and Delete), a list of all actions a computer system should be capable of doing with records.

As can be seen, when you use combinations of our various screen types, you can create dynamic, feature-rich, and highly functional mobile apps that work together to solve real business problems with minimal technical knowledge.

Tips & Tricks

App: Entry Drafts Data Source

When launching Data Entry Forms with passed parameters and saving, the only way to view those saved entries would be to configure an additional User Interaction to launch the “App: Entry Drafts” data source to view all saved entries.

For example, a Listing screen driven from the “App: Entry Drafts” data source and row User Interaction configured to launch and view a saved entry based on the Entry’s ID.