Two for the Band
- Posted: Jun 05, 2015 at 6:00AM
Honest, this is the last Microsoft Band post... (for a bit at least)(unless I find something really really cool anyway... ;)
Just for reference, here are the other recent C4F posts; Microsoft Band SDK Release and Band Studio Introduction, Developing for the Microsoft Band Link Round-up, Microsoft Band SDK Preview, Raspberry PI 2 and the Microsoft Band
Today two Microsoft MVP's, Laurent Bugnion and Joost van Schaik, share two new adventures developing for the Microsoft Band. My favorite is Joost's where he seems to throw just about everything into the project...
Frist through, Laurent Bugnion shares a presentation and code;
Date: 13 Mai 2015
Location: Mechelen Belgium
Event name: Techorama 2015
Microsoft took the technical world by surprise by releasing in November 2014 a smartwatch and a Health application compatible with Windows Phone, Android and iOS, and loaded with features. Just a few weeks later, an SDK was also released for these three platforms. The SDK gives access to the watch's many sensors (heart rate, accelerometer and many more) and also allows sending notifications to the watch. This is of course just a first step in opening up this new platform for 3rd party, and using the watch as a new kind of input/output device for applications. In this session, we will have a lot of fun coding for Microsoft Band. We will first discover the band and understand how it works. We will see how to install the SDK, how to create a new application leveraging the sensors and how to enrich your apps by sending notifications to your users' wrist. Then we will use the Band's sensors to create fun applications.
Now Joost van Schaik takes just about everything, Windows 10, UWP, Azure and the Band, mixes it together and...
Back in February I got my Raspberry PI2 and wanted to do something with it. So I created a setup that made it display my heart rate as measured by my Microsoft Band, making it blink a colored LED in the same rate as my heartbeat. Windows 10 IoT Core wasn’t available at that time, which made me resort to using Raspbian Linux, installing Mono on that, getting a OWIN ASP.NET server running on that, that listened to postings on a WebAPI endpoint, employing a modified C library to actually drive the pins to make the LED go, editing files, setting permissions, all via command line stuff.
Back to the drawing board
What I envisioned when I started out in February, was something like this:
A kind of magic black box in the middle that would take care of this problem by receiving data and distributing it to clients. It’s the kind of diagram typically drawn by a branch of people who tends to net big salaries by painting happy stories in the client’s mind - and, with the warm fuzzy feeling of a job well done, drop the actual problem of getting these magic boxes to appear out of thin air on the desk of some hapless unsuspecting developer. These people tend to call themselves architects, but I think marchitects would be a better word. Believe me, I’ve done architecture myself, I know how this goes. But I digress.
Anyway, in this case Microsoft has you (and me) poor developer’s – er – behind already covered, because this magic box already exists. It’s called Signal/R, and it’s been around for a while. A basic setup hardly needs any code, and if you host it on on Azure, you can very simply publish it with a few mouseclicks, debug it while running, and you never need to worry about where your magic box is on the network – it has a global URL. And what you end up then with, is this possibility:
The basic setup
I have created a pretty simple solution that contains 4 projects:
- A Windows Phone 8.1 app to receive Microsoft Band heart rate data and send it to the Signal/R hub
- A Windows 10 UWP app to display the hearth rate as it receives notifications from the Signal/R hub
- A Portable Class Library that contains some classes that are shared by the various projects.
- A very simple ASP.NET web app hosting a Signal/R app that can accept heart rate pulse information and notify all clients
I opted for making a Windows Phone 8.1 Universal App to actually drive the code that receives the actual Band data for two reasons: first, my main phone is still Windows Phone 8.1 and I still use my Band every day and second, it is a nice way to demonstrate how similar Windows 10 UWP and the ‘old’ UAP code now is (and share code between it).
There are two caveats:
- To open the whole solution and deploy the Windows 10 apps you will need VS2015RC (of course), but I can only get the 8.1 app deployed correctly on my phone by opening the same solution with VS2013 and deploying it from there.
- There is an issue with Signal/R and Windows 10 UAP – you will need to do some fiddling with referenced assemblies to get it working – that is why there is an Signal/R client assembly in a Binaries solution folder. For details see this post I did earlier.
With some very basic stuff published on Azure and utilizing the power of the Universal Windows Platform apps I was able to write a distributed system for displaying my heart rate – using not only one code base but a single app that can be deployed on a range of devices; devices that could basically be everywhere on the world, as long as they have internet access. This really shows the power of current and near future Microsoft technology, making things that used to be extremely hard just very very simple. If I understand this right, this would even be able to run on XBox One and HoloLens, although I am not quite sure a gamer would like to see a big circle flashing on his console, nor would a HoloLens user like to see that more or less blocking his field of vision. But the point is that using these technologies it becomes very easy to connect a lot of devices very easily using one type of app.
There are some issues still to be addressed in this solution. Basically everyone can post to the hub now and everyone can connect to it, so this opens great possibilities of completely destroying an on-stage demo. You clearly need to be sure that not everyone can post heart rate data to your hub or, if you want to make this available as a cloud service, at least make sure no-one get’s other people’s data pushed to it. There are several ways to achieve that, but that’s beyond the scope of this post.
I actually have to credit my wife for thinking of an actual practical application of this crazy demo, for when I showed this to her in my typically overenthusiastic geek way, her reaction was not the typical geeks’ wife “well that’s nice dear” but “so if I understand you right, I can make a doctor listen to my heart rate even if I am on a holiday somewhere far away?” :).
The demo solution, as always when applicable, can be found here