UWP App Development: Styling the Mobile Status Bar

Very handy if you’re building an app for Windows 10 mobile

irregular expressions

(If you’re new to Windows 10 and the Universal Windows Platform, go here.)

With Windows 10 and Universal Windows Apps, a lot has changed for developers, particularly if you’re coming from the phone side of things. Some changes are awesome! Others will take some getting used to. Dealing with the Status Bar probably falls under the latter category.

If you’re not familiar: The Status Bar is the UI at the top of your screen on Windows Phone:

Mobile Status Bar

In Windows Phone 8.1 app development, dealing with the Status Bar was pretty simple. You could show it, or hide it, or change it’s appearance slightly. The first-party Bing apps (News, Money, etc…) took advantage of these capabilities in some interesting ways. (You can read about how they did it here.)

Customized Mobile Status Bar

The Status Bar is alive and well in Windows 10 Mobile, but the way it interacts with an app is…

View original post 413 more words

Building a device driver using MRAA and JavaScript: Introduction

If you’re using NodeJS to build a program for an IoT device like the Intel Edison, then chances are you have, or will, run into a case where there is not a driver for the peripheral device that you’re trying to use. My team and I ran into this very scenario a couple of weeks ago on a project where we were trying to use the SparkFun OLED Edison Block as the main display for a prototyped wearable technology. There is a C++ driver for it, but it looked like it would be a challenge to get it running with the JavaScript interface we were already writing, so as a learning experience, I decided to rewrite the driver in JavaScript, leveraging the MRAA library for JavaScript.

Note: Intel published a driver for this block via UPM a week after we decided to build our own.

In this post, I will go through the MRAA interface for JavaScript and share the best practices I’ve learned from my experience. Through this blog post series, I will take you through each of the device interfaces and give you samples of how to use them. At the end, I will show you how to package your driver into a NPM package for other developers to consume.

I will primarily be referencing the Intel Edison board during this post, but MRAA supports other platforms like Raspberry Pi and Beaglebone Black. A full list of boards is here.

What is MRAA?

MRAA is a low-level device interface library for Linux-based microcontroller platforms. It is based in C/C++ and also has language projections for Python and JavaScript. The library abstracts device-level interfaces like analog pins, GPIO pins and other communication bus technologies like PWM, I2C and SPI.

Before you get started, it’s a good idea to make sure you have the latest MRAA build on your device. To do that, follow these instructions.


The easiest way that I have found to work with Intel-based devices is through using their IDE – Intel XDK IoT Edition. It has interfaces for connecting to and deploying code to your boards. It also has a built-in debugger, which comes in handy and the code editor is based on Brackets, an open source code editor.

Introduction to the MRAA JavaScript interface

The JavaScript interface is architected to work with a NodeJS-based application. The full API reference can be found here – http://iotdk.intel.com/docs/master/mraa/node/modules/mraa.html. One thing that I have noticed using the JS library is that not all of the projected methods are documented under the node docs, so you may need to reference the actual library source in some cases.


The analog pins interface is pretty straightforward. The readings are returned as 10-bit ADC values, which means that it has the ability to detect 1,024(210) discrete analog levels (source). This is common to the Arduino pinout and boards that support it.

Here’s a sample of reading a value off analog pin zero taken from the Intel XDK template for reading analog.

var mraa = require('mraa'); //require mraa
console.log('MRAA Version: ' + mraa.getVersion()); //write the mraa version to the console

var analogPin0 = new mraa.Aio(0); //setup access analog input Analog pin #0 (A0)
var analogValue = analogPin0.read(); //read the value of the analog pin
console.log(analogValue); //write the value of the analog pin to the console

You can see that a new reference is created using mraa.Aio(0), specifying that it should read from analog pin zero, or A0. It’s as simple as that to read the value, but you will likely need to convert the value into something useful like a temperature reading, or motion reading. I won’t get into any of the specifics here. There are plenty of samples out on the web and each specific sensor may require its own conversion formula.

The Aio class also contains useful methods that grant you finer grain of control over how it’s read. For instance, you can change the bit resolution to 12 bits(max capable in MRAA) on the pin by calling setBit(12).


General purpose input/output is also a very common basic interface in the world of microcontrollers. With GPIO, you can do simple things like power and LED or Piezo buzzer to reading input from a button.

Let’s take a look at how GPIO can be used to power the onboard LED of the Intel Edison. This is sourced from the Intel XDK template as well.

var mraa = require('mraa'); //require mraa
console.log('MRAA Version: ' + mraa.getVersion()); //write the mraa version to the Intel XDK console

//var myOnboardLed = new mraa.Gpio(3, false, true); //LED hooked up to digital pin (or built in pin on Galileo Gen1)
var myOnboardLed = new mraa.Gpio(13); //LED hooked up to digital pin 13 (or built in pin on Intel Galileo Gen2 as well as Intel Edison)
myOnboardLed.dir(mraa.DIR_OUT); //set the gpio direction to output
var ledState = true; //Boolean to hold the state of Led

periodicActivity(); //call the periodicActivity function

function periodicActivity()
 myOnboardLed.write(ledState?1:0); //if ledState is true then write a '1' (high) otherwise write a '0' (low)
 ledState = !ledState; //invert the ledState
 setTimeout(periodicActivity,1000); //call the indicated function after 1 second (1000 milliseconds)

In the above code sample, you can see that we created a new GPIO object that interfaces with GPIO13 on the board. In this case, that happens to be the onboard LED for the Intel Edison.

After creating the object, we need to tell what direction we expect to use the pin for. In this sample, we will set the direction to OUT, so that we can write to it. This effectively allows a HIGH or LOW voltage to be set on the pin – which can be used to turn something on/off like the LED. If you are expecting to read a value off the pin, then you would set the direction mode to IN.


If you’re new to the world of using JavaScript to write IoT software, then I suggest firing up some of the sample templates included in the Intel XDK IoT Edition. It does a fairly decent job of covering most of the scenarios supported by the MRAA library.

In the next post, I will cover using MRAA and JavaScript to build an I2C interface for a sensor. Stay tuned!

Hack to the Future – Hackster.io Hardware Weekend Dallas

This past weekend, April 18th & 19th, I led a team of Dallas-based Microsoft employees at the Hackster.io Hardware Weekend hackathon. If you’re not familiar with the event series, you can find out more about it here. The basic gist of the event was to hack on any kind of hardware, but the special prize was getting to hack on a DeLorean DMC-12.

When we started planning for the event, we decided we definitely wanted to take advantage of having access to the car, but we also wanted to showcase some Microsoft technologies. We decided that whatever we did should include an interface to the car, cloud components and a mobile app component. Here’s what we ultimately came up with.

Project CliMATE

The goal of the project was to enable intelligently-controlled climate for your automobile. In Texas, we get some extreme heat during the summer months (> 100 degrees Fahrenheit), so this is a real-world problem that we were trying to solve. Essentially, you would be able to monitor the internal temperature of your auto from the mobile app and then decide if you want to remote start the auto and/or adjust the auto’s climate system, prior to departing a location like home or work.

Obviously, there are a lot of technical and safety challenges to a system like this, so we ended reducing the scope to realistically fit the project into the given time of the hackathon. What we ended up with was internal temperature monitoring and remote-starting the auto from a mobile app.

Here’s a video of the final project operating (even if the car battery died)


You can view the project on Hackster here.


Our team ended up winning the Hackster award for the best hack on the car and the best overall hack.

The team

Jason Fox – SDE, Strategic Engagements, Microsoft

Enamul Khaleque – Senior Escalation Engineer, Microsoft

Prashant Pratap – Senior Escalation Engineer, Microsoft

Farida Bharmal – Senior Escalation Engineer, Microsoft

Peyton Casper – Microsoft Student Partner, UT Arlington


My Next Chapter

I’ve been at Microsoft for just over 3 years and I’ve decided it’s time to move on.

Move on to Redmond, that is!

On March 16th, I will begin my new chapter at Microsoft as a Software Development Engineer in the Worldwide DX group – where I will be helping partners build epic projects.

The decision to accept this position did not come easy, as I have come to care greatly for the developer community in Dallas and surrounding areas. I have made many great friends as an evangelist this past 14 months and I will never forget the great times I had interacting with the community. Let’s face it, being a developer evangelist at Microsoft is an incredible job and one that I do not concede lightly, but I know that whoever they find to replace me will do a fine job.

Sometime in the next few months, my family and I will relocate to Washington, but I have a feeling that we’ll return one day. DFW is and always will be my home – it’s where I grew up, my family is still here and there are opportunities that I hope will someday come to bear here, when the time is right.

Never fear, I will still be actively blogging and interacting with the community on social media. I also hope to be able to bring some of the work I will be doing Redmond back to DFW down the road where it makes sense.

I bid you all in Dallas/Fort Worth a farewell, but not goodbye.

Jason Fox

How to access the UnityPlayer.log file on Windows Phone

Sometimes when debugging a game built with Unity, you need to access the UnityPlayer.log file to see what’s happening on an actual device. Here’s how you get the log file off of Windows Phone for inspection.

Requirements: You need a PC with the Windows Phone 8/8.1 SDK installed and a test device that has your game installed from either Visual Studio or the Application Deployment tool.

Note: this method does not work on games installed from the Windows Phone store.

Finding your game’s GUID

First, you will need to find the GUID for your app. For Windows Phone 8.1, this value is located in the Package.appxmanifest in Visual Studio. You will have to open the file using the text or XML editor. From there, you will need to find the PhoneProductID element of the PhoneIdentity tag.

For Windows Phone 8.0, this value is the Product ID, located in the WMAppManifest.xml file.

Taking a snapshot of IsolatedStorage

Next, we’ll use the IsolatedStorageExplorerTool to capture a snapshot of the game’s Temp directory on the phone and copy it to a directory on your PC.

Open a Windows command prompt and enter the following command –

Windows Phone 8.1 –

[snippet id=”20038″]

Windows Phone 8.0 –

[snippet id=”20039″]

If the operation completed successfully, the tool will print “Done.” In the output window.

Now you can navigate to your output folder and the UnityPlayer.log file should be located in the newly created IsolatedStore directory.


IsolatedStorageExplorerTool – https://msdn.microsoft.com/en-us/library/windows/apps/dn629254.aspx

Getting started with VR for Windows Phone

I started playing around with VR projects for Windows Phone back in December. I was thinking that if others could do it on Android and iOS, then our platform deserves some support, too. My initial project used the Google Cardboard for Unity SDK with a few tweaks for Windows Phone support. It was really hacky and I didn’t feel too great about releasing it to the public, even though I did drop it out on GitHub.

I spread that initial hacky version around inside my organization at Microsoft and it garnered some attention and resulted in me connecting with Peter Daukintis, a colleague of mine over in the United Kingdom. Peter had published two blogs posts – one about head tracking on Windows Phone and a follow up post using ALPS-VR for Unity.

Learning about ALPS-VR really opened up my eyes to what was possible with an open, cross-platform VR framework for mobile platforms, so I decided to scrap most of what I had done in my hacky Cardboard-based solution and move forward with ALPS-VR.

So, let’s move into actually building a VR experience for Windows Phone. This assumes that you have some working knowledge of Unity3D and Visual Studio for building Windows Phone apps.

You’ll need a few things:

  • A VR headset that can hold your phone – I’ve been using a Google Cardboard headset, since they are cheap and easy to come by. I have found them on e-bay and Amazon for less than $15 USD.
  • Download the Unity package(“alpsvr-wp.unitypackage” ) or clone my GitHub repo
  • Unity 4.6 (Pro for barrel distortion) – http://unity3d.com/unity/download **Not verified to work with Unity 5**
  • Visual Studio 2013 Community Edition – link
  • A Windows Phone running Windows Phone 8.1 – I recommend a phone in the 4.5-5 inch range like the Lumia 1020, 930 or Icon. The 1520 and other larger phones don’t fit the Cardboard googles.

Create your Unity project

  1. Open Unity and create a new 3D project
  2. Import “alps-vr windows phone.unitypackage” into your project
  3. Open the “demo” scene file located in Assets/Scenes – this will show you the structure of how a scene needs to be setup – you really just need to drag the ALPSCamera from ALPS/Prefabs into your scene

Select the ALPSCamera object in the scene and scroll down to the ALPSController script component. Notice that there is a Device setting for which VR headset you are using. I have mine set to “CARDBOARD” and the framework will optimize it’s settings for the Cardboard headset.

Build out for Windows Phone

  1. Open the Build Settings window located in the File->Build Settings menu
  2. Under Platforms, select Windows Store and set SDK to Phone 8.1

  3. Press “Build” and select an output folder for the Visual Studio project. I usually use something like a Builds folder that sits alongside my Unity project’s Assets folder.

Running the project on a device

This wouldn’t be much fun if you run it on an actual phone in a headset, so place that phone in there with the USB cable connected.

  1. Open that newly output Visual Studio project.
  2. Connect your phone to the PC using a USB cable. Make sure the phone is registered as a developer device.
  3. Now, you can run your project on the phone by targeting “Device” and pressing F5. Notice I have my build configuration set to “Master”. This setting yields the best performance, as it removes all of the profiling hooks from the Unity player.

What’s next?

Now that you’ve gone through setting up the sample project, you can venture forth to build your own custom scenes for your project. I would love to see what you build, so hit me up on Twitter to share and I will try to get you some exposure for your project – especially if you publish your app to the store.

You can post questions or comments here on the article and I will do my best to answer them in a timely manner. Of course, you are also welcome to contribute back to the GitHub repo. I will take a look at any pull requests submitted.

I should also mention that ALPS VR has support for Android phones as well, but I haven’t tried it yet. The Android phone that I have is far too old to run it.

***EDIT (5-13-2016) to remove the hijacked alplsvr URL – sorry if anyone clicked on it and was offended!

Here’s what I’m doing at PAX South this weekend

My team here at Microsoft wanted to do something really cool this year at the inaugural PAX South convention, so we decided to help out some Texas-based game developers that we know, by hosting them in our booth.

From that idea, the Texas Indie Game Lounge was born!.

The Texas Indie Game Lounge is a space dedicated to showcasing games from some of the game developers we know and that we’ve partnered with, in Texas, over the past year to bring great games to both Windows and Windows Phone platforms.

Some highlights to look forward to this weekend at our booth –

We’re all excited to see everyone at PAX South this weekend! See you there!