Comments (10)
@armansito since that's copied directly from the Chrome API.
The DescriptorEvent was used for DescriptorValueChanged, which I removed in #18. I'll leave it for now in case another descriptor event comes back.
from web-bluetooth.
This is an idea that I toyed with while designing the Chrome API as well. What I finally decided was that it was more intuitive to fire a single event (onServiceAdded) at the end of the initial discovery of all characteristics/descriptors than to have a succession of onServiceChanged/onCharacteristicAdded events.
Similarly if an existing service definition changed and we received a "Service Changed" event, I find that it is more intuitive to fire a single onServiceChanged event after we rediscover all characteristics and descriptors and have the application reprocess all of them in a single event.
So I suppose we should clarify that onServiceChanged is reserved for indications from the "Service Changed" characteristic?
from web-bluetooth.
So I guess this is what happened as ServiceChanged:
(1) GATT server sent ServiceChanged indication
(2) bluez bluetooth stack received ServiceChanged indication and automatically start re-discovery services (call gatt_discover_primary?)
(3) onServiceChanged gets called once for a service after all of its characteristics and descriptors have been discovered
Question: Shall we expect BluetoothGATTServiceSequence in ServiceEvent? Maybe there will be two or more services changed?
I'm not sure this is a good question but I'm confused.
from web-bluetooth.
Pretty much. If two or more services changed, then we either send multiple onServiceChanged events, one for each service that was modified, or we have a single onServicesChanged that takes in a BluetoothGATTServiceSequence; either way is fine. If any services were removed or added, then we send onServiceAdded and onServiceRemoved events for them.
Note on BlueZ: With the current BlueZ APIs that we're trying to deprecate (the code in attrib/), we would call gatt_discover_primary. What BlueZ will do to propagate this information is something do decide. In the Chrome OS specific implementation, I simply remove all services and rediscover everything after a Service Changed indication. This is definitely a stop-gap solution. I'm still revising the proposed D-Bus API and in the process of implementing it for upstream.
from web-bluetooth.
And we don't have to call onCharacteristicValueChanged if the Characteristic is << ServiceChanged >>
, even if it's an indication, right?
from web-bluetooth.
It depends. If we decide to expose the << GATT >>
service then we should probably allow an app to call BluetoothGATTCharacteristic.startNotifications on the ServiceChanged characteristic (even though apps wouldn't be permitted from actually disabling indications from it). In that case, we would send an onCharacteristicValueChanged event. That said, there isn't much the app can do with it.
If we're blacklisting the << GAP >>
and << GATT >>
services and hiding them from the applications, then we wouldn't call onCharacteristicValueChanged. (I'm leaning more towards this).
from web-bluetooth.
In that case, we would send an onCharacteristicValueChanged event. That said, there isn't much the app can do with it.
The reason I asked is because the application already get information updated from onServiceChanged/onServiceAdded, and it looks like we duplicate information again, and <<ServiceUpdated>>
Char comes with attribute handles, the application cannot use the handle value directly to do anything.
If we're blacklisting the << GAP >> and << GATT >> services and hiding them from the applications, then we wouldn't call onCharacteristicValueChanged
This is ongoing Issue #24
from web-bluetooth.
You're right, in that it's redundant. Then again we would only do this if the application specifically requested to get notifications from that characteristic.
We can discuss this as part of issue #24. I think as far as this issue goes (whether to add Added/Removed events for characteristics/descriptors), I think we all agree that a single onServiceChanged event is sufficient?
from web-bluetooth.
It sounds like it makes sense to expose the ServiceChanged
event directly and not make the UA parse it into a cloud of CharacteristicAdded
, CharacteristicRemoved
, DescriptorAdded
, and DescriptorRemoved
events. Websites can use the Characteristics' and Descriptors' instanceId
s to identify precisely which ones have appeared or disappeared. I'll close this in a couple days if nobody's spoken up by then.
from web-bluetooth.
For the onCharactersticAdded/Removed, onDescriptorAdded/Removed, I agree the conclusion here, a single onServiceChanged should be sufficient.
We can discuss further about service changed characteristic in issue #24 as @armansito suggested.
Thanks!
from web-bluetooth.
Related Issues (20)
- requestDevice filters to exclude devices. HOT 1
- Would be nice to enable the Discussions on this repo, not everything is an issue HOT 1
- [watchAdvertisements] Support Extended Advertising HOT 8
- can't access services list on some devices HOT 2
- Kerem
- Services not found (Primary detected as Secondary?) HOT 3
- Using Bluetooth from WebExtension HOT 1
- Permissions API Extension HOT 3
- Not working with MacOS Sonoma + Intel HOT 1
- Add requestDevice User Prompt BiDi Extension Section to Bluetooth Spec
- p2p connection options HOT 3
- Filter on or prefer paired devices HOT 1
- Spec vs Chromium implementation. HOT 4
- Proposal does not reflect Chromium's dynamic device selection HOT 1
- Proposal: active scanning with scan response HOT 7
- navigator.bluetooth.requestDevice (opt) same filter but ios browser bluefy doesn't work HOT 2
- Unable to connect to the device, the error message is as follows HOT 1
- Broken references in Web Bluetooth
- Broken references in Web Bluetooth
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from web-bluetooth.