Open jimaobian opened 7 years ago
@SidLeung has anyone from the Intel team looked into this?
That's expected. Because your code use BLE object. The BLE object is used to manage the local device. So the code always return false.
In your code, you need get the connected device and use this BLEDevice object to call connected method.
BLEDevice central = BLE.central();
if (central && central.connected()) {
// Do what you want
}
That's expected. Because your code use BLE object. The BLE object is used to manage the local device. So the code always return false.
@sgbihu I disagree with this expected behaviour.
The original spec we discussed had:
bool connected(); // is the device connected
So I expect BLE.connected()
to return true is a central is connected, when the 101 is in peripheral mode.
Hi @sandeepmistry ,
I disagree with your opinion too.
So I think your opinion want return true if the BLE has any connected device. Do you think this is necessary?
The BLE
instance of BLEDevice
represents the local BLE device, soBLE.connected()
should return if the local device is connected to a central.
Another scenario is the BLE is work in central mode. Does it return true if peripheral connected to it?
If return true. Does this API can adapt here? If not, why peripheral and central don't have same behavior?
@sgbihu Hi, for my view BLE.connected()
should be true whichever BLE is in central mode or in peripheral mode as they are actually "connected". Just keep the API simple and easy to understand.
For the ambiguous about the the connection state of central mode and peripheral mode at same time. I think it is a minor requirement. And users can use api like yours to get the different connection state of the two mode:
BLEDevice central = BLE.central();
if (central && central.connected()) {
// Do what you want
}
BLEDevice peripheral = BLE. peripheral();
if (peripheral && peripheral.connected()) {
// Do what you want
}
I agree with @jimaobian's comment above.
Folks:
Would like to summarize the discussion in a conclusive manner and to identify tasks to bring fruitful results,
To address the above issues, I would like to kick off a proposal to re-structure the BLEDevice class. Please consider the following class diagram,
This is a realization of various classes based off the parent class, BLEDevice. Using the above class structure, performed a simple exercise of putting several methods (of the BLEDevice class) to the corresponding classes.
It would be more efficient if we can first settle on the re-structuring of the BLEDevice class and that tag some of the methods to each identified class. Please note that this is a kick off of the re-structuring exercise, nothing is set in stone at this point. Please comment.
@sandeepmistry
I can see one major obstacle to my proposed changes to the BLEDevice class - the class definition is released to the public. There are sketches using this definition. If some of the methods are moved (re-classified) to the derived classes, these sketches will fail to compile. The proposed hierarchical class structure is a logical description of the class interaction and classifies the behavioral relationship accordingly. The structure validates the each method and implicitly defines its application. The existing flat structuring of the BLEDevice has the initial advantage of easy to get started. However, the baggage of describing the limitations of each method with respect to various condition is quite demanding on the documentation. The chance of confusing a user is much higher especially in the case of using the library without reading the documentation.
@SidLeung I propose we go with a more simpler change like PR #528 in the short term.
The class diagram you proposed makes sense logically, however I don't think we need a major refactor now. Although, some users might want to call BLE.hasService(....)
to see if the local device has the desired service.
The existing flat structuring of the BLEDevice has the initial advantage of easy to get started. However, the baggage of describing the limitations of each method with respect to various condition is quite demanding on the documentation.
We'll find out soon, when the CurieBLE reference on the Arduino site is updated for the new 2.0.2 release. I don't expect too many headaches at this point.
@sandeepmistry Thank you for understanding the dilemma I was pondering upon - refactoring a public facing definition or document the operating condition for each method. Apparently, this is an unfortunate choice of the lesser evil. I lean towards the refactoring of the BLEDevice class due to the fact that the instances we ran into as we were developing our comprehensive test scripts for the BLE section. A simple exercise like the following would give a first time user a bit of head scratching,
BLEDevice central = BLE.central();
central.scan(); // Can't do that! It's a remote Central device. But the method is available? But the
// situation invalidates this behavior (method).
BLE.scan(); // This works. BLE is the local device. But it is a Peripheral and it is connected to a
// Central. The stack supports both roles at the same time!
That's a bit of explaining for one method, scan(). In fact, @sgbihu has grouped all the BLEDevice methods with the following spread sheet,
I am concerned with the fact that we may have a user experience issue budding here and the time is now to nip it. I would urge you to reconsider the refactoring of the BLEDevice class.
Hi @SidLeung ,
I can understand your concerns, but the APIs make a lot of sense in the BLE world, where a device (BLEDevice
in this case, in fact "the object") can change role.
The remove-vs-local behaviour reflects this duality; of course some functions can't be used on the remote (or makes no sense on the local since you already have that info available as a variable).
In the non-embedded world, you would throw an exception when you are calling a function on the "wrong" object, but the way it's handled right now is ok from my POW.
I'd merge https://github.com/01org/corelibs-arduino101/pull/528 since it's an easy solution to a complicated problem, and wait to see the adoption rate of the new APIs and the number of forum requests to decide if we need to enforce some behaviours.
Will make this change in Elnath.
https://jira.ndg.intel.com/browse/ATLEDGE-857 I think this is addressed by PR454 and jira 857 and it was closed. I think we can close this issue @SidLeung
Will re-test when merged for Elnath.
testing other BLE issues. Will retest for Elnath release.
Here is the code. It always return false, even BLE is connected.
corelib Version: 2.0.1-RC2