Multiple Behaviors

Another common scenario is a controller that connects into a specific data source or API and exhibits multiple functionalities.

For example, a social media controller might parse a chat and offer:

• A curated list of chat messages to select and show.

• A live poll compiled from votes in the chat.

• Special alerts that fly in and out when certain events occur.

Each of these could be connected to a different title, using different \variables, and intended for a different display purpose.

It doesn’t make sense to have a separate controller for each of these. Instead, one controller can log into the service, parse the data, and use it to drive these three different operations. So, it needs to present itself as a series of input instances, each with a different name, that share just one control UI.

In this example, “06a Multi Behavior” triggers an alert to one title, while “06b Multi Behavior” sends polling and image updates to another.

Here’s how it works:

XML Definitions for Shared Controller

Each input is represented by a separate XML file, but there are several attributes used to set the shared behavior.

The first input looks like this:

<inputBehavior
  name="API Tour: 06a Multi Behavior"
  url="tour/06_multiBehavior.html"
  iconOn="tour/tour_06.png"
  uiName="API Tour: 06 Multi Behavior"
  UIGroups="General"
>
  <variable name="Question" type="text" />
  <variable name="AnswerA" type="text" />
  <variable name="AnswerB" type="text" />
  <variable name="Image" type="image" />
</inputBehavior>

And the second looks like this:

<inputBehavior
  name="API Tour: 06b Multi Behavior"
  url="tour/06_multiBehavior.html"
  iconOn="tour/tour_06.png"
  uiName="API Tour: 06 Multi Behavior"
  UIGroups="General"
>
  <variable name="Question" type="text" tags="name" />
  <variable name="AnswerA" type="text" />
  <variable name="AnswerB" type="text" />
  <variable name="Image" type="image" />
  <variable name="PollA" type="graph" />
  <variable name="PollB" type="graph" />
</inputBehavior>

• The names are different. This ensures they show up as different inputs.

• The url, icon, and uiName are the same, because these are indeed managed by the same controller.

• The variables overlap, but they don’t have to. They could each drive a completely different set of variables.

Controller Code

The controller itself acts as a single source for two inputs.

In this case, it’s a UI that takes in information and uses it to drive alerts from Input A and updates from Input B.

The controller code cannot rely on ServiceHandler.inputName for the input name, because that will be registered only for the first input created. Instead, it needs to know the names as defined in the different XML files and use them directly.

let inputBehavior1Name = 'API Examples: 6a Multi Behavior';
let inputBehavior2Name = 'API Examples: 6b Multi Behavior';

Then, it calls to scheduleAction (it should use whichever inputName is appropriate for the action).

The first input triggers alerts. This flies in the title, holds it for the requested duration, and then flies it back out.

scheduler.scheduleAction('Alert', inputBehavior1Name, '', variables);

The second input triggers update actions. This assumes the title is already live and it is updating the displayed values with animation. So every time one of those sliders changes, it fills in the new value and calls:

scheduler.scheduleAction('Update', inputBehavior2Name, '', variables);