I accessed the Chrome BLE API page (5/7/2016). there seem to be conflicting information messages (see image below). Does this work on Chrome OS only, or OS X and Windows also?
EDIT/UPDATE:
I tried the demo application (demo BLE API) on Windows 10. It was able to see paired devices, but not unpaired devices. I got an error message: Battery device not supported on this platform. I'm not sure if this is because of the test vector I used (LightBlue), or another issue.
System:
Windows 10 64 bit
Surface Pro 3
The chrome.bluetoothLowEnergy API works only for paired devices on Windows as it still uses (at that time) Windows 8 APIs to retrieve paired devices only: https://chromium.googlesource.com/chromium/src/+/08c9d69b0c0d625d2ce38e3d8402f36e1226f0fc/device/bluetooth/bluetooth_low_energy_win.h#117
For info, the Web Bluetooth team plans to support Windows 10 as much as feasible: https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/implementation-status.md#chrome
Reading through your given documentation wherein you referenced the use of navigator.bluetooth, Interact with BLE devices on the Web also states that:
Web Bluetooth API is at the time of writing partially implemented in Chrome OS and Chrome Dev for Android behind an experimental flag.
Hence, you got undefined as a return value.
Functionalities were provided by Bluetooth Low Energy (BLE) through key/value pairs provided by the Generic Attribute Profile (GATT).
Related
According to Microsoft's latest docs:
Do I have to pair Bluetooth devices before using them? You don't have
to for Bluetooth RFCOMM (classic) devices. Starting with Windows 10
release 1607, you can simply query for nearby devices and connect to
them. The updated RFCOMM Chat Sample shows this functionality.
However, when I try to connect to my devices using this chat sample, I get a notification that asks me to "set up the device", like I was going through a normal pairing process.
Am I missing something?
The snippet of code that I changed from the sample:
var rfcommServices = await bluetoothDevice.GetRfcommServicesAsync(BluetoothCacheMode.Uncached);
Taken from msdn resources:
Windows 10 Mobile is currently limited to connections with only paired
devices. In Windows 10, you can programmatically pair/unpair. See
scenarios 8 and 9:
https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/DeviceEnumerationAndPairing
Here’s is the related MSDN documentation on pairing and the relevant
device selectors for enumeration.
https://msdn.microsoft.com/en-us/library/windows/apps/windows.devices.enumeration.deviceinformationpairing.aspx
https://msdn.microsoft.com/en-us/library/windows/apps/windows.devices.bluetooth.bluetoothdevice.aspx
But I also know that you can use direct bluetooth connections on lower level and this way windows won't suggest you pairing. For example, that's how things work with 32feet.net library, discussed in this answer (I worked with it and it was fine, however it is currently unsupported so please beware of it).
First thing to test is the bluetooth protocol used to be RFCOMM in both client and server. Link
Check that both client and server hardware support the RFCOMM
Check the bluetooth versions in both client and server link
based on wikipedia bluetooth has many protocols.
Second is to check windows version
I am creating a mobile application that can detect iBeacons and I am confused which windows devices support that. I already checked that it's possible in Windows 10 but somewhere I read that it's also possible for Windows 8.1.
Unfortunately, it is not possible to detect beacons with Windows Phone 8.x because the OS has no built-in beacon support and does not allow apps to access raw Bluetooth LE scan results.
You can read more info about this here: https://stackoverflow.com/a/30603394/1461050
Just curious to understand why iOS devices connect to sphero directly but an app needs to do it in Android?
Well that's what I guess is happening because sphero will keep flashing in identity colours in Android until an app completes a connection.
To add: to use the option that keeps the sphero alive on the charger while connected to the client, then IOS would not need an app running but Android would. Well the Android app could have a service running to keep a connection open with sphero.
But ideally a consistent behaviour would be better.
Kasuku, you're correct in your post, but you also need to consider that the operating systems that you are comparing are completely different. For example, in Android it is possible to directly access the bluetooth adapter and "manually" connect to a bonded device. In iOS, this functionality is abstracted out from the developer.
To address BTLE:
No, as of right now Sphero currently does not support BTLE hardware.
OK ... as usual this tag seems to be dead so I post my finding anyway:
Bluetooth hardware that wanted to connect to IOS, but were not following one of the standard profiles (e.g. headsets), need to conform to Apple's proprietary MFI (Made for IOS) protocol. So the connection is established by the IOS system and then it allows apps to access this connection.
But now newer IOS devices support Bluetooth LE so the MFI restriction no longer applies. I think Sphero2B is going to use this. Current Sphero hardware probably doesn't support BT LE. My next question is ... does sphero hardware support BT LE? ... but I'm not going to ask on this forum:)
Android on the other hand allows apps to negotiate the connections to paired devices.
Here's a link with more info:
Some blog
I have been long interested to develop on the platform. I even got the tools installed already on my desktop but I can't upgrade my WDDM from 1.0 to 1.1. To make things simple: my graphics chips are not up to the task of running the emulator.
If I still buy a Windows Phone (e.g. a Nokia Lumia) for development purposes, can I sideload and test my apps there efficiently instead of going against the emulator?
If I still buy a Windows Phone (e.g. a Nokia Lumia) for development purposes, can I sideload and test my apps there efficiently instead of going against the emulator
Yes, of course. It's very easy and convenient. You have debugger and all the goodies. Advantage of the emulator is the test option for 256MB devices.
That's exactly what I used to do prior to upgrading my devstation. The nominal min spec says 3G but with a real phone it worked fine in 2G and as you say this also sorts out graphics limitations.
Note that the setting for whether the emulator or physical device is used is stored in the project, so if you accept a project from someone else you will have to set it once prior to debugging.
Well there are 2 sides of the coin. With the physical device you can test most of the things, but with a few limitations
You will not be able to test internet related test cases - For example, if you have an app which uses internet connectivity then you will not be able to test it on the device easily because
The device does not use the machine internet connectivity
When connected to the PC the device's internet connectivity(Data connection 3G/ wifi/GPRS) is broken.
You will have to purchase an account right from the first day you want to test your app. If you have the emulator working then you could postpone this for atleast few days.
Does the Windows Phone Test Framework by Expensify support testing on real mobile devices running windows phone 7 OS ?
If yes, which devices does it support? Please reply.
It depends what functionality you want to test.
The framework uses 3 different APIs to talk to the apps:
a COM API to talk to install/uninstall and start/stop apps
Silverlight automation peer support (communicated to using HTTP) to
talk to the silverlight controls within the apps - this allows get
and set of values, some list manipulation and inspection of the
visual tree.
Mouse and keyboard emulation to control the emulator
device - this is needed to do things like physical touches, hard
button presses (and other emulator interactions when the app isn't
running - e.g. taking photos).
For devices attached using USB: 1 and 2 are available
For devices attached using a network: 2 only is available
In summary, you can do some things if you want to... but I don't use the test framework to test real phones - I stick to the emulator. When external inputs (e.g. camera or gps) are needed then I find a way to mock them
according to the first few seconds of http://www.youtube.com/watch?v=2JkJfHZDd2g "there is some support for devices".
I would hope/expect all devices to devices to behave the same way, subject ot how they're configured.