Windows Phone 8 native and Javascript interop

In the last blog post we talked about our experience as a C# developer when migrating a C# app to Javascript + Html. In this follow up post we will deep dive into some areas that wasn’t self-explanatory and addresses some native and Javascript interoperability pitfalls and problems when building a Windows Phone 8 app with Html and Javascript.

Full source code is available at Github.

App structure

The default project template for creating Windows Phone 8 Html 5 apps doesn’t give us very much. We get a MainPage.xaml preconfigured with a WebBrowser control and a folder with index.html and a .css file. Nothing fancy and nothing you couldn’t live without.

What we did was to create an empty Asp.Net Web Application project to our solution and moved the folder with the index.html and the .css file from the initial project to the newly added project. That makes our code more separated and we get one web project which hosts our Html, Javascript, CSS and one native project with C#/XAML.

Another bonus with this setup is that we easily can publish our website to Azure or another server of our choice due to the project type. This is a great setup when developing a hybrid application, now the client becomes just a thin layer on top of the shared web-project. The logic and the shared content of the application are to be found in the shared project and the platform specific features and looks are to be found in the native project.


The Appbar is a little bit special as the app only have one xaml page and if we code the Appbar in XAML we will have the same Appbar on every page we navigate to in our WebBroswer. We solved this by having our Javascript code notifying our C# code that a navigation occurred and reacted to that notification in our code behind to create a page-specific Appbar. The reason why we let the Javascript code notify our C# code that a navigation had occurred was due to the fact that our Appbar needed information about links loaded in Javascript to correctly create the Appbar.

If your C# code doesn’t need any page-specific information from Javascript to create the Appbar it can instead subscribe to the Navigated event from the WebBrowser component. This event is triggered when the user navigates and provides information about which page the user navigated to and thereby create the Appbar we need.

Invoke Javascripts from C#

As we wrote in our previous post and as you probably noticed in the Appbar section, it’s possible to interact between C# and Javascript. From C# you can call any Javascript function without having your Javascript understanding which functions that can be invoked. The only limit is that you can only invoke Javascript with strings so if you need to work with more complex structures, use JSON.

In our Javascript file we have a function that we want to invoke from C#:

function doTheStuff(parameter) {

It does the stuff we want to do and accepts one parameter, nothing special here.

When it comes to our C# code we need access to the WebBrowser control in our MainPage.xaml code behind – it’s easily done with just specifying a function name on the control in XAML. In C# we are able to invoke a script with the following code:

Browser.InvokeScript(“doTheStuff”, “hello world”);

In this example we have named our WebBrowser control “Browser”. The invoke method called takes one function name as string and an array of parameters, so you are not limited to just one parameter. Make sure to set the property IsScriptEnabled to true on the WebBrowser control or this won’t work.

Notify C# from Javascript

To let C# understand notifications from Javascript we need to subscribe to the ScriptNotify event on the WebBrowser component. This callback method will then handle all of the notifications from Javascript.

In our Javascript code we can easily notify our C# code with a simple function call. We are limited to only one string parameter in the function call, but it’s possible to send large JSON objects as long it’s serialized as string.

window.external.notify(“your awesome parameter”);

This parameter is then easily accessed in our C# callback.

AccentColor / Themes

The use of accent color and themes in your application will give the user a better windows phone experience. From Javascript we can’t access any of the styles and themes from the app resources so we have to do some workarounds to make this happen. In the following code we give an explanation on how to set the accent color in your app, the theme color is set in the same manor and therefore redundant in this section.

First we need to identify the elements that we want to be bound to the accent color and give them the right CSS style.

.accentColorStyle {
<div name=”elementToBeBound” class=”accentColorStyle”></div>

Second we need to include a really nice Javascript library created by Shawn Olson that enables us to easily manipulate our CSS class or id.

Third we need a Javascript function which will be invoked from C# that changes the CSS. This function will take one parameter that will be our accent color hex code.

function setAccentColor(accentColor) {
    changecss(‘.accentColorStyle’, ‘color’, accentColor);

This snippet uses Shawn Olson’s changecss function to do the magic. We specify that we want to change the color attribute of the accentColorStyle class in our CSS with the accentColor value we get from C#.

From C# we invoke the Javascript function as specified before, the challenge is to get the accent color and make it compatible with CSS as it is encoded in ARGB, CSS needs RGB.

public void SetAccentColorHex()
    var c = (Color)Application.Current.Resources[“PhoneAccentColor”];
    var hex = “#” + c.R.ToString(“X2”) + c.G.ToString(“X2”) + c.B.ToString(“X2”);
    Browser.InvokeScript(“setAccentColor”, hex);

This code loads the accent color from the phones resources, translates it to a RGB hex and invokes the Javascript function.

//Alexander Persson & Frank Camara

This Post Has 4 Comments

  1. Denys Chamberland

    So in a way your Windows Phone application acts more as a “doughnut layer container application” so to speak. IOW you integer a full screen “stretched” browser component in a MainPage.xaml page in which you run the Web content.

    I ear some barking “hey but that’s not really native code”, but honestly I would say I can live with that. I love the idea of SOC. I mean isn’t that what SOC is all about?

    I also love the approach using AngularJS. Neat.

    So in a way I could even connect the Web section to an extra light Web API 2 oData with OWIN and it could still the job for delivering the data. Right?

    Are you planning to make any Nuget template starter package in the near future? Though that’s not a big problem as we could easily build our own.

    Good job… I’ll keep an eye on it and do some testing on my side.


    1. Alexander Persson

      Correct, the Windows Phone application only acts as a container for running the web content. It’s not really native but using native app bar brings some native feel to the app.
      Using this approach it’s possible to do all kind of stuff with oData and OWIN, we are using a simple Rest API in our app and we had no major problems with that.

Leave a Reply