This page explains the class structure of the objects that Thing Interaction Framework and its SDK are based on.
Note that the structure presented on this page is the conceptual model unless stated otherwise, so it may be different from the class relationship in the SDK.
The following diagram illustrates the structure of thing-related classes. The structure is hidden under the
ThingIFAPI class implementation-wise.
Thing, the subject to be controlled, is represented as a subclass of the
Target. Currently, the thing is the only destination for sending commands. The concept
Targetis introduced to expand the destination in the future (i.e., sending commands to mobile applications and other types of devices).
- The thing owner is represented as the
Owner, and the
Useris defined as its subclass. The concept
Owneris introduced for expanding this relationship in the future (e.g., adding admin accounts).
Targetcan have multiple
Schema. In the SDK implementation, multiple instances of the
ThingIFAPIwill be generated and each of them will have one schema.
Targetcan have triggers, commands, and state with the multiplicity shown in the diagram.
The following diagram illustrates the structure of command-related classes.
- As explained in Action and Command Execution, the
Targetis identified as the destination for sending commands. As already explained, the
Targetis an abstraction of the
Thing. In the actual SDK, this is not implemented as a class reference. The SDK has the
Targetas an ID.
The following diagram illustrates the structure of thing-related classes.
Triggeris a class used for the trigger execution explained in Auto Execution with Triggers.
- It has a
Commandwhen you are auto-executing a command.
- It has a
ServerCodewhen you are auto-executing server code.
The multiplicity of the
ServerCodemust not be 0 at the same time. They are exclusive, so only one of them can be 1.
- It has a
Predicatecorresponds to a "predicate" of the predicate logic, and it represents a function that returns if the trigger execution condition is satisfied or not. It can have the
StatePredicatethat covers the state comparison based condition, the
ScheduleOncePredicatethat covers the one-time schedule, and the
SchedulePredicatethat covers the recurring schedule.
Commandwhen auto-executing the command, but this is merely the template of the command. The actual command for the execution is created using this template.
The next diagram illustrates how the
Trigger and subsequent classes are implemented in the SDK. All class names are from the Android SDK. The iOS SDK also has the same structure, but some of the class names are different.
- The relationship between
ServerCodeis the same as that of the conceptual model. You will use a pair of
SchedulePredicateas its subclass.
StatePredictefor making the state comparison has a
TriggersWheninside. As explained in State Condition, they correspond to the comparison condition (what to compare) and the execution condition (how to associate the condition to the command execution). The
TriggersWhenis the enum implementation-wise, so you will use it as an attribute of the class.
ScheduleOncePredicateto designate a time has the
scheduleAtattribute inside. As explained in One-Time Schedule, it is a time condition to execute a trigger once.
SchedulePredicateto designate a time has the
scheduleattribute inside. As explained in Recurring Schedule, it is a time condition to execute a trigger on the scheduled interval.
Clausethat is a root of the tree structure. You can define the condition using its subclasses (e.g.,
NotEquals). You can use the recursion for the