Displaying Microsoft Band heart rate via Raspberry PI2 using Mono, C#, OWIN and a Windows Phone

Intro – what? WHY?

As regular readers of my blog might have seen, I got myself a Raspberri PI 2 and a Sunfounders sensor kit, and was happily dabbling a little with it. And then suddenly, out of the blue, Microsoft dropped a development kit for the Microsoft Band – and Gerard Verbrugge (Microsoft DX Netherlands) challenged me to make something with it. So I thought to combine a number of gadgets: my Microsoft Band, my Windows Phone and  the Raspberry PI plus some of the stuff from the sensor kit.

I created an application that shows your heart rate with a blinking led connected to the Raspberry PI, with a connected buzzer making sound as well. The LED blinks at the heart rate as reported by the Band, and using the  buzzer, the PI also emits and audible tick-sound as the LED blinks. At low heart rate the LED blinks blue, at medium rate green, and at high rate red:

Raspberry PI2 controlled by Microsoft band at heart rate < 80

Raspberry PI2 controlled by Microsoft band at heart rate > 80

If you crank up the sound, you can hear the ticking of the buzzer at the heartbeat. I think this is one of the coolest stuff I ever made. So, Gerard, challenge accepted. And, IMHO, achievement unlocked ;)

Hardware used

• 1 Microsoft Band
• 1 Windows Phone running Windows Phone 8.1
• 1 Raspberry PI 2
• 1 4-pins RGB LED from the SunFounders kit
• 1 3-pins Active buzzer from the Sunfounders kit
• Breadboard, GPIO cable (connecting PI to breadboard), miscellaneous connecting wires

Don’t give up reading if you don’t have a Band – that part can be simulated and the technique to control hardware peripherals from a WebAPI endpoint is useful on it’s own.

Global setup

How this thing works is, in essence, pretty simple:

• On the Raspberry PI2 runs a OWIN server hosting
  • a little WebAPI endpoint that accepts heart rate data
  • an endless running task making the LED blink in the right color and cadence, again using Daniel Riches’ wrapper around Gordon Henderson’s wiringPI C library. Once again, with some adaptions.
• A Windows Phone 8.1 application listening to the paired Microsoft Band’s heartrRate sensor’s events, and posting those to the RaspBerry PI2’s OWIN server upon receiving those.

The demo solution contains 5 projects:

• A Universal app (with only the Windows Phone project actually used)
• An project holding the OWIN server
• A PCL holding two simple classes: an object to post data with to the OWIN server, and a Settings object with some hard coded settings shared over several projects
• A test project posting a single simulated hearth rate update to the server
• The WiringPi project – the wrapper around the C library that I used before.

A little PCL

I started a with a little PCL library WebLinker.Pcl that contains only two classes: a simple payload class that I can post from my Windows Phone to my OWIN server:

namespace WebBlinker
{
  public class Pulse
  {
    public int HeartRate { get; set; }
  }
}

and a little class to host some settings

namespace WebBlinker
{
  public static class Settings
  {
    public const string ServiceUrl = "http://192.168.0.188:5001/api/singleblink";
    public const string BaseListenUrl = "http://*:5001/";
  }
}

Rather primitive, indeed. But I want the class that I post as JSON and deserialize from JSON to be shared over client and server, and I don't like magic strings (especially not repeated magic strings) so I tend to gather those in settings classes.

The OWIN server

OWIN is a self hosted web server inside a console app – more or less Microsoft’s answer to nodejs and the like. It’s pretty simple to get started: make a console app, then add the Microsoft.AspNet.WebApi.OwinSelfHost nuget package and that brings everything you need – it’s even simpler than I described in this post. Oh, and add a reference to the PCL while you are at it.

The server contains four parts:

• A “Program” class with a static void Main – like every console app – kicking and keeping the OWIN server alive
• A “Startup” class containing the configuration of the OWIN server
• A “BlinkController” WebAPI controller hosting two methods (one for test, one for the real thing)
• A “Blinker” class that hosts a thread that does the actual blinking.

The Program class is, well, not very complicated:

using System;
using System.Threading;
using Microsoft.Owin.Hosting;

namespace WebBlinker
{
  class Program
  {
    static void Main(string[] args)
    {
      // Start OWIN host and keep it running
      using (WebApp.Start<Startup>(url: Settings.BaseListenUrl))
      {
        while (true)
        {
          Console.WriteLine("Server still alive...");
          Thread.Sleep(60000);
        }
      }
    }
  }
}

The startup class does the actual configuration and is simple but noteworthy:

using System.Web.Http;
using Owin;

namespace WebBlinker
{
  public class Startup
  {
    public void Configuration(IAppBuilder appBuilder)
    {
      var config = new HttpConfiguration();

      //Use attribute routes!
      config.MapHttpAttributeRoutes();
      appBuilder.UseWebApi(config);
      Blinker.GetBlinker().Start();
    }
  }
}

Although in general I am a fan of Microsoft technology, there are some tiny parts I hate with a vengeance. One of those things is ASP.NET MVC / WebAPI default routing. So whenever I get the chance, I go for attribute based routing. I’d rather like to have the minor chore of having to define all my routes explicitly and know they will be there, in stead of having to deal with inferred routes that might just disappear because someone else adds a route that ‘steals’ or invalidates mine. Just a pet peeve. So I did not include the default routing – I just added a call to MapHttpAttributeRoutes. Now I can control my routes pretty easily in my BlinkController by adding attributes:

using System;
using System.Web.Http;

namespace WebBlinker
{
  public class BlinkController : ApiController
  {
    [HttpPost]
    [Route("api/singleblink")]
    public void PostBlink([FromBody] Pulse pulse)
    {
      Console.WriteLine( "Got update: {0}", pulse.HeartRate);
      Blinker.GetBlinker().HeartRate = pulse.HeartRate;
    }

    [HttpGet]
    [Route("api/helloworld")]
    public string HelloWorld()
    {
      Console.WriteLine("Hello world called");
      return "Hello world!";
    }
  }
}

So now I have an explicitly defined route “api/singleblink” where I can post a Pulse object containing a heart rate to, as well as a simple “api/helloworld” method whose URL I can enter in a browser to see if the WebAPI is up and running at all.

In the “PostBlink” method our Blinker’s HeartRate property is updated. And we come to the heart of the matter – pun intended – as far as the server is concerned. What is important to understand is that the Microsoft Band does not post an update per heartbeat. It posts at a quite regular interval what your current heartbeat is. So in order to let the LED blink at the rate of a heartbeat, we actually have to calculate how often the LED needs to flash. As a matter of fact – the LED does not show your actual heartbeat. It just blinks at the same rate. More or less.

The basic setup of the Blinker is:

using System;
using System.Threading;
using System.Threading.Tasks;
using WiringPi;

namespace WebBlinker
{
  public class Blinker
  {
    private DateTime lastReceivedUpdate = DateTime.MinValue;
    private int heartRate;
    private Task task;

    private Blinker()
    {
      if (Init.WiringPiSetup() != -1)
      {
        GPIO.pinMode(BluePin, (int)GPIO.GPIOpinmode.Output);
        GPIO.pinMode(GreenPin, (int)GPIO.GPIOpinmode.Output);
        GPIO.pinMode(RedPin, (int)GPIO.GPIOpinmode.Output);
        GPIO.pinMode(SoundPin, (int)GPIO.GPIOpinmode.Output);
      }
    }

    public void Start()
    {
      if (task == null)
      {
        cancellationTokenSource = new CancellationTokenSource();
        task = new Task(() => ShowHeartRateBlinking(cancellationTokenSource.Token), 
           cancellationTokenSource.Token);
        task.Start();
      }
    }

    public void Stop()
    {
      if (cancellationTokenSource != null)
      {
        cancellationTokenSource.Cancel();
        task = null;
      }
    }

    private CancellationTokenSource cancellationTokenSource = null;


    private static Blinker blinker;
    public static Blinker GetBlinker()
    {
      return blinker ?? (blinker = new Blinker());
    }

    public const int RedPin = 27;
    public const int GreenPin = 28;
    public const int BluePin = 29;
    public const int SoundPin = 0;
  }
}

On creation, it initializes the pins we are going to use for output (these are GPIO16, GPIO20 and GPIO21 for RGB, and GPIO17 for sound). See picture for connection details. To make things easier for myself, I actually selected a blue wire for the blue pin, a red for the red ping, and green for the green pin ;):

I am using a different API than before, for this one is – amongst other reasons reasons - a lot simpler to use and does not hinge on C threading. With a caveat I will come to a little later. Important to see is that’s a singleton – there’s only a private constructor and a static method GetBlinker() to create it. Normally you would not get away with this in a web environment, but as OWIN is not hosted in IIS, we actually can use statics here. Scalable? No. But who cares on a mini device like this. Usable? Yes!

So the Startup class initializes and starts the Blinker. That fires of a cancellable task. The Blinker actually has some more code, amongst other the implementation of said task:

private async Task ShowHeartRateBlinking(CancellationToken cancellationToken)
{
  while (!cancellationToken.IsCancellationRequested)
  {
    if (DateTime.Now - lastReceivedUpdate < TimeSpan.FromSeconds(5))
    {
      DoBlink();
      await Task.Delay(60000/HeartRate, cancellationToken);
    }
    else
    {
      await Task.Delay(10000, cancellationToken);
    }
  }
}

public int HeartRate
{
  get { return heartRate; }
  set
  {
    if (value >= 0 && value <= 200)
    {
      lastReceivedUpdate = DateTime.Now;
      Console.WriteLine("Got updated: {0}", value);
      heartRate = value;
    }
  }
}

private async Task DoBlink()
{
  var pin = GetPin();
  GPIO.digitalWrite(pin, 1);
  GPIO.digitalWrite(SoundPin, 1);
  await Task.Delay(50);
  GPIO.digitalWrite(pin, 0);
  GPIO.digitalWrite(SoundPin, 0);
}

private int GetPin()
{
  if( HeartRate < 80) return BluePin;
  return HeartRate < 130 ? GreenPin : RedPin;
}

The ShowHeartRateBlinking actually is an endless loop, that runs while no cancellation is given (or until the OWIN server is simply killed). If the last update was less than 5 seconds ago, it will blink the LED and give a sound pulse, wait for 60000ms divided by the beats per minute – and goes into the next blink. If it does not get updates after 5 seconds, it goes into a 10-seconds polling mode.

The HeartRate property is set by the BlinkController when new data from the Band is posted to the OWIN server’s endpoint, and it’s setter also keeps track of the last update time. The DoBlink method actually does the blinking and the activating of the buzzer (at pin 0). The GetPin method, by means of extra fun, determines what color the LED will flash based upon the posted heart rate: blue for below 80, green for below 130, and red for 130 and up.

In the demo solution there is actually a test project with a test method that posts a single update to the OWIN server. That should at least get you a “Got updated” line on the screen when you run the server. If you run the method multiple times, the LED should start to blink at 75bmp and the buzzer gives a ticking sound.

Adapting the WiringPi wrapper

I already warned about a caveat concerning the API I am using now. Unfortunately, if you compile and run the OWIN server in this stage on the Raspberry PI2, you will get an error. Apparently the WiringPi wrapper is a bit outdated or things have changed for the Raspberry PI2. In the WrapperClass.cs file there’s a class GPIO with on top the following part:

public class GPIO
{
  [DllImport("libwiringPi.so", EntryPoint = "pinModeGpio")] 
  public static extern void pinMode(int pin, int mode);

  [DllImport("libwiringPi.so", EntryPoint = "digitalWriteGpio")]
  public static extern void digitalWrite(int pin, int value);

Studying the original C code, I found that the entry points should be just “pinMode” and “digitalWrite”, not “pinModeGpio” and “digitalWriteGpio”. That was easily fixed:

public class GPIO
{
  [DllImport("libwiringPi.so", EntryPoint = "pinMode")] 
  public static extern void pinMode(int pin, int mode);

  [DllImport("libwiringPi.so", EntryPoint = "digitalWrite")]
  public static extern void digitalWrite(int pin, int value);

If you compile the OWIN server now, and copy the .EXE and all DLLs in the bin/debug directory to your Raspberry PI2, you should now be able to run the server (sudo mono WebBlinker.exe – since settings.BaseListenerUrl is set to “http://*:5001/” it listens to port 5001 on all hostnames assigned to your Raspberry PI, and this means you have to start the webserver as root). It should print “Server still alive…” every 60 seconds on the command line, as well as any heart beat postings coming by.

The Windows Phone app

I hope my Windows Phone friends will forgive me for skimping a little on this, because I really made quite a horrible and above all ugly app. I first installed the Microsoft ASP.NET WebAPI 2.2 Client libraries in it. Then I created this model to actually listen to the Band’s heart rate events and post them to the OWIN server:

using System;
using System.Diagnostics;
using System.Linq;
using System.Net.Http;
using Microsoft.Band;
using Microsoft.Band.Sensors;
using WebBlinker;

namespace BlinkerPhone
{
  public class BlinkerModel
  {
    public async void SendSimulatedPulse(int value)
    {
      var pulse = new Pulse { HeartRate = value };
      using (var client = new HttpClient())
      {
        await client.PostAsJsonAsync(new Uri(Settings.ServiceUrl), pulse);
      }
    }

    private IBandClient bandClient;

    public async void StartListening()
    {
      var pairedBands = await BandClientManager.Instance.GetBandsAsync();
      if (pairedBands.Any())
      {
        var band = pairedBands.First();
        bandClient = await BandClientManager.Instance.ConnectAsync(band);
        var sensor = bandClient.SensorManager.HeartRate;
        sensor.ReadingChanged += SensorReadingChanged;
        await sensor.StartReadingsAsync();
      }
    }

    public async void StopListening()
    {
      var sensor = bandClient.SensorManager.HeartRate;
      sensor.ReadingChanged -= SensorReadingChanged;
      await sensor.StopReadingsAsync();
      bandClient.Dispose();
    }

    async void SensorReadingChanged(object sender, 
      BandSensorReadingEventArgs<IBandHeartRateReading> e)
    {
      try
      {
        if (e.SensorReading != null)
        {
          var pulse = new Pulse { HeartRate = e.SensorReading.HeartRate };
          using (var client = new HttpClient())
          {
            await client.PostAsJsonAsync(new Uri(Settings.ServiceUrl), pulse);
            Debug.WriteLine("Sending update, pulserate = {0}", pulse.HeartRate);
          }
        }
      }
      catch (Exception ex)
      {
        Debug.WriteLine("Error reading/sending data: {0}", ex);
      }
    }
  }
}

This is not exactly rocket science, and it’s mostly 1:1 nicked from the heart rate sensor sample in the Windows Phone Band SDK samples anyway. If there’s a heart rate event coming in, a new Pulse object is created and posted to the Raspberry PI2’s OWIN Web API endpoint and the LED starts blinking in the right rate.

To give the user the ability to start, stop and send test data I created this awesome UI with buttons to start and stop the phone sending band data to the OWIN server, as well as a button to send a simulated heart rate as typed in the textbox. Quite the pinnacle of minimalistic design I’d say, don’t you think? ;)

Conclusion

With a little imagination, out-of-the-box thinking and of course some kick *ss hardware and awesome SDKs it’s not that hard these days to let three devices dance together and make a single system – all C#, mostly Microsoft technology and mostly standard knowledge. The hardest part is now writing the C# code that runs on Mono, as it’s impossible to debug a running instance from Visual Studio. We are so spoiled by Visual Studio and the awesome tools it offers, it’s sometimes very hard to have to do without. Let’s hope Windows 10 for devices makes life as good for device developers as for all other Windows Platform developers.

For those who missed the link in between – a complete solution can be downloaded here.

AngularJS + TypeScript – using $resource to talk to a WebApi backend

Intro – multiple stacks to choose from

There are a number of ways to talk to a backend (i.e. communicate over JSON services) in Angular. I know at least of two built-in: the $http api, which basically gives you a bit raw, jQuery-like API, and the $resource API, which kind of builts on top of that, using a more formalized approach. Also, you can choose to forego the whole built-in stack and use something like Breezejs which has it own pros and cons. I used both successfully. And I don’t doubt there are more. But in this article I will concentrate on $resource.

Once again, I don’t claim ultimate wisdom nor do I claim this is the best way, but I describe a way that works and is complete.

Setting up the backend

I continue where I left off in my previous post, and proceed to add a model class in the Models folder. Mind you, this the folder in the root, not that in the app folder with TypeScript stuff in it. We are talking C#. Our application will be extended to maintain a list of phones.

namespace AtsDemo.Models
{
  public class Phone
  {
    public long Id { get; set; }

    public string Name { get; set; }

    public double ScreenSize { get; set; }
  }
}

Then add a WebApi controller in the Controllers folder. I right-clicked the Controllers folder, clicked “Add/Controller”, selected “Web API 2 Controller with read/write actions” and called it – very originally – “PhonesController”. I implemented only the Get and the Post method, to prove the communication actually works:

using System.Collections.Generic;
using System.Linq;
using System.Web.Http;
using AtsDemo.Models;

namespace AtsDemo.Controllers
{
  public class PhonesController : ApiController
  {
    private static List<Phone> phoneDb;

    private List<Phone> PhoneDb
    {
      get
      {
        if (phoneDb == null)
        {
          phoneDb = new List<Phone>
          {
            new Phone {Id = 1, Name = "Lumia 1020", ScreenSize = 4.5},
            new Phone {Id = 2, Name = "Lumia 1520", ScreenSize = 6.0},
            new Phone {Id = 3, Name = "Lumia 625",  ScreenSize = 4.7},
            new Phone {Id = 3, Name = "Lumia 930",  ScreenSize = 5.0}
          };
        }

        return phoneDb;
      }
    }
    // GET: api/Phones
    public IEnumerable<Phone> Get()
    {
      return PhoneDb;
    }

    // POST: api/Phones
    public void Post([FromBody]Phone value)
    {
      value.Id = PhoneDb.Max(p => p.Id) + 1;
      PhoneDb.Add(value);
    }
  }
}

As you can see this implements an ‘in memory database’ ;-) to list and store phones. To make sure WebApi honors the JavaScript convention of using camel casing, the following code needs to be added at the end of the Register method of the WebApi class in App_Start:

var jsonFormatter = 
  config.Formatters.OfType<JsonMediaTypeFormatter>().First();
jsonFormatter.SerializerSettings.ContractResolver = 
  new CamelCasePropertyNamesContractResolver();
config.Formatters.JsonFormatter.SupportedMediaTypes.Add(
  new MediaTypeHeaderValue("text/html"));

The last statement is actually only to make WebApi default output JSON – this is not actually necessary, but it makes testing WebApi a bit easier. To get this to work, three extra usings will be necessary:

using System.Net.Http.Formatting;
using Newtonsoft.Json.Serialization;
using System.Net.Http.Headers;

If your run the project and then change the url in http://localhost:3987/api/phones you get the following data:

[{"id":1,"name":"Lumia 1020","screenSize":4.5},{"id":2,"name":"Lumia 1520","screenSize":6.0},{"id":3,"name":"Lumia 625","screenSize":4.7},{T"id":3,"name":"Lumia 930","screenSize":5.0}]

This is easiest in Chrome, as it has no qualms about displaying raw JSON in the browser. In Internet Explorer it works as well, but IE insist on saving the file to disk, refusing it to display for security reasons. The backend now works.

Creating model and interface

If you have installed the Web Essentials 2013 for Update 2 as I recommended in the first part of this series you can now do something fun, although with such a little model not very useful yet:

• Right-click Phone.cs
• Select Web Essentials (all the way to the top)
• The select “Create TypeScript Intellisense file. This will generate a file “Phone.cs.d.ts” with the following contents:

declare module server {
    interface Phone {
        id: number;
        name: string;
        screenSize: number;
    }
}

Which gives a nice skeleton that we can use. I don't like client side models sitting next to C# code, so I create a folder "models" in my "app" folder and moved this file over to that location (for some reason that does not work in the Solution Explorer; I used the Windows Explorer to do that). I addition, I renamed the file to Phone.cs, made a class of it and put the class inside the App.Models namespace, so the net result is:

module App.Models {
    "use strict"; 
     export class Phone {
        id: number;
        name: string;
        screenSize: number;
    }
}

Now this is where is gets a little complicated and it had me reeling some time. If you want to use a resource to get models from and to a backend, you will need to define a resource on an interface, not on a class. According to this Stack Overflow example – the only one I have been able to find, although it is parroted on several other places (up to and including the errors that were – and still are – in it) – we need two interfaces like this:

module App.Models {
    export interface IPhone extends ng.resource.IResource<IPhone> {
        id: number;
        name: string;
        screenSize: number;
    }

    export interface IPhoneResource extends
       ng.resource.IResourceClass<IPhone> {
    }
}

This works fine – as long as you never need a concrete implementation of IPhone. But if you do, and you make your Phone class implement IPhone like this:

 export class Phone implements Models.IPhone

You will be rewarded with a compilation error.

Simply because an IPhone now not only needs to implement it’s three properties but also the whole kit and caboodle that comes with being a resource. 

What I came up with was to define actually three interfaces. First, we define a simple interface for the object itself:

module App.Models {
    "use strict"; 
     export interface IPhone {
         id: number;
         name: string;
         screenSize: number;
    }
}

Then we define a simple interface that only extends a resource on IPhone. I define these in the “resources” folder (and namespace) as I like to keep related stuff together. First, I define a resource definition interface

/// <reference path="../models/iphone.ts" />
 module App.Resources {
    "use strict"; 
     export interface IPhoneResourceDef
     extends ng.resource.IResource<Models.IPhone> {
     }
 }

And then we define the Resource Class on the resource definition

/// <reference path="iphoneresourcedef.ts" />
module App.Resources {
    "use strict"; 
    export interface IPhoneResource
    extends ng.resource.IResourceClass<Resources.IPhoneResourceDef> {
    }
}

Now you can still reference to an IPhone object and have a concrete implementation of it and have a resource. As you can see, having type safety comes at a price. Remember that interfaces in JavaScript don’t exist and that this code won’t translate to any JavaScript code. All you are basically doing is providing scaffolding for type checking at compile time. Pure JavaScript fans will say they can write a lot more with a lot less code. I think they are right. I assume rock star programmers with an IQ of 200 can also go a lot faster if they don’t write unit tests for .NET code as well. The rest of us, the mere mortals, need all the help we can get.

Adding a resource builder

Now this may also seem like a lot of overkill, but believe me – when you start adding more and more resources to your app, you will se a lot of repetitive code in your AppBuilder. Me se not like that, to quote a beloved ;-) Star Wars character. So I came up with this Factory to build services for me:

module App.Factories {
    "use strict"; 
    export class ResourceBuilder{

        static $inject = ['$resource'];

        constructor(private $resource: ng.resource.IResourceService) {
        }

        public getPhoneResource(): Resources.IPhoneResource {
            return  this.$resource('/api/phones/:id', { id: '@id' }, { 
            });
        }
    }
} 

So then we mosey over to the AppBuilder.ts to add this factory and the resource we are building with it:

this.app.factory("ResourceBuilder", ['$resource',
    ($resource) => new Factories.ResourceBuilder($resource)]);

this.app.factory("PhoneResource",
    ["ResourceBuilder",
        (builder: App.Factories.ResourceBuilder) => builder.getPhoneResource()]);

This is added just below the declaration of the Angular modules, and just before the only controller we currently have.

Testing the setup

Basically we are done now – the only thing is to add code to show that all this actually works. So here we go again, as explained in the first post:

• You add a new scope interface
• You add a new controller
• You add a view
• You add the controller to the app and update the router.

Scope

For a quick demo, I am going to put some objects directly on the scope, which you normally would not do to prevent issues with sub scopes:

/// <reference path="../models/iphone.ts" />
module App.Scope {
    "use strict";

    export interface IPhoneScope {
        listOfPhones: Models.IPhone[];
        newPhone: Models.IPhone
    }
}

Add a new controller

/// <reference path="../models/iphone.ts" />
/// <reference path="../models/phone.ts" />
/// <reference path="../resources/iphoneresource.ts" />
/// <reference path="../scope/iphonescope.ts" />
/// <reference path="../models/phone.ts" />

module App.Controllers {
    "use strict";
    export class PhoneController {
        constructor(private $scope: Scope.IPhoneScope, 
                    private phoneResource: Resources.IPhoneResource) {
            $scope.listOfPhones = [];
            $scope.newPhone = new Models.Phone();
        }

        public doLoadPhones(): void {
            this.phoneResource.query({}, (d: Models.IPhone[]) => this.onLoaded(d));
        }

        private onLoaded(d: Models.IPhone[]): void {
            this.$scope.listOfPhones = d;
        }
         
        public doSavePhone(): void {
            this.phoneResource.save(this.$scope.newPhone,
                () => this.saveCallback(),
                () => { alert('failure'); });
        }

        private saveCallback() {
            alert('success');
            this.$scope.newPhone = new Models.Phone();
            this.doLoadPhones();
        }
    }
}

Not really rocket science here – a method to load phones from the server using the resource “query” method, and a method to save a phone using the resource “save” method. By inheriting ng.resource.IResourceClass we got all this methods for free, in stead of that we had to implement that all by ourselves using the $http stack.

Interlude - ways to mess up TypeScript callbacks
"I have not failed. I've just found 10,000 ways that won't work" - Thomas A. Edison

Sometimes you make typos, or honest mistakes. TypeScript, although being very powerful, has, like every other programming language, it’s own unique set of particular devious pitfalls that sometimes makes you wonder if someone made them on purpose. Observe way the callback is called:

public doSavePhone(): void {
    this.phoneResource.save(this.$scope.newPhone,
        () => this.saveCallback(),
        () => { alert('failure'); });
}

This works as intended. Now the fun thing is, if you just forget the parentheses at the end, e.g.

public doSavePhone(): void {
    this.phoneResource.save(this.$scope.newPhone,
        () => this.saveCallback,
        () => { alert('failure'); });
}

This will compile flawlessly. Only - the callback never gets called. Even more fun is this one:

public doSavePhone(): void {
    this.phoneResource.save(this.$scope.newPhone,
        this.saveCallback,
        () => { alert('failure'); });
}

This will compile, and saveCallBack will even be called. Only you will notice you have lost the "this" inside saveCallback. Ain’t life fun sometimes? Please take care when making callbacks. Don't fall into the same traps I did.

Add a new view

Then we add a new view phonesView.html in views:

<div>
  <div>
    Phones
    <div data-ng-repeat="phone in listOfPhones">
      <div>Name: {{phone.name}}; screen size: {{phone.screenSize}}"</div>
    </div>
  </div>

  <button data-ng-click="phoneController.doLoadPhones()">Load phones from server</button>
  <br /><br />
  Add a new phone<br />
  <label for="name" style="width:40px">Name</label>
  <input id="name" type="text" data-ng-model="newPhone.name" /><br />
  <label for="name" style="width:40px">Size</label>
  <input id="screensize" type="text" data-ng-model="newPhone.screenSize" /><br />
  <button data-ng-click="phoneController.doSavePhone()">Save</button>
</div>

Nothing special here, a div to show loaded fields and two text boxes to input a new one.

Update the AppBuilder with the new controller and route

First, we add the new controller. Nothing that we haven't seen before.

this.app.controller("phoneController", [
    "$scope", "PhoneResource", 
    ($scope: Scope.IPhoneScope, phoneResource: Resources.IPhoneResource)
        => new App.Controllers.PhoneController($scope, phoneResource )
]);

Then we add the new route to the controller, and make it the new default route. Also nothing new

this.app.config([
    "$routeProvider",
    ($routeProvider: ng.route.IRouteProvider) => { 
        $routeProvider
            .when("/person",
            {
                controller: "personController",
                controllerAs: "myController",
                templateUrl: "app/views/personView.html"
            })
            .when("/phones",
            {
                controller: "phoneController",
                controllerAs: "phoneController",
                templateUrl: "app/views/phonesView.html"
            })
            .otherwise({
                redirectTo: "/phones"
            });
    }
]);

Running the test

If you start the web application, you will initially see this:

Then, if you hit “Load phones from server”, it will show:

Then suppose we add the 530:

and hit save, we will see the “success” alert pop up, and finally,

Success at last.

Conclusion

This took me quite some time to figure out, and I am not one to sing my own praise but this may just be the only complete – and running – sample of using Angularjs resources with TypeScript. Most of what I wrote here is out there somewhere on the web, in bits and pieces, and sometimes partially wrong. Anyway. This works. Running sample solution, as always, can be downloaded here.

Now my only hope is that I won’t get sued over violating some copyright rules by defining a TypeScript interface whose name resembles a popular brand of phones made by a company whose name resembles a common fruit ;-)