Category Archives: Windows Phone 8

Posts about Windows Phone

Microsoft Band API

So I just started looking at the SDK for the Microsoft Band. It’s pretty good, but bear in mind that there are limitations, for example, you can only gather “live” sensor data – there’s no way to get any cached stats that may (or may not) be on your device.

Having said that, here’s a quick overview of using the SDK.

Microsoft Band
The Band

Preparing the solution

First thing to do here is to make sure your band is paired with your phone, turned on and active. Once that’s done, open Visual Studio and create a new phone project.

The SDK is available via NuGet, so add a reference to it.

You should see that references have been added to the required assemnblies, but also your package.appxmanifest file will have been updated with the following device capabilities.

These allow the app to communicate with your Band.

Now you can get going.

Connecting to your Band

In your page, get a list of the paired band devices on the system with the following command. Note that I return from the method if there are no paired Bands. You’ll need to set a using reference to Microsoft.Band.

Once you have your list of Bands, you can connect to one. In this case, I’m assuming we always want to connect to the first connected device, but you can modify this bit to suit your needs.

Note: The tutorials suggest you wrap the returned client instance in a using block, but if you do that then later steps like collecting sensor data won’t work because the client is disposed when this method returns. I hold a local reference to the client object and dispose it in OnNavigatedFrom();

At this point we can start getting basic data back, like the hardware and software versions.

Gathering sensor data

Now we get to the fun stuff. Assuming you followed my advice above about holding a local reference to the client object, you can start getting sensor data back. In this case, the HeartRate data.

Add a using statement for Microsoft,.Band.Sensors, then you can subscribe to events.

Since all this work takes place on its own thread, you’ll need to do a little bit of juggling to get this data onto the screen. Specifically use the CoreDispatcher to invoke the action on the UI thread. You might like to set up a method to keep this simple…

and then call it like so…

for example.

Next time – more on sending notifications and personalising your Band.

Nokia Imaging SDK updated

Not surprising news, but worthy of a big mention. The Nokia Imaging SDK has had a new beta release (1.2).

This release brings all the goodness of the Phone library to the new, conjoined Microsoft platform across Windows 8.1 and Windows Phone 8.1. I am hoping to find a little time to play with the new SDK over the next week or so, but the sample apps and code look great. There are also sample apps in the Windows store, although the links in the site seem not to work. I’d suggest opening the Windows Store and searching for “Filter Effects” and installing the one published by Nokia.

It’s //build time!

For those of you who haven’t managed to convince your management to let you go to //build (and this includes me), you can see what you’re missing on the official //build 2014 site. The recordings of the sessions will also be made available there.


Having had a look at the session listings, there is big (although maybe not unexpected) news for Windows Phone and Windows Store apps. As ever, you can find the details 24-48 hours after the live events in the videos and slide decks (or just keep an eye on your favourite Twitter client / blog).

Discrete Slider in Windows Phone

This morning I found an interesting question on StackOverflow asking how to make the default Windows Phone slider control return discrete values (in this case an integer value rather than the default double).

There are several possible ways to go about this, but the one that leapt out was to create an attached property on the slider and bind to that.

The entire helper class for the property looks like this.

The points to note here are:

  1. On line 7 we hook into the slider’s ValueChanged event so that we can round the value.
  2. Ob line 12 I just return the slider’s Value property, cast as an integer. This value has already been rounded and set on line 7.
  3. If we don’t attach the property, the slider will continue to behave as normal

To use this code in an app, here’s a sample of three sliders, each with a TextBlock to display the Value.

I know this isn’t an elegant solution to the problem, and that it has a couple of issues, but it does work and should give the results the original questioner was after.

Nokia Imaging SDK and the Emulator

If you’re testing an app that uses the Nokia Imaging SDK (or any other app that access your pictures library, for that matter) and you can’t see any content in your pictures library it might be the result of a bug in the emulator.

If you need to access the in-built images, you need to open the photos app at least once before you run your app. once you’ve done that, the content will become available to your app.

(Thanks to the guys at Nokia, this information has now been added into the documentation. I’m childishly pleased to have been able to help out in my own small way. ;) )

Nokia Imaging SDK

I’ve just been having a look at the Nokia Imaging SDK (also available via NuGet). It looks like it really bridges the gap that a lot of developers have when they want to include image technologies in their apps. (for example, you can specify an image size that you want to use in the PhotoChooserTask, but you can’t let the user decise what aspect ratio to use. It’s even less flexible in the CameraCaptureTask where the user can’t do any manipulation at all.

Adding this SDK would allow you to give a lot more control to your users as it supports cropping, resizing, rotation, scaling, filters and other image enhancements.

There’s a tutorial application project in the full downloadable version of the SDK (not available via NuGet) that will quickly get you started. Give it a try! (I would highly recommend you read the Quick Start guide as well, though. ;))

Unit Testing MVVM Light Messages

MVVM Light has a messenger implementation which can communicate with the UI layers in order to handle things like page navigation, and using this is is very easy to set up a PCL ViewModel assembly to drive both a Windows 8 and Windows Phone app. As a quick example of how you’d set this up, imagione this implementation in a view model.

where NavigationRequestMessage and NavigationTarget are implemented as follows.

Now you can handle the incoming message in your front-end app. In this example, it’s in a Windows 8 Store app.

Note that we unregister the handler again on navigating away from the page, otherwise the message will be handled twice next time we visit the page, three times the next time, etc.)

Now we can write a unit test for this method to ensure that whatever our actual implementation logic tell us should be the resulting navigation is actually correct…

This is a trivial example, but hopefully it explains how to test the navigation in your apps when driven by MVVM Light’s Messenger functionality.

Another Unit Testing trick

So, you’re about to start an MVVM Windows Phone app, and you really want to be able to run unit tests against your view models using Visual Studio’s built-in test engine.

By default, you can’t do that for a phone app – you need to create a Phone Unit Test App that will wrap everything and spit out the test results when you run the app.

If you really want to be able to run tests within the IDE you can build your view models in a separate Portable Class Library (yes, those again). As long as you add .NET as a target framework for the VM library, you will be able to write your tests in the same way as you would for any other project type.

Of course, this approach is not appropriate for all functionality – for phone-specific functionality you will need to use the default (separate app) approach, or a mix of the two.

Take a SIP

I posted briefly yesterday about an experience with the WordPress app for Windows Phone.  I’ve not used it much more than an initial look around, but for the most part it seems to be a great app – apart from the experience when you are writing a post.

Once you get into the text editor for the post body, you initially see a screen like this.

The WordPress app post editor screen
The WordPress app post editor screen

OK, so the buttons look kind of randomly placed, but no biggy.  The issue I had was when I entered the textbox and started adding text.

The WordPress app post editor screen with SIP
The WordPress app post editor screen with SIP

Now we have the ability to enter text, just as you’d expect.  There are, however, 2 issues here.

  1. There is no obvious way to save your work and return to the previous screen, and
  2. there is no way to access the additional feature buttons that were on the screen

It turns out that the way to get back from the editor once you finish entering text is to simply press the back button. I’m not sure about that design choice, to be honest. It feels counter-intuitive somehow, as if you are going to abandon your changes. In fact, it felt so counter-intuitive that I avoided doing it until all hope was lost and I was resigned to losing my text. Not a great user experience.

The second issue is harder to work around. If you want to apply formatting to the post after you’ve entered your text, you have to jump through all kinds of hoops to achieve it (re-enter the text editor with the SIP, select the word, press the back button, press the required formatter).

There has to be a better way. Unfortunately, the platform doesn’t allow much flexibility in this regard. There’s no simple way to implement your own HTML editor on the platform without some sort of compromise – I’ve said it before and I’ll say it again, designing an app is hard and there’s really no substitute for experience and a good designer.

One option that we have is to use a third party control, prehaps the COmponentOne RichTextBox control.

ComponentOne RichText editor
ComponentOne RichText editor

Note the use of the app bar to add edit functions, even while the SIP is present. It doesn’t immediately get around the first issue I mentioned, but is certainly a step in the right direction.

I am going to write a further post about handling the SIP in apps, and how to modify the layout to ensure that important UI elements don’t become inaccessible when the SIP is displayed.

Note : I am not trying to criticise the authors of the WordPress app – I like the app and I’m glad the authors are focussing on their core strengths of developing a great blogging platform rather than supporting applications.


Being a developer in both Windows 8 and Windows Phone is an interesting life. Given the relative newness of both of these platforms, and the similarities in look and feel between them, you’d probably expect that the code can be shared easily between the platforms for the same app. Sadly, that’s not the case for more than about 60% of the code base. (I’m not even going to start on the presentation layer – XAML will always need to be *at least* tweaked to account for the different screen sizes)

The differences between the desktop and phone APIs can cause sleepless nights, as well as necessitating two separate versions of a code base with all the complexities that entails (fixing the same defect multiple times, for example).

Luckily there is a solution that can help us out greatly – Portable Class Libraries. These useful little additions to the platform allow you to write one assembly that can be consumed by Windows 8, Windows Phone, Silverlight or the full .NET framework. But there is a catch – supporting all these platforms comes at a cost of compatibility. The code you write in a WinForms app is likely to use different methods, located in different parts of the BCL to the same feature on the phone.

Fortunately, Microsoft have put a lot of time into portable class libraries, and done some lever under-the-hood work to redirect calls the the PCL versions of some tasks to their platform-specific counterparts. A great example of this is the PCL HttpClient (announcementNuGet package). This makes the task of getting content from the web a snap, and you don’t need to worry about which of the implementations of a web client to use in your assembly. Just use :

Note : If you are targetting .Net 4.0 or Windows Phone 7.x, make sure you also install the Microsoft.Bcl.Async package from NuGet, otherwise the solution won’t build.

So now, all you need to do is call the method as follows, and it will work across all your platforms.

Hopefully that one example will give you some insight into the power of the portable class library, and it’s ability to simplify your coding across the platforms. I will be posting a list of useful NuGet packages that extend the base PCL functionality soon, although there’s plenty of good stuff already in there to get you going.