I am planning to do a universal shared library for Windows/Phone 8.1 and greater.
Any hints, Laura?
I guess I can get an android device to compare with, but it might be helpful to get an overview of how things are supposed to work. Are there any in-depth descriptions of how the functions on the board are addressed?
If you are seriously considering building Windows Phone support for out product then please send me an email so I can send you the documentation you need: hello@mbientlab.com.
@paul yeah, I know, but the problem I'm having is trying to keep the same API signature as the Android API, which is the only API we have the source to. That is a bit more difficult because of the way the Java is written.. That takes A LOT longer than just "talking to it", which I've already done by brute-forcing it.
The other problem is a 10+ hour a day regular job, but I'm getting there. I hope to have an initial PCL in the next week or so.
Laura, I never got any documentation email from you. Did you get my email to hello@mbientlab.com?
I think that others touched on it, but I am having to clean up some places where members and methods have the same name. I think most of us prefer the idea of using getxxxx style accessory, so that's what I'm gong with to remove the clashes.
Also, it doesn't appear that the current Java API would support more than one device. I think that all that would be necessary to do that would be to get another N product ID's so that the system could tell the difference, and then make some of the static pieces of the API non-static.
I could be wrong about the API though, because I have no Android device or ADK to run with yet.
The Java API as it is only supports one connected device. It is possible to have multiple ble connections however, the Android Bluetooth stack can only broadcast one message at a time so I did not bother with supporting multiple connections for the current release.
As far as converting the Java to C++, the only silly thing about the Java API is the MetaWearBleService class. Because of how the Android platform handles things, namely:
The aforementioned Bluetooth stack limitation
How one would enable characteristic notifications on Android
When GUI changes are allowed to be made i.e. can't be done in a BluetoothGATT callback function
the service class ends up being cluttered with what seems like unnecessary code that would otherwise be in separate classes or removed altogether.
I'm doing the Windows port now. The port is a Windows Portable Class Library for Windows Store apps in C#, and therefore should be usable on Windows and Windows Phone 8.1 and greater.
I have a decent level of completeness on all the service and characteristics classes as well as registers. There are a few changes in the signatures because of the differences between Java and C#.
I'm in the process of working through the MetaWearBleService class now. As you said, some of it goes away, and other parts have wholly different code in order to be compatible with Windows.
On Windows:
o One would have to first pair the device
o Assign a PNP watcher to it (that would handle sending the DeviceCallbacks for connected and disconnected)
o Hook into the notify event for any characteristics that support it.
o The notify event will then drive the rest of the callbacks.
There is another somewhat large difference in Windows in that one doesn't receive callbacks for characteristics that are read. One simply reads the value from the characteristic (async), which then either comes from the cache or from the device, depending on how the call is structured.
Still fooling with it, but this limitation may end up causing some cross thread difficulties, as one would
o Read the characteristic
o Receive the result
o Call the callback in line
Doing the callback in line will also expose the API to being stalled by user code which handles the callback.
I already had a brute-force hack working where I just set up a characteristic read and notify hook on the accelerometer.
I'm hoping to converse with the board via the API in some limited ways today.
My Windows Store Portable Class Library is somewhat usable now. Just waiting to make contact with Laura to find out what she wants to do as the next step.
I've successfully read Accel values, the switch, and blinked the LED to date. More to come.
Hi Eric, I am working with your code from codeplex. Does the accelerometer example work? When I run the application, I can connect to my board, and turn on the LED, but I cant figure out how to get accelerometer data.
Comments
I am planning to do a universal shared library for Windows/Phone 8.1 and greater.
Any hints, Laura?
I guess I can get an android device to compare with, but it might be helpful to get an overview of how things are supposed to work. Are there any in-depth descriptions of how the functions on the board are addressed?
-thanks
-e
I will do so.
A nice demo would be an Xbox One fitness app or something. If you would like to collaborate on that, let me know!
@paul yeah, I know, but the problem I'm having is trying to keep the same API signature as the Android API, which is the only API we have the source to. That is a bit more difficult because of the way the Java is written.. That takes A LOT longer than just "talking to it", which I've already done by brute-forcing it.
The other problem is a 10+ hour a day regular job, but I'm getting there. I hope to have an initial PCL in the next week or so.
Laura, I never got any documentation email from you. Did you get my email to hello@mbientlab.com?
Laura,
I think that others touched on it, but I am having to clean up some places where members and methods have the same name. I think most of us prefer the idea of using getxxxx style accessory, so that's what I'm gong with to remove the clashes.
Also, it doesn't appear that the current Java API would support more than one device. I think that all that would be necessary to do that would be to get another N product ID's so that the system could tell the difference, and then make some of the static pieces of the API non-static.
I could be wrong about the API though, because I have no Android device or ADK to run with yet.
-e
DISCLAIMER: I am not a Windows person, but have recently written an Xbox One app, so there is that...
- The aforementioned Bluetooth stack limitation
- How one would enable characteristic notifications on Android
- When GUI changes are allowed to be made i.e. can't be done in a BluetoothGATT callback function
the service class ends up being cluttered with what seems like unnecessary code that would otherwise be in separate classes or removed altogether.Thanks Eric,
I'm doing the Windows port now. The port is a Windows Portable Class Library for Windows Store apps in C#, and therefore should be usable on Windows and Windows Phone 8.1 and greater.
I have a decent level of completeness on all the service and characteristics classes as well as registers. There are a few changes in the signatures because of the differences between Java and C#.
I'm in the process of working through the MetaWearBleService class now. As you said, some of it goes away, and other parts have wholly different code in order to be compatible with Windows.
On Windows:
o One would have to first pair the device
o Assign a PNP watcher to it (that would handle sending the DeviceCallbacks for connected and disconnected)
o Hook into the notify event for any characteristics that support it.
o The notify event will then drive the rest of the callbacks.
There is another somewhat large difference in Windows in that one doesn't receive callbacks for characteristics that are read. One simply reads the value from the characteristic (async), which then either comes from the cache or from the device, depending on how the call is structured.
Still fooling with it, but this limitation may end up causing some cross thread difficulties, as one would
o Read the characteristic
o Receive the result
o Call the callback in line
Doing the callback in line will also expose the API to being stalled by user code which handles the callback.
I already had a brute-force hack working where I just set up a characteristic read and notify hook on the accelerometer.
I'm hoping to converse with the board via the API in some limited ways today.
My Windows Store Portable Class Library is somewhat usable now. Just waiting to make contact with Laura to find out what she wants to do as the next step.
I've successfully read Accel values, the switch, and blinked the LED to date. More to come.
-e
@Laura @Eric
I'm still waiting for you guys to call me so we can go over what's next on the Windows Store API.
My contact info is embedded with my recent email to you
-thanks
-e
@ericleigh007 H there have you seen this library on codeplex:
http://sensortag.codeplex.com/
It's based upon creating GATT services for the TI Sensor Tag reference design and may provide some pointers to avoid cross threaded problems.
If people are using MVVM as a pattern for their app UI then problems should be minimised.
HTH,
Mike
(Wish I could help as I am a Metaware owner but just don't have the spare time right now - too busy using BLE in other ways)
Hi,
I'am also trying to get the metawear run with a Windows (store or phone) app. Any help would be welcomed.
Franck
There are a few pieces of documentation missing that I'm not able to get, but I'm almost there.
We will have in the next week or so, a project with a PCL for Windows and a test app.
@Mike, grabbed the sensor library. I'm not using MVVM in the test app (the API is not really involved in whether the app does that or not).
However, I've been thinking about adding events for the current callbacks because that would invite more use of XAML tricks.
I've decided that once I get things working, I'll THEN add the events.
-thanks
-e
First version of the Windows Portable Class library is complete. Somewhat tested on Windows, no tests have been done on the phone.
VERY rough work! Be gentle.
https://mwear.codeplex.com/
-e