| ... | ... | @@ -63,4 +63,4 @@ Fig.1 shows shows the sequence diagram of a widget implementing the **Tetherable |
|
|
|
* 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 |
|
|
|
* 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. It's interesting to note that the manager call's its hosting object's **separateFrom()** method. By doing so, the **TetherManager** notifies the **Tetherable** object about the impending separation, giving it a chance to get ready. Under normal circumstances, the **Tetherable** object's **separateFrom()** relays the call back to the manager's **separateFrom()** method, which in turn performs the actual separation from the candidate object. |
|
|
\ No newline at end of file |
