public class ClassicDiscovery
- Object
- Observable
- AsyncResource<Boolean>
- ClassicDiscovery
Live handle of a running classic discovery (inquiry scan, ~12 seconds)
returned by
BluetoothClassic.startDiscovery(ClassicDiscoveryListener).
As an AsyncResource<Boolean> the handle resolves when discovery
ends: with true when the inquiry finished (naturally or via
stop()), or with a
BluetoothException when the OS aborted it.
cancel() is equivalent to stop().
Constructors
protected ClassicDiscovery() | Created by BluetoothClassic; application code receives instances from startDiscovery. |
Methods
public void stop() | Aborts the inquiry; the handle resolves with true. |
public boolean isActive() | true while the inquiry is running. |
public boolean cancel(boolean mayInterruptIfRunning) | Equivalent to stop(). |
protected void onStop() | Hook for the port to abort the platform inquiry; invoked exactly once from stop(). |
Inherited nested types
Inherited methods
From AsyncResource
isCancelled, all, all, await, await, waitFor, get, get, get, isCancelled, isDone, isReady, ready, ready, except, except, complete, error, await, addListener, onResult, asPromise
Constructor details
ClassicDiscovery
protected ClassicDiscovery()BluetoothClassic; application code receives instances
from startDiscovery.Method details
stop
public void stop()true. A no-op when
discovery already ended.isActive
public boolean isActive()true while the inquiry is running.cancel
public boolean cancel(boolean mayInterruptIfRunning)stop().Returns
True if the resource loading was cancelled. False if the loading was already done.
Cancellation notifies observers, which is how a waiter learns the
resource became terminal. It used to call setChanged() and stop there,
leaving the flag set with nothing notified: a thread inside get()
adds an observer, checks isDone(), and then waits, so a cancel
landing after that check woke nobody and the waiter blocked forever on
a resource that had already finished.
It deliberately does not run the callbacks registered through
ready(SuccessCallback) or except(SuccessCallback). Cancelling
means the caller has stopped listening, and publishing to it anyway
would contradict a contract the rest of the framework is built on and
tests – see the AI language and vision suites, which assert that a
cancelled operation delivers neither a value nor an error even when the
backend answers afterwards. Observers are the internal wake mechanism
for get() and waitFor(); they are not the application’s callbacks.
One consequence worth knowing: cleanup wired through
onResult(AsyncResult) does not run on cancellation either. Anything
that must be released has to be released by whoever owns it. A
per-operation timeout timer, for instance, survives until its deadline
and then retires itself on finding the resource already done.
onStop
protected void onStop()stop().