... | @@ -55,3 +55,12 @@ As you can imagine, managing tethering requires quiet a bit of housekeeping. Do |
... | @@ -55,3 +55,12 @@ As you can imagine, managing tethering requires quiet a bit of housekeeping. Do |
|
<figcaption>Fig. 1 - Tethering Sequence Diagram</figcaption>
|
|
<figcaption>Fig. 1 - Tethering Sequence Diagram</figcaption>
|
|
</figure>
|
|
</figure>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
|
|
Fig.1 shows shows the sequence diagram of a widget implementing the **Tetherable** interface and using the **TetherManager** Helper class as a proxy for all things related to tethering. The diagram starts with the tetherable widget being moved by the user.
|
|
|
|
* The widget calls its **TetherManager**'s **move()** method to notify it about the change in position.
|
|
|
|
* This call sets off the tethering mechanism. First thing on the list is to update the tether origin of the tetherable object being moved.
|
|
|
|
* Next, the **TetherManager** iterates over all potential tetherable candidates, i.e. those which have been previously registered by calling the **addPotentialTether()** method.
|
|
|
|
* First of all, the manager checks for each potential candidate whether is *active* or not.
|
|
|
|
* If it is active, the manager retrieves the current position of the potential candidate's tether origin in order to determine the relative distance.
|
|
|
|
* The course of action depends on whether we're currently tethered with this object or not. A call to the candidate's **isTetheredWith()** will yield the sought answer.
|
|
|
|
* If we're currently tethered with this object and the distance exceeds our tethering distance, than the manager initiates the separation process by invoking the **separateFrom()** method. |
|
|
|
\ No newline at end of file |