There is some progress for scanning, you can track it here, and also see the specifics in the Chromium Tracking Bug. It seems like they are targeting MacOS and Android for the initial release.
You can also participate in the discussions in the WebBluetoothCG repo, for instance, this issue about Sevice Worker support.
Hello Andrey, I’d suggest to type
chrome://bluetooth-internals/#devices in Chrome’s address bar and then click “Start Scan” (on the right side) in order to see which devices Chrome can find. You can also try the nRF Connect application for Android to check which BT devices are advertising in your proximity.
I also asked myself the same question a few months ago. After spending a day researching the subject, it seemed like there is almost zero information about the internals of modern phones, and that they are unlikely to have any accessible hardware debug interface. Thus, writing the hardware drivers for such an embedded system will be a very…
Thanks Marius! Yes, I wrote another article about my experiments with running Ivy with Angular 7 inside StackBlitz. Basically, as you mentioned, you have to call
markDirty() unless you use something like Zone.js which triggers the CD for you. You can read the full story here:
Yes, things have changed since I wrote this post — the WebAR standard merged with WebVR into a new WebXR standard, and the ecosystem is in progress of adapting to the new standard. A new version of a-frame, 0.9.0, has just been released, and it includes initial support for WebXR. Once things stabilize a bit more, I will update the blog post (and the…
Totally agreed! The experimental APIs have landed in Chrome, but they have changed since I wrote the article, and the ecosystem hasn’t fully adapted yet. Hopefully things will get much better in the coming months — aframe has just released version 0.9.0 with support for the new WebXR standard, which is the first step towards enabling AR in a-frame to…