Tethering is a feature which allows Tetherable objects to be dynamically tied together, based on their relative proximity. The original idea for this feature goes back to a very early scenario, the Windmill scenario, where pupils got the collaborative task of maximising the power output of a windmill by modifying a number of parameters. The aim of this task was for them to understand which parameters had an influence on the power output, and which didn't have any influence at all. While re-working the scenario, implementing a more realistic Windmill model, the idea came up to implement a kind of probe which would allow to measure a number of otherwise hidden parameters. The probe was a dedicated widget which, if brought close enough to the windmill part of interest, would display a parameter directly related to that part.
Each Tetherable object defines a tethering distance, which defines a radial zone around the object. Lets assume we have two Tetherable objects on the table.
Even though the zones defined by their respective tethering distances overlap, the origin of object B is not yet in the tethering zone of object A. Now, lets move object A a bit closer to object B.
By moving object A closer to object B, object A detects that a potentially tetherable object is within its tethering distance. Object A initiates the tethering process by perform a handshake with object B in order to find out whether it is ready and willing to be tied to object A. If this is the case, the link between the two objects will be established, visually shown by a Tether being displayed between the two objects. Objects A and B may be moved and the shown Tether will follow along as long as the relative distance between A and B is smaller than A's tethering distance. If this distance is exceeded, then the Tether is torn down and both objects are no longer tied together.
It is important to note that tethering is not limited to tangible objects alone. Coronas, Markers and even Content may become potential tethering candidates, provided they implement the required Tetherable interface.
As we have just seen, Tether's take care of visually showing that two tetherable objects are tied together. But their purpose doesn't stop there. As you might have guessed, when establishing a connection between two objects, we're also establishing a kind of communication channel between the two objects, one of them providing information which is then received by the other. So Tethers in fact have a direction, with information flowing from the providers to the receivers. Tethers are defined in the scenario's connections section.
<connections> <tethers> <tether> <type>Line</type> <name>Windmill Probe</name> <strokeWidth>2</strokeWidth> <strokeColour> <rgb>0xFF0000</rgb> </strokeColour> </tether> </tethers> </connections>
The example above shows the declaration of a simple Line tether, with a
strokeWidth of 2 and red as its colour. Please note that we don't have to define a direction at this stage. The direction of the data flow will be determined by the tetherable objects using this Tether as their link.
The following are the common properties that all tetherable objects share:
- The mandatory
distanceproperty defines the radius of the tethering zone for this particular tetherable object. An optional
stateproperty allows specifying in which coordinate system the distance is expressed.
- The optional
originOffsetdefines the spatial offset for the tether origin, which, if not specified sits on the objects origin itself. The
originOffsetproperty might be used, for instance, to move the sensitive part of a pointing object to the tip of the physical object.
- The optional
- The optional
exclusiveflag specifies whether this tetherable object can be tied to more than one object, or, whether it accepts only a single one.
- The optional
rotatesWithTetherflag specifies whether or not this tetherable object rotates together with its Tether. By setting this flag to true, object A's orientation would follow object B if the later would orbit around object A.
providerslists one or more Tether's, considered to providing information to this tetherable. So by specifying a given Tether in the
providerssection, we automatically declare to be at the receiving end of the respective Tether.
receiversalso lists one or more Tether's. However, contrary to the previous declaration, Tethers specified here will receive information from this tetherable, this tetherable will feed data into the respective Tether.