Workflow

[Erhannis]

Re: #69 (comment)
Regarding the workflow of scanning for devices, connecting, scanning for services.
At the moment it's a pretty finicky process - depending on platform, you need to, in order,

1. scan devices
2. connect to the device you want
3. scan services on that device
4. notify characteristics etc.
   If you omit any of those steps, after ANY disconnect (maybe you don't need to rescan devices?), things may mysteriously fail, depending perhaps on platform.

At the moment, the API doesn't enforce any of this ordering, or really even warn you if you fail to do it, AFAIK. I feel this could be improved somehow.

1. More checks and informative errors? "No service scanning has been performed since last connect" etc.
2. Automatically rescan etc. when necessary. This is a liiiiitle invasive, but given how broken things can get if it doesn't happen, may be worth it. Perhaps there could be a flag to disable it if one really doesn't want the default behavior.
3. Mention was made of using object handles rather than e.g. service Strings. I'm sorta 50/50 on it - it does encourage the proper workflow, at least the first time around, but makes e.g. connecting from saved configuration a little more annoying, presumably having to filter objects by one's known uuids, etc., rather than directly submitting the uuids. Also, it doesn't prevent a user from e.g. keeping a stale object, though I guess you could have them throw errors once they're invalid. One note in favor of the object route, though: horrifyingly, the BLE specs permit more than one characteristic on a given service to have the same UUID. Worse, I have seen it done in practice. (The same MAY be true of having more than one service with the same uuid, I forget.) This is surprising behavior and most BLE libraries/apps do not handle it. I modified a ble library to deal with it by appending an optional e.g. ":2" index after the uuid, but a more "standard" way it seems like e.g. Android handles it is to just use Characteristic objects. I'm partially tempted to ignore the duplicate-uuid "feature" as being horrible and I won't stand for it, but arguably it IS part of the spec, so....

Sorta leaning towards 2 with disable flag, as being easiest to use out of the box while maintaining flexibility.