I am working on an app for the Windows Store that requires mapping functionality. As it is a Windows app, it seems logical to use Bing Maps as they also provide an SDK for apps. Currently it is at version 8, but I had a few problems implementing that version so went for version 7 with the hope to upgrade it at some point when I get more traction for the app.

Firstly you need to go to the Bing Maps Developer portal and sign in to request an API key for your project.

Click on the Create Key link and enter some details about the app. For store apps, a key type of Basic should suffice as we are not doing any enterprise level development. Choose Universal Windows app for the type and any URL you have for your in dev app (I use a placeholder page on my website where the app privacy policy etc. are going to go).

Some transactions with the Bing Maps API are billable, but you have to exceed a limit of 50,000 transactions in any 24 hour period, a listing of billable transactions can be found here. The reason I am mentioning this is in case you are offering a free app and a large number of users start to hit the service you could be liable to paying out.


While there have a look at the feature set for V7 with the online examples. As these are all HTML and JavaScript based samples, they are also ideal for a WinJS UWP app.

To get the SDK for V7, you need to go to the Visual Studio Marketplace and download the Bing Maps SDK for Windows 8.1 Store apps.

This will give you a VSIX to install into Visual Studio.

Open up Visual Studio and choose New Project >> JavaScript >> Windows >> Universal >> WinJS App


This will give you a basic template with enough functionality to test out the mapping API.

Choose the Target versions to support (Build 10586 should suffice)


Add a reference to the Bing Maps for JavaScript extension.


It will highlight a compatibility warning linking to https://go.microsoft.com/fwlink/?LinkID=309181 as it is really should be used with Windows 8.1 apps.

So now when we expand the References in our app we can see the required files for the mapping functionality we are going to build with.

I like to structure my apps, so that the main entry view (index.html and main.js) do a check on load and change the view depending on screen size/device etc. So I create a home view which has the ready, unload and updateLayout functionality. This home view is then loaded from the main entry view and inserted into a content host element.


We now need to add the script references and an element for the map in the home.html file:-

The CSP is important because it defines which urls are safe to load from. The div with the id webview is where our map will go.

Then in the home.js file add this

There you go, our simple map in the app.


There is so much more functionality that can ne added to this app such as getting the geolocation of the user and adding pushpins to different locations, but I will leave that for another post.

Happy coding.

If you want to monetize your UWP apps, it might be part of you plan to have some kind of trial so that uses can try out the basic functionality of your hard work. This can be achieved in two places, firstly you need to test and set the properties in the app. Then you need to change the properties of your app submission in the Windows Dev Center. So here I will cover how we write the code to test for a trial installation of your app.

In my MoonPhase app, I have limited some functionality in the trial version. Basically a user can view the current details on the Moon, but if they want to move forward or backwards in time to see what the Moon looks like on different days, then a message popups up to tell them they cannot do that in the trial. This way they get to use the basic functionality and if they find the app useful, then they can pay for the full version in the app store.

Trial Functionality in UWP

So here is the logic I have in the JavaScript for the view

The ‘message’ element is a div in the HTML that the fly out will append to when the ‘previous’ button is clicked.

In the JavaScript listing above there is a call to getLicenseInfo(), this function takes in a Boolean that if set to true then it is in trial mode and needs to use the CurrentAppSimulator as opposed to the CurrentApp. The CurrentAppSimulator does just that, it simulates certain properties of the application that you have control over.

So to test locally simply pass in true.

var licenseInformation = getLicenseInfo(true);

The CurrentAppSimulator will then look for the WindowsStoreProxy.xml file that resides on your drive, usually somewhere like this:-

%UserProfile%\AppData\Local\Packages\<app package folder>\LocalState\Microsoft\Windows Store\ApiData\WindowsStoreProxy.xml

Depending on what you are testing for, you can populate the sections you need. I am testing for a trail version, so set the IsTrial within the App element to true. You can now run the app in the debugger and you can step through your code to see what paths it is taking. In my case I show the message fly out notifying the user of the trial status.

One thing to remember though is to take out the Boolean or set to false before submitting to the store. I am still looking for a better way to handle this and was hoping there would be some sort of pre-processor functionality like what is used in C# that could be switched when in debug mode.

Submitting Through the Windows Dev Center

So once you are happy to publish the app and the Boolean has been taken out or set correctly, go to the ‘Pricing and availability’ section of your submission.


The use the drop down to set the trial period.


When a user first installs the app in trial mode the real IsTrial property will be set to true and each time the app launches it will check the install date and if this is still set to true then the app won’t launch and the user will be presented with a Windows dialog to prompt them to purchase from the store. When they do purchase, then the IsTrial is set to false and they get all the functionality.

Happy coding

Require.js is a JavaScript module loader, helping to reduce complexity of applications by managing dependencies and allowing easier separation and organisation of code into modules.

Asynchronous Module Definition or AMD modules are a way for applications to manage dependencies and easier separation by organising code into modules. Require.js is one such AMD module loader that can be used with jQuery, node and others, but firstly the JavaScript needs to be refactored appropriately.

Run JSLint over the code

JSLint is a tool that can be run either from the command line, through Gulp or Grunt or even in the browser at https://www.jslint.com/, it will highlight issues with the JavaScript to be fixed that will produce better quality code.

Structure the JavaScript

After the issues highlighted by JSLint have been fixed, organise the code so that it follows a more structured outline such as having a collection of vars and functions.


Add the AMD define call

For it to be recognised by module loaders such as require.js, the code needs to be wrapped in define calls which will turn it into an AMD module.


Dependencies such as jQuery

To add any dependencies such as jQuery, simply include them in the define call array such as this:-


Any dependencies added in this way also need to be AMD compatible modules or a shim might be needed, documentation for jQuery can be found here:- https://requirejs.org/docs/jquery.html

Add a little Encapsulation

One of the advantages of the module pattern is that it can be structured so that variables and functions can be internalised and effectively defined in a 'private' scope. The module's return object can define exactly what should be publicly accessible. In the previous code snippet, the variable foo and both functions were all returned by the module. This means that they would all be publicly accessible by any client code. Instead, we want to ensure that foo and the functions are initially defined as private, and then expose the functions explicitly in the return object.


Happy coding

Well its been quite a while since my last post and it might look like I wasn’t going to be blogging again. I am planning on writing more and posting the content here. The reasons I haven’t blogged in a while are numerous, but basically I have been involved with a project over the past 12 months that has taken up my time and at the tail end of last year I got a bit burned out with everything tech.

So excuses over, what am I going to be writing about in the coming weeks and months?

  • Windows 10
  • Node
  • Docker
  • Angular
  • .Net
  • TeamCity and CI/CD

Also I will be writing a bit about my experiences creating and running a mini SASS application which has just gone live called ObsPlanner.

So thats it for now. The first words are always the hardest.