The AppGyver Enterprise Documentation

Welcome to the AppGyver Enterprise Builder Documentation. Information about the different aspects of Enterprise Builder's functions may be found in the guides presented here. More guides and tutorials will be added in the following weeks.

Feel free to suggest edits on any parts of the documentation that feel unclear.

Get Started    

Logic Editor

The Logic Editor lets you visually create advanced frontend logic for your app. It is a part of the Interface Builder and works closely with your app Data – it is a good idea to read those guides first, if you haven't already.

Some of the things you can do with Logic Editorinclude:

  • Attach actions to events like button taps and page loads
  • Use conditions to create forking paths of logic
  • Store and read local variables and JSON data
  • Two-way binding of app data with UI components
  • Create lists by making UI components repeat themselves based on a data collection
  • Create your own actions
  • Reference component values, local variables, app data and passed parameters in components and actions

Actions

All UI components have an Add Logic button on their Properties tab. Currently, the only available trigger event is Tap, i.e. when the user taps on the element. Events like text input changed and others are coming soon.

After opening the logic editor, click on the blue tap event circle to get started.

Available action types

Available action types

Most actions have configurable properties that will be covered in detail in the next chapter. The Alert action, for example, is a straightforward one to try out.

You can also chain actions to create more complex logic. All actions have a success path output on the bottom right, marked by a checkmark. After the action has been successfully executed, the next action in the chain will be triggered.

Some actions define a failure path output also, marked by an X symbol: the logic chain will be followed if the action "fails". This can happen if a Condition action evaluates to false or the failure callback of a Custom JavaScript with callbacks action is fired.

Example of chained logic with conditions.

Example of chained logic with conditions.

List of Actions and Their Properties

Action properties either require you to select a data reference from a drop-down, or write freeform text. Additionally, most freeform text fields allow you to bind a data reference to the field via the Link icon.

Example properties of an **Open page** action, passing in the ID of a data record.

Example properties of an Open page action, passing in the ID of a data record.

Alert

Shows an alert dialog box.

Title

Alert dialog title text.

Message

Alert dialog message text.

Button

Alert dialog dismiss button text.

Condition

Creates a fork in the logic chain. If the condition evaluates to true, the success path (right side, marked by a checkmark) is followed; if false, the failure path (left side, marked by an X symbol).

The Key is tested against Value for equal value and equal type (=== operator in JavaScript).

Key

Reference value to test against. Can be any string-type reference.

Value

The other side of the equation: does Key match Value?

Custom JavaScript

Run any custom JavaScript. The JavaScript is executed on the currently open page.

Note that the code is currently not checked for correct syntax, so make sure it's error-free!

JavaScript

JavaScript code to execute. For example, to open a website, you can run:

// Open an app to show the URL, works for other protocols like maps:// too
supersonic.app.openURL("https://www.google.com")

// Use the InAppBrowser plugin to display a website within your app.
window.open("https://www.google.com", "_blank")

Custom JavaScript with callbacks

Same as above, but executing the predefined success() function continues the logic chain along the success path, while the fail() function continues along the failure path.

JavaScript

JavaScript code to execute.

Find one

Fetches a single record and makes it available as a reference. The reference created functions the same way as connecting data to your page via the Data tab of the Interface Builder (see the Data guide for more).

Resource Name

Resource in which to look for the record. Uses the Data ID value (can be found via the Data section) of the resource, not its display name.

Reference Name

Name of the new data reference that will point to the fetched record.

Identifier

The ID key of the record to fetch.

Find all

Like Find one, but for the entire resource/collection.

Resource Name

Resource made that will be accessible via the new reference. Uses the Data ID value (can be found via the Data section) of the resource, not its display name.

Reference Name

Name of the new data reference that will point to the fetched collection.

Queury Parameters

Additional query parameters for the API call that fetches the collection.

Save

Saves a data reference to the cloud.

Reference

The data reference whose current local state will be saved to the cloud.

Navigate Back

Navigates back to the previous page, if available.

Open Page

Opens a new page.

View

The page to open.

Parameters

Additional parameters to pass to the new page. These will be available as data references on the target page.

ID parameter for Details views

If you are programmatically opening the Details page of a CRUD page group, you should pass in an id parameter that contains the id of the record in question. This way, the Details page knows to fetch the correct record.

Set Variable

Set a local key-value pair variable. Including this actions makes the local variable available for use as a data reference.

Key

Key to save the value data to.

Value

Value to be saved.

Creating Custom Actions

You can create custom actions by either selecting the Create new... option from the action type menu, or cloning an existing action by clicking on the clone button in the action's properties.

The custom action syntax will be overhauled soon, so there's no official documentation available yet. However, you should be able to get a good sense of how they function by cloning some of the predefined actions and examining how they've been constructed.

Data References

Data references are pieces of data in the context of the currently running instance of your app. Data references can be used to bind UI components to app data, pass dynamic parameters to actions, modify data records in your app's resources and more.

There are seven kinds of data references.

Data (Collection)

Reference to a collection of data records from a single resource.

Data (Entry)

Reference to a single data record.

Data (Entry Field)

Reference to a single data field of a record.

Storage

Reference to a locally stored key-value pair.

Component

Reference to the current value of a component, such as a text input field.

Query Parameters

Reference to the parameters passed to the current page by the action that opened the page.

Page

Reference to a page in your app.

Whenever a data reference is available to be used in place of a static value, the field has a link icon that can be clicked to select the reference.

The link icon indicates that a data reference can be used in place of a static value.

The link icon indicates that a data reference can be used in place of a static value.

When clicking on the link icon, the data references that are available on the current page are shown as a dropdown list.

Data references available on the CRUD Details page for an Orders resource.

Data references available on the CRUD Details page for an Orders resource.

After selecting a data reference, the link icon and input field text turn blue to indicate an active reference.

Active data reference.

Active data reference.

Now, the Text property will get the value of the current data.Orders.Status reference and modify its parent component accordingly – in this case, changing the button text.

Data references can also be linked to action properties and connected data properties.

Two-Way Data Binding

All data reference bindings are two-way. This means that if the bound field's value can be changed in the app, the changes are reflected back to the data reference. For example, binding a local variable to a text input field's Value property will correctly display the variable's contents when the app loads, but also save all changes made into the data reference (thus also updating other bound fields – like the title of some other page).

A special case is references to data records and collections, where the current local state of the data model needs to be saved to the cloud for the changes to persist. This can be done with a Save action pointing to the record/collection data reference.

Utilizing data references in Custom JavaScript actions

Any data resources that have been linked to a page can be accessed in Logic Editor actions as properties of this. Let's say you have a resource call Lead defined for your page.

For example, to create a button that opens a prefilled Calend.ly link based on the data in the currently open individual Lead record, you could use the following Custom JavaScript:

var firstName = this.Lead.firstName;
var lastName = this.Lead.lastName;
var email = encodeURIComponent(this.Lead.email);

var query = "?name=" + firstName + "+" + lastName + "&email=" + email;
var baseURL = "https://calendly.com/my-calendly-organization"

supersonic.app.openURL(baseURL+query);

Logic Editor