Allow parallel commands over ADBΒ #24
Description
Currently, one can only issue one command at a time. Issuing two or more will cause issues with the data being intermixed because the ADB client assumes a local-id of 1.
My current proposal is to alter the internal use of the AdbMessage
class so that an instance is used, which holds the handle (also renamed to transport instead of usb to match android-adb). In the various Connect
classmethods in AdbCommands
, it will create a new instance of that class, but there will be a new method that accepts an existing instance. This will allow a new parallel version to be used, but only by folks interested in that, so we don't affect or slow existing users.
An entirely new class will be created for parallel connections, likely a thin wrapper around a dict of the AdbMessage
replacement.
This will result in two things:
- Everything inside of
AdbCommands
will change rather drastically, so anyone using internal functions will get bit. We'll have to do a major revision change. - Users who didn't reach past
AdbCommands
and want parallel commands will have to make code changes to specify that, so they get the 'optimized' version that only allows a single stream.
The reason for allowing, and defaulting to, a single stream implementation is not as much for performance, as it is to reduce complexity in the normal case. The multi-stream version will have dispatching and lookups interleaved with everything a single-stream version has to do, making debugging more confusing. Users should be able to avoid multi-stream support when they don't need it, and be able to switch to single-stream when they're debugging something that may falsely show up as an adb issue.