Skip to main content

Conditions

Conditions allow you to choose with granularity when to execute actions or display information. They can be used inside components or monitors, but also in actions. Conditions mainly work with variables, which can be input variables that are retrieved when the user entered some data, or general variables that you defined yourself.
A condition is a String that is evaluated at runtime by the application. This enables you to chain conditions.

Below is an exhaustive list of the available operators & operands.

info

In the tutorial An Octory Pro tour, you can learn how to deal with simple conditions.

Operators

Comparison operators

  • == for equal
  • != for different
  • > for greater than
  • >= for greater than equal
  • < for lesser than
  • <= for lesser than or equal

Advanced operators

  • contains for contains. The result is true if the left operand contains the right one. The left operand has to be filled with values separated by commas.
  • isIn for checking in an array of values. True when the left operand matches a value given in the right operand. The right operand is a list of string separated with commas. Use backslash to escape a comma in a string.
  • matches for matching values. True when the left operand matches the regular expression given as the right operand. The whole left operand has to match the regular expression to be validated.
  • hasPrefix for checking as prefix. True when the left operand starts with the right operand. Case sensitive. (~= can also be used as an alternative operand)
  • hasSuffix for checking as suffix. True when the left operand ends with the right operand. Case sensitive. (=~ can also be used as alternative operand)

Logic operators

  • && for and
  • || for or

Operands

You can compare a variable and an operand with a comparison operator. There are four types of operands.

  • String which are quoted with double quotes only
  • Number which groups all numeric values, including floating ones
  • Boolean which are written as true or false
  • variables which have to begin by a letter (lower or upper case) and can contain hyphens - and underscores _
info

Two variables can be compared. Note that boolean variables can be written without the == to evaluate if their state is true.

Examples

Given the following variables, here are some examples:

Variables

  • “isUserAWizard”: “true”
  • “userName”: “Gandalf”
  • “userAge”: “400”
  • “fellowship”: “Gandalf, Frodo, Sam, Aragorn, Gimli, Legolas, Boromir, Merry, Pippin”
  • “hobbit”: “Bilbo”
  • “passphrase”: “You shall not pass!”

Expressions

  • isUserAWizard == true && hobbit == "Bilbo" → true
  • userAge >= 400 || userName != "Saruman" → true
  • userAge < 400 && userName == "Gandalf" → false
  • (userAge < 400 && userName == "Gandalf) || fellowship <: "Aragorn" → true
  • isUserAWizard && passphrase == "You shall not pass!" → true
  • userName hasPrefix "Gan" → true
  • passphrase contains "sha" → true
  • "Sam" isIn fellowship → true
  • userAge matches '[0-9]{3}' → true

Conditionally insert or remove components or monitors

You can add a condition to any component. Octory will smoothly animate the insertion or removal of the component, depending on the result of the condition evaluation.
For example, if you define a ListInputComponent to ask the user their role in the company.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<!-- ... -->
<key>Slides</key>
<array>
<dict>
<key>Containers</key>
<array>
<dict>
<key>Components</key>
<array>
<dict>
<key>Type</key>
<string>Input</string>
<key>InputType</key>
<string>List</string>
<key>Variable</key>
<string>UserRole</string>
<key>Items</key>
<array>
<string>Consultant</string>
<string>Manager</string>
<string>Department Manager</string>
<string>Director</string>
</array>
</dict>
</array>
</dict>
</array>
</dict>
</array>
<!-- ... -->
</dict>

You can then display a TextComponent only for the director role, like this.

<dict>
<key>Type</key>
<string>Text</string>
<key>Text</key>
<string>I want a raise!</string>
<key>Condition</key>
<string>UserRole == "Director"</string>
</dict>

Or you can display an input component only for the Consultant and Manager roles with the contains operator <:

<dict>
<key>Type</key>
<string>Input</string>
<key>InputType</key>
<string>Text</string>
<key>Condition</key>
<string>"Consultant, Manager" <: UserRole</string>
<key>Label</key>
<string>Who is your manager?</string>
<key>Variable</key>
<string>UserManager</string>
</dict>

If you define a variable in General → Variables like NonDirectorRoles: “Consultant, Manager”, you could simply write the last component this way.

<dict>
<key>Type</key>
<string>Input</string>
<key>InputType</key>
<string>Text</string>
<key>Condition</key>
<string>NonDirectorRoles <: UserRole</string>
<key>Label</key>
<string>Who is your manager?</string>
<key>Variable</key>
<string>UserManager</string>
</dict>

It is a good practice to store all your variables in the Variables array to avoid to repeat yourself, which is error prone. That said, you can even store conditions in the Conditions array to avoid to repeat this condition in several components.

<array>
<key>IsUserNotADirector</key>
<string>NonDirectorRoles <: UserRole</string>
</array>

Finally, your component would appear even clearer.

<dict>
<key>Type</key>
<string>Input</string>
<key>InputType</key>
<string>Text</string>
<key>Condition</key>
<string>IsUserNotADirector</string>
<key>Label</key>
<string>Who is your manager?</string>
<key>Variable</key>
<string>UserManager</string>
</dict>

Monitors

When adding a condition to monitors, you should keep in mind that the user can exit the application depending on the monitor installation states (unless you deactivated this behaviour with the UserCanQuitIfInstallationIsIncomplete key in the navigation section).
Thus, if all the monitors whose conditions are validated are installed, the user will be able to exit. That said, conditionally inserting monitors to be installed lets the user being able to exit by changing an input which validates some monitors but not the ones they are supposed to wait the installation for. Taking this into consideration, you might want to use the key HidePreviousButton for a slide to prevent the user from changing their choice.