Related Posts:

1. Writing a simple implementation of dependency injection in MVC 4 Web API with .NET Framework 4.5
2. Writing BDD style unit tests to verify the MVC based Web API

To recap, so far we put together a MVC based Web API and examined the mechanism for plugging in a very simple dependency injection mechanism without using an established framework. Further on we added BDD style unit tests to verify the API behavior. Since the base framework is established and sensor readings are getting generated as expected, let’s develop a UI client to consume the generated data. Now there are several ways to consume and display the sensor data such as a desktop client, WPF client, browser client, Windows Store client and what not!

How about a mobile client such as one based on Windows Phone 8.1 that also coincides with the mission statement of Microsoft:

“….To create a family of devices and services for individuals and businesses that empower people around the globe at home, at work and on the go, for the activities they value most…." 

Without further ado, let’s dig into this idea! Start by adding a new Windows Phone project to the solution.

Right click on the Solution and choose Add—>New Project… Select Windows Phone as the project type. There are several templates available for creating a Windows Phone project. Since we need two pages, one for generating and storing sensor readings and another for browsing the sensor data, let’s choose Blank App template and add these pivots manually:

To adhere to Globalization and Localization best practices for Windows Phone, we’ll store all the resource strings in resource files. Create a new folder called Strings and add another folder under it to store en-US strings. Now add a new Resource file (Resources.resw) under en-US folder as shown below:

Once the resource file is created, resource editor window opens, allowing you to enter the resource strings for your app. Copy and paste the following strings:

Name	Value	Comment
PagingControl.Text	Total: {0} - Showing Page {1} of {2}
PivotPostReadings.Header	Record Readings
PivotSensorDataTracker.Title	SENSOR DATA TRACKER
PivotShowReadings.Header	View Readings
SensorReadingTitle.Text	Sensor Readings
SubmitButton.Content	Submit Reading

We’ll create a Portable Class Library (PCL) so that we may share the code that accesses the web API between various clients. Add a new project to the solution called SensorDataTracker.CommonLogic as shown below:

When you create a PCL project, Visual Studio asks you which frameworks you wish to target. Make sure that the following options are selected in the dialog:

[Note that the last two boxes are visible only if you’ve Xamarin platform installed on your box.]

In Visual Studio, right-click the SensorDataTracker.CommonLogic project, and then select Manage NuGet Packages for solution. In the Manage NuGet Packages dialog, select Online->All in the left pane, make sure that Include Prerelease is selected in the dropdown and then search for “Microsoft.AspNet.WebApi.Client” as follows:

Install the selected NuGet package that enables us to use System.Net.Http namespace for formatting and content negotiation.

Create a new folder called Services in the SensorDataTracker.CommonLogic project, and add an IHttpService interface. Copy and paste the following code:

namespace SensorDataTracker.CommonLogic.Services
{
    using System.Threading;
    using System.Threading.Tasks;
    public interface IHttpService
    {
        Task<string> PostAsync(Uri postUri, string postBody);
        Task<string> GetAsync(Uri requestUri);
        Task<string> PostAsync(Uri postUri, string postBody, CancellationToken cancellationToken);
        Task<string> GetAsync(Uri requestUri, CancellationToken cancellationToken);
    }
}

The interface IHttpService declares four async Task methods, two each for GET and POST API calls with the only difference of cancellation token being passed in the overloaded version.

Let’s go ahead and write a generic implementation of this service interface. Go ahead and create a class called HttpService in the same folder and copy/paste the following code:

namespace SensorDataTracker.CommonLogic.Services
{
    using System;
    using System.Net.Http;
    using System.Text;
    using System.Threading;
    using System.Threading.Tasks;
    public class HttpService : IHttpService
    {
        public async Task<string> PostAsync(Uri postUri, string postBody)
        {
            return await this.PostAsync(postUri, postBody, CancellationToken.None);
        }
        public async Task<string> GetAsync(Uri requestUri)
        {
            return await this.GetAsync(requestUri, CancellationToken.None);
        }
        public async Task<string> PostAsync(Uri postUri, string postBody, CancellationToken cancellationToken)
        {
            using (var httpClient = new HttpClient())
            {
                var postData = new StringContent(postBody, Encoding.UTF8, "application/json");
                var response = await httpClient.PostAsync(postUri, postData, cancellationToken);
                response.EnsureSuccessStatusCode();
                return await response.Content.ReadAsStringAsync();
            }
        }
        public async Task<string> GetAsync(Uri requestUri, CancellationToken cancellationToken)
        {
            using (var httpClient = new HttpClient())
            {
                var response = await httpClient.GetAsync(requestUri, cancellationToken);
                response.EnsureSuccessStatusCode();
                return await response.Content.ReadAsStringAsync();
            }
        }
    }
}

As you can see, we’re using HttpClient (added via NuGet package reference) class to get an async JSON response from the web service and similarly posting a JSON payload to the post controller method of the API. Pretty straightforward!

Since we’re encapsulating service interaction logic in a PCL, we might need to do some refactoring here in order to make the models definition available to the clients such as Windows Phone. Though in a real world project, you might consider moving the model to another shared library and hooking up with the service API using a repository pattern that allows nice separation of concerns with the ability to write unit tests against mock representation of data. However for this exercise, moving the Models folder (that has SendorReading and ResultPage classes) from web API project to PCL project suffices. After the move, SensorDataTracker.CommonLogic should look like below:

Don’t forget that you’ll need to make appropriate namespace corrections and add a reference to PCL project in the web API project (SensorDataTracker) so that models are visible to the latter. Likewise you’ll need to add reference to PCL project in the test project (SensorDataTracker.Test) and fix the namespaces, relatively trivial tasks towards the cost of flexibility!

Since the generic service classes are in place, let’s write another layer that makes use of the generic service methods to retrieve and post sensor data to the web API. Under Services folder, add a new interface ISensorDataTrackerService and copy/paste the following code:

namespace SensorDataTracker.CommonLogic.Services
{
    using SensorDataTracker.CommonLogic.Models;
    using System.Threading.Tasks;
    interface ISensorDataTrackerService
    {
        Task<ResultPage<SensorReading>> GetSensorReadingsAsync();
        Task<ResultPage<SensorReading>> GetSensorReadingsAsync(int pageNumber);
        Task PostSensorReadingAsync(SensorReading reading);
    }
}

We’ve declared three methods, two for retrieving sensor readings and the third one for posting the sensor reading. Let’s implement them in a class called SensorDataTrackerService under the Services folder as before:

namespace SensorDataTracker.CommonLogic.Services
{
    using System;
    using System.Globalization;
    using System.Threading.Tasks;
    using Newtonsoft.Json;
    using SensorDataTracker.CommonLogic.Models;
    public class SensorDataTrackerService : ISensorDataTrackerService
    {
        private readonly IHttpService _httpService;
        private const int DefaultPageIndex = 1;
        private const string ServerAddress = "https://sensordatatracker.cloudapp.net";
        private readonly string sensorReadingBaseUrl = string.Format(
            CultureInfo.InvariantCulture,
            "{0}/api/SensorReading",
            ServerAddress);
        private const string PaginationQueryString = "{0}?pageNumber={1}";
        public SensorDataTrackerService(IHttpService httpService)
        {
            this._httpService = httpService;
        }
        
        public async Task<ResultPage<SensorReading>> GetSensorReadingsAsync()
        {
            return await this.GetSensorReadingsAsync(DefaultPageIndex);
        }
        public async Task<ResultPage<SensorReading>> GetSensorReadingsAsync(int pageNumber)
        {
            var requestUri = new Uri(string.Format(PaginationQueryString, this.sensorReadingBaseUrl, pageNumber));
            var responseContent = await this._httpService.GetAsync(requestUri);
            return JsonConvert.DeserializeObject<ResultPage<SensorReading>>(responseContent);            
        }
        public async Task PostSensorReadingAsync(SensorReading reading)
        {
            var postUri = new Uri(sensorReadingBaseUrl);
            await this._httpService.PostAsync(postUri, JsonConvert.SerializeObject(reading));
        }
    }
}

Let’s understand the code above before we inch ahead. SensorReadingTrackerService has a constructor that required a reference to an IHttpService that we defined previously. ServerAddress points to the web API location and sensorReadingBaseUrl contains the additional prefix for the GET and POST methods of the service controller. PaginationQueryString is concatenated to the sensorReadingBaseUrl that allows us to pass in a page number. GetSensorReadingsAsync(int pageNumber) composes a Uri with the given page number and asynchronously calls the GetAsync method of HttpService. It then uses DeserializeObject method of JsonConvert class to cast the response into a ResultPage of SensorReading objects before returning. Similarly PostSensorReadingAsync serializes a SensorReading and posts it to the service.

With PCL in place, it’s time to revisit the Windows Phone 8.1 client. Add a reference to PCL project in Windows Phone 8.1 client project.

Double click MainPage.xaml to open the designer and paste the following code, overwriting the existing:

<Page
    x:Class="SensorDataTracker.WindowsPhone.Client.MainPage"
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="https://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="https://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="*"></RowDefinition>
            <RowDefinition Height="30"></RowDefinition>
        </Grid.RowDefinitions>
        <Pivot Title="" x:Uid="PivotSensorDataTracker" Grid.Row="0"
               x:Name="PivotContainer"
               SelectionChanged="PivotContainer_OnSelectionChanged">
            <PivotItem Header="PivotItem 0" x:Uid="PivotPostReadings">
                <Grid Margin="12,0,12,0">
                    <StackPanel Orientation="Vertical">
                        <TextBlock Text="" x:Uid="SensorReadingTitle"
                                   Margin="10,0,0,0"
                                   FontFamily="Verdana"
                                   FontSize="20"/>
                        <TextBlock 
                                   x:Name="TextSensorReadingId"
                                   FontFamily="Verdana"
                                   FontSize="80"
                                   FontStretch="UltraExpanded"
                                   FontWeight="ExtraBlack"
                                   HorizontalAlignment="Center"
                                   Margin="10"
                                   Foreground="Khaki" />
                        <Button Content="" x:Uid="SubmitButton"
                                Click="SubmitButton_OnClick" />
                    </StackPanel>
                </Grid>
            </PivotItem>
            <PivotItem Header="PivotItem 1" x:Uid="PivotShowReadings">
                <Grid Margin="12,0,12,0">
                    <StackPanel Orientation="Vertical">
                        <Grid>
                            <TextBlock Text="" x:Uid="SensorReadingTitle"
                                   Margin="10,0,0,0"
                                   FontFamily="Verdana"
                                   FontSize="20"/>
                        </Grid>
                        <ItemsControl Margin="10"
                                      Name="SensorReadingList">
                            <ItemsControl.Template>
                                <ControlTemplate TargetType="ItemsControl">
                                    <Border BorderBrush="Aqua"
                                            BorderThickness="1"
                                            CornerRadius="10">
                                        <ItemsPresenter />
                                    </Border>
                                </ControlTemplate>
                            </ItemsControl.Template>
                            <ItemsControl.ItemTemplate>
                                <DataTemplate>
                                    <Grid>
                                        <Ellipse Fill="Silver"
                                                 Opacity="0.50"
                                                 Stroke="DarkSlateBlue"
                                                 StrokeThickness="2" />
                                        <StackPanel>
                                            <TextBlock Margin="3,3,3,0"
                                                       FontSize="20"
                                                       HorizontalAlignment="Center"
                                                       Text="{Binding Path=Id}" />
                                            <TextBlock Margin="3,0,3,7"
                                                       FontSize="20"
                                                       HorizontalAlignment="Center"
                                                       Text="{Binding Path=CreateDate}" />
                                        </StackPanel>
                                    </Grid>
                                </DataTemplate>
                            </ItemsControl.ItemTemplate>
                        </ItemsControl>
                        <Grid>
                            <Grid.RowDefinitions>
                                <RowDefinition Height="30"></RowDefinition>
                                <RowDefinition Height="50"></RowDefinition>
                            </Grid.RowDefinitions>
                            <Grid.ColumnDefinitions>
                                <ColumnDefinition Width="120"></ColumnDefinition>
                                <ColumnDefinition Width="*"></ColumnDefinition>
                                <ColumnDefinition Width="120"></ColumnDefinition>
                            </Grid.ColumnDefinitions>
                            <TextBlock x:Name="PageInfo"
                                       x:Uid="PagingControl"
                                       Grid.Column="0"
                                       Grid.Row="0"
                                       Grid.ColumnSpan="3"
                                       HorizontalAlignment="Center"
                                       VerticalAlignment="Center"
                                       FontSize="16" />
                            <Button x:Name="PrevPage"
                                    Grid.Column="0"
                                    Grid.Row="1"
                                    IsEnabled="False"
                                    Content="&#xE100;"
                                    FontFamily="Segoe UI Symbol"
                                    FontSize="20"
                                    Click="BrowsePage_OnClick" />
                            <Button x:Name="NextPage"
                                    Grid.Column="2"
                                    Grid.Row="1"
                                    Content="&#xE101;"
                                    FontFamily="Segoe UI Symbol"
                                    FontSize="20"
                                    Click="BrowsePage_OnClick" />
                        </Grid>
                    </StackPanel>
                </Grid>
            </PivotItem>
        </Pivot>
        <StackPanel VerticalAlignment="Top"
                    Grid.Row="1">
            <ProgressBar Margin="10"
                         x:Name="NetworkActivity"
                         IsIndeterminate="False"
                         Height="15" />
        </StackPanel>
    </Grid>
</Page>

In the XAML markup, we’re creating a Pivot control with two pivot items, first for posting the sensor readings and second for viewing the pages of sensor readings.

In the first pivot item, a grid control lays out a couple of text blocks to display a title and a large random sensor reading, finishing with a button to submit the reading. In the second pivot item, I tried to be a little bit artistic (and evidently I’m not good at it but at least I tried ) by creating a rounded rectangle with an ellipse inside it enclosing the sensor reading. A pager control follows the visually appealing rendition that displays information about the number of records out of total and the number of page we’re on, succeeded by a row containing previous and next buttons. A progress bar is included that is outside the pivot control (to track network activity) and thus is available on both pages.

Okay…let’s now wire up the event handlers to enliven the dead UI elements! Open MainPage.xaml.cs and copy/paste the following code:

namespace SensorDataTracker.WindowsPhone.Client
{
    using SensorDataTracker.CommonLogic.Models;
    using SensorDataTracker.CommonLogic.Services;
    using System;
    using System.Collections.Generic;
    using System.Globalization;
    using Windows.UI.Xaml;
    using Windows.UI.Xaml.Controls;
    using Windows.UI.Xaml.Navigation;
    public sealed partial class MainPage : Page
    {
        private readonly Random _readingGenerator;
        private const int MaxNum = 10000;
        private int _currentPage = 1;
        private const double PageSize = 5;
        private readonly IDictionary<string, int> _buttonPageActions = new Dictionary<string, int>
            {
                {"PrevPage",-1},
                {"NextPage",1},
            };
        private readonly SensorDataTrackerService _sensorService = new SensorDataTrackerService(new HttpService());
        private string _pagerFormatString;
        public MainPage()
        {
            this.InitializeComponent();
            this.NavigationCacheMode = NavigationCacheMode.Required;
            _readingGenerator = new Random();
        }
        private void PivotContainer_OnSelectionChanged(object sender, SelectionChangedEventArgs e)
        {
            if (PivotContainer.SelectedIndex == 1)
            {
                this.LoadSensorReadings();
            }
            else
            {
                this.ShowNextReading();
            }
        }
        private async void LoadSensorReadings()
        {
            NetworkActivity.IsIndeterminate = true;
            var sensorReadings = await _sensorService.GetSensorReadingsAsync(_currentPage);
            this.UpdateControls(sensorReadings);
            NetworkActivity.IsIndeterminate = false;
        }
        private void ShowNextReading()
        {
            TextSensorReadingId.Text = string.Format(CultureInfo.CurrentCulture, "{0}", _readingGenerator.Next(0, MaxNum));
        }
        private async void SubmitButton_OnClick(object sender, RoutedEventArgs e)
        {
            var sensorReading = new SensorReading()
                                {
                                    Id = Convert.ToInt32(TextSensorReadingId.Text),
                                    CreateDate = DateTime.Now
                                };
            NetworkActivity.IsIndeterminate = true;
            await _sensorService.PostSensorReadingAsync(sensorReading);
            this.ShowNextReading();
            NetworkActivity.IsIndeterminate = false;
        }
        private void BrowsePage_OnClick(object sender, RoutedEventArgs e)
        {
            var button = (Button)sender;
            var key = button.Name;
            var increment = this._buttonPageActions.ContainsKey(key) ? this._buttonPageActions[key] : 0;
            _currentPage += increment;
            LoadSensorReadings();
        }
        private void UpdateControls(ResultPage<SensorReading> resultPage )
        {
            var totalCount = Convert.ToInt32(resultPage.TotalCount);
            var totalNumberOfPages = (totalCount <= PageSize)
                ? 1
                : Math.Ceiling(totalCount / PageSize);
            if (string.IsNullOrWhiteSpace(_pagerFormatString)) _pagerFormatString = PageInfo.Text;
            PageInfo.Text = string.Format(CultureInfo.CurrentCulture,
                _pagerFormatString,
                resultPage.TotalCount,
                _currentPage,
                totalNumberOfPages);
            PrevPage.IsEnabled = _currentPage > 1;
            NextPage.IsEnabled = _currentPage < totalNumberOfPages;
            SensorReadingList.ItemsSource = resultPage.Results;
        }
    }
}

Let’s start dissecting the code from beginning. Fields include:

1. A random reading generator that generates a random number under a specified MaxNum.
2. Current page number tracker.
3. Number of records to fetch per page indicated by PageSize.
4. A dictionary to keep track of browse button clicks, –1 for previous and 1 for next.
5. SensorDataTrackerService instance to invoke the service methods.

Event handler PivotContainer_OnSelectionChanged, handles the cycling between pivot items and based on the index either readings are fetched or a new reading is generated for submission.

LoadSensorReadings fetches the readings from the web API asynchronously and updates the controls including the progress indicator.

Let’s take a closer look at UpdateControls method:

        private void UpdateControls(ResultPage<SensorReading> resultPage )
        {
            var totalCount = Convert.ToInt32(resultPage.TotalCount);
            var totalNumberOfPages = (totalCount <= PageSize)
                ? 1
                : Math.Ceiling(totalCount / PageSize);
            if (string.IsNullOrWhiteSpace(_pagerFormatString)) _pagerFormatString = PageInfo.Text;
            PageInfo.Text = string.Format(CultureInfo.CurrentCulture,
                _pagerFormatString,
                resultPage.TotalCount,
                _currentPage,
                totalNumberOfPages);
            PrevPage.IsEnabled = _currentPage > 1;
            NextPage.IsEnabled = _currentPage < totalNumberOfPages;
            SensorReadingList.ItemsSource = resultPage.Results;
        }

UpdateControls gets a JSON deserialized ResultPage that holds SensorReading objects in the form of Results collection and a TotalCount of records, the latter being required to calculate the number of pages. TotalCount is divided by PageSize to obtain the number of pages if it’s greater than the latter else one page is assumed. Pager format string is initialized with the resource string PageInfo.Text and respective placeholders are replaced with total count, current page and total number of pages, e.g. Total: 12 – Showing page 1 of 3. Based on the current page and total number of pages, prev and next buttons are enabled or disabled using a simple calculation. Finally the Results collection is assigned as the source of items for ItemsControl declared in XAML.

Event handler SubmitButton_OnClick creates a new SensorReading with the random number as Id and current date as CreateDate that is posted asynchronously to the web API.

Event handler BrowsePage_OnClick handles the paging between sensor readings pages. First it determines which button was clicked based on the sender’s Name property, looks it up as a key in the dictionary and then uses the corresponding value to advance the current page forward or backward.

That pretty much sums up the Windows Phone 8.1 client functionality! There is an inherent issue with Windows Phone emulator. Since Windows Phone 8.1 emulator employs a virtual machine under the covers, it has the same IP address as the host machine - so all the references that use the localhost IP address end up in loopback. To get around this issue, you need to configure the IIS express or IIS server so that it may distinguish between the requests coming from the emulator and local machine. See this article on curah.microsoft.com for some possible workarounds. However on a corporate domain, the emulator appears as a separate network device that is not joined to the domain. As a result, you may also have to get an exception from your IT department before the emulator can connect to services that are running on the domain-joined development computer. Due to the aforementioned nuisance I prefer to deploy my web API to Microsoft Azure Cloud which is trivial comparatively!

Let’s convert the web API that we created previously to an Azure Cloud project. Right click on SensorDataTracker project and choose Convert—>Convert to Windows Azure Cloud Service Project option:

A new cloud wrapper project gets created as shown below:

Right click on SensorDataTracker.Azure project and choose Publish option. The following dialog appears:

Choose your Azure subscription and a new or existing Cloud service to deploy to (in the next dialog shown below) and click on the Publish button. You may optionally save the target profile giving it a name of your choice or leave the defaults.

As you may’ve already noted, I used the service URL of the Azure deployed web API service in SensorDataTrackerService class. Set Windows Phone 8.1 client as the Startup project and click on emulator 8.1 option to deploy the package to Windows Phone 8.1 emulator and start the app:

When the emulator starts it appears as below:

Click on Submit Reading button. Once the reading is posted, a new random reading appears. Play around by posting several readings and then scroll to View Readings pivot item that should appear somewhat like below:

It has been a pretty long post but if you’ve carefully followed all the steps up till now, you should’ve a full fledged Windows Phone 8.1 client for your web API and well on your way towards developing the next one that is, well, not a rocket science to guess! Since we already have a nice separation of functionality in a PCL, we’ll look into extending our client base in the next post via a Windows Store client! As always your feedback is highly appreciated! Please don’t hesitate to point out any errors or omissions.

Related Posts:

1. Writing a simple implementation of dependency injection in MVC 4 Web API with .NET Framework 4.5
2. Writing BDD style unit tests to verify the MVC based Web API

[Previous post –>Writing a simple implementation of dependency injection in MVC 4 Web API with .NET Framework 4.5]

In my previous blog post, we developed a simple REST based web API that exposes web methods using MVC 4 controller. We also discussed how to implement a simple dependency injection mechanism using the inbuilt IDependencyResolver interface, which may be useful to understand the IoC pattern for academic purposes though the practical implementation inevitably requires a DI framework such as Unity framework by Microsoft Patterns and Practices team! (Winking for the shameless promotion though it’s among the best out there and we recently utilized it in our latest guidance that shows how to use Microsoft Azure Media Services to build an On-Demand Video Service. And here goes another for the latter!

Okay, let’s get back to the topic under discussion before I deviate any further. In this post, first we’ll write a couple of BDD style unit tests to verify the API methods.

To the solution created in the previous step, add a new solution folder named Test and create a new Unit Test Project named SensorDataTracker.Test under the Test folder:

Rename the default source file UnitTest1.cs to TestHarness.cs:

Replace the code in TestHarness.cs with the following:

namespace SensorDataTracker.Test
{
    using System;
    using System.Collections.Generic;
    using SensorDataTracker.Models;
    using SensorDataTracker.Store;
    internal static class TestHarness
    {
        internal static IEnumerable<SensorReading> GenerateAndStoreReadings(
            ISensorReadingStore store,
            int count,
            Func<int, int> genMethod)
        {
            var readings = new List<SensorReading>();
            for (var i = 0; i < count; i++)
            {
                var sensorReading = new SensorReading { Id = genMethod(i) };
                readings.Add(sensorReading);
                store.Save(sensorReading);
            }
            return readings;
        }
    }
}

As you can see, we’ve created a utility method that generates and store readings. For the sake of brevity, the same method is generating as well as storing the readings though ideally in order to adhere to SRP, you’d like to refactor! The method GenerateAndStoreReadings expects a SensorReadingStore object, a count of readings to generate and a method that acts as the reading generator. A SensorReading is generated and added to a list as well as to a SensorReadingStore and finally the list of readings is returned to the caller.

Now since the harness is in place, we’re ready to add our first unit test. Add a new class to SensorDataTracker.Test project and name it SensorReadingStoreTest.cs as shown below:

Paste the following code in SensorReadingStoreTest.cs file:

namespace SensorDataTracker.Test
{
    using System.Collections.Generic;
    using System.Linq;
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    using SensorDataTracker.Models;
    using SensorDataTracker.Store;
    [TestClass]
    public class SensorReadingStoreTest
    {
        [TestMethod]
        public void WhenSavingItemsShouldReturnSincereRepresentationOfTheItems()
        {
            // Given
            var store = new SensorReadingStore();
            var readings = TestHarness.GenerateAndStoreReadings(store, 3, i => 2 * i + 1);
            // When
            var results = store.Get().Results.ToList();
            // Then
            CollectionAssert.AreEqual(
                readings.ToArray(),
                results,
                Comparer<SensorReading>.Create((x, y) => x.Id.CompareTo(y.Id)));
        }
    }
}

Carefully examine the language I used while naming the test that self-documents the intent of the test. The test is nicely structured to depict that

given a specific set of initial conditions

when certain operations are performed that triggers a scenario

then specific set of outcomes should be obtained.

The test first creates 3 sensor readings using any random function such as an odd number generation algorithm in this particular case and saves the readings to the store. When readings are obtained from the in memory store they should match with the list of readings returned by the method that generates and stores the sensor readings. Note the use of a Comparer delegate that uses a lambda expression to compare the corresponding ids of two collections of sensor readings, pretty elegant!

Let’s add another test. Add the following code in SensorReadingStoreTest.cs:

        [TestMethod]
        public void WhenSecondPageIsRequestedShouldReturnTheSecondPageOfResults()
        {
            var store = new SensorReadingStore();
            const int TwoPages = 2 * SensorReadingStore.PageSize;
            for (var i = 0; i < TwoPages; i++)
            {
                store.Save(new SensorReading() { Id = i, CreateDate = DateTime.Now });
            }
            var page = store.Get(2);
            Assert.AreEqual(SensorReadingStore.PageSize, page.Results.Count());
            Assert.AreEqual(SensorReadingStore.PageSize, page.Results.First().Id);
        }

Here we’re verifying that on requesting the second page of sensor readings, the test should indeed return the second page. And how do we verify if we’re actually getting the second page? First we initialize a constant integer to double the size of a page e.g. if one page stores 5 readings then TwoPages is initialized to 10. Now we store sensor readings with ids from 0 to 9 in the SensorReadingStore instance and then request the second page of results (ResultPage) from the Web API controller using Get method. And all we’re left to do, is to verify that the number of results and the Id of the first reading in the second page both match the PageSize!

Now let’s run the tests and verify that they are passing. I prefer to run all my tests in the Test Explorer window. To bring up Test Explorer in Visual Studio 2013, choose TEST—>Windows—>Test Explorer from the main menu. Select Run All option in the toolbar of Test Explorer window and you should see something similar to below if all goes well!

That’s it! In the next blog post, we’ll add a Windows Phone client that consumes the Web API so stay tuned. .

[Next Post—>Developing a Windows Phone 8.1 client for the sensor data tracker web API via a Portable Class Library]

ASP.NET Web API allows developers to expose data and services to the Web directly over HTTP. This approach offers developers the ability to fully harness the richness of HTTP as an application layer protocol to communicate with a broad set of clients, including browsers, mobile devices, desktop applications, or backend services. The architecture is designed to support applications built with REST, but it does not force new applications to use a REST-style architecture.

This article does not intend to be a full blown walkthrough or tutorial for developing Web API services using .NET Framework 4.5 but rather demonstrates the use of a simple implementation of inbuilt dependency injection (DI) [also known as Inversion of Control (IOC)] mechanism. Microsoft Patterns and Practices team have developed their own DI framework called Unity that is the more suitable candidate in elaborated scenarios. Latest version of Enterprise Library that includes Unity framework can be found on Codeplex. Here is the link: https://entlib.codeplex.com/releases/view/64243. It's highly recommended to read the accompanying developers guide to get a thorough understanding of the DI even if you're looking to use a different DI framework!

I’m using Visual Studio 2012 Update 2 though Visual Studio 2012 or Visual Studio 2012 Express, Visual Studio 2010 (with ASP.NET Web API extension installed) should work well. Some familiarity with MVC architecture is assumed but is not a requirement for understanding the code.

The first step to creating a Web API service is to fire up the IDE and create a new project of type ASP.NET MVC 4 Web Application:

In the next dialog, choose Web API as the template and leave rest of the options as they are.

Click on OK button and a new Web API project based on MVC 4 is generated for you. Since the intent of this tutorial is to exhibit simple inbuilt DI mechanism in Web API MVC 4, we'll not go into the details of the architecture or MVC in general. We'll start by adding a couple of model classes to represent a fictional sensor reading and a results page displaying all the readings for a user. Right click on Models folder and add a new class named SensorReading as shown:

Replace the code in SensorReading.cs with the following code:

namespace SensorDataTracker.Models
{
    using System;
    public class SensorReading
    {
        public int Id { get; set; }
        public DateTime CreateDate { get; set; }
    }
}

As it’s trivial to figure out, we’re creating a class to represent a sensor reading:

1. Id – Actual numeric reading
2. CreateDate – Date and time when the reading was taken

Similarly create another model class and name it ResultPage. Replace the code in ResultPage.cs with the following code:

namespace SensorDataTracker.Models
{
    using System.Collections.Generic;
    public class ResultPage<T>
    {
        public int TotalCount { get; set; }
        public int PageNumber { get; set; }
        public IEnumerable<T> Results { get; set; }
    }
}

Similarly we’re creating a generic collection holder ResultPage class that has:

1. TotalCount – Total number of sensor readings.
2. PageNumber – Current page number
3. Results – Generic collection of objects that may be used to store any object.

Now we'll implement a mechanism for fake persistence of the readings using an in memory store that simply stores the readings for the duration of the session in a memory collection, though a real implementation shall have a backend database to persist and retrieve the values at will.

Add a new folder to the project and call it Store.

Under folder Store, add an interface named ISensorReadingStore. Replace the code in ISensorReadingStore.cs with the following code:

namespace SensorDataTracker.Store
{
    using SensorDataTracker.CommonLogic.Models;
    public interface ISensorReadingStore
    {
        void Save(SensorReading reading);
        ResultPage<SensorReading> Get();
        ResultPage<SensorReading> Get(int pageNumber);
    }
}

Again under folder Store, add a new class named SensorReadingStore. Replace the code in SensorReadingStore.cs with the following code:

namespace SensorDataTracker.Store
{
    using SensorDataTracker.Models;
    using System.Collections.Generic;
    using System.Linq;
    public class SensorReadingStore : ISensorReadingStore
    {
        private readonly IList<SensorReading> _internalStore = new List<SensorReading>();
        public const int PageSize = 5;
        public void Save(SensorReading reading)
        {
            _internalStore.Add(new SensorReading { Id = reading.Id, CreateDate = reading.CreateDate });
        }
        public ResultPage<SensorReading> Get()
        {
            return this.Get(1);
        }
        public ResultPage<SensorReading> Get(int pageNumber)
        {
            var skipCount = (pageNumber - 1) * PageSize;
            return new ResultPage<SensorReading>
                       {
                           TotalCount = _internalStore.Count(),
                           PageNumber = pageNumber,
                           Results = _internalStore.Skip(skipCount).Take(PageSize)
                       };
        }
    }
}

Notice how we’re using an interface to represent our store. In order to plug-in DI, we need to design our application with loose coupling and no hard dependencies in place since the DI framework accesses the system via interfaces. This is also very handy approach for unit testing since fake representations of the underlying store may be created with a very few lines of code and tests are executed against the latter as opposed to running the test against say a store that hosts SQL database!

Next step is to create the Web API controller that handles all the requests from user interface and simultaneously interact with our store to retrieve and save values. Locate the Controllers folder and delete the default API controller ValuesController.cs file since we’re plugging in our own.

[Note: You may have to delete the corresponding Unit Test controller if you chose to create the unit test project initially, otherwise you’ll see compile errors.]

Right click on Controllers folder and select Add-->Controller. Make sure that the dialog looks like as below:

Replace the code in SensorReadingController.cs with the following code:

namespace SensorDataTracker.Controllers
{
    using SensorDataTracker.Models;
    using SensorDataTracker.Store;
    using System.Net;
    using System.Web.Http;
    public class SensorReadingController : ApiController
    {
        private readonly ISensorReadingStore _store;
        public SensorReadingController(ISensorReadingStore store)
        {
            _store = store;
        }
        public void Post(SensorReading reading)
        {
            if(reading==null) throw new HttpResponseException(HttpStatusCode.BadRequest);
            _store.Save(reading);
        }
        public ResultPage<SensorReading> Get()
        {
            return Get(1);
        }
        public ResultPage<SensorReading> Get(int pageNumber)
        {
            return _store.Get(pageNumber);
        }
    }
}

As you can see, we’ve methods mapping to GET and POST requests with one overload of GET that takes a page number as a parameter. Notice the constructor of SensorReadingController class that takes an interface as a parameter – classic paradigm of DI implementation. This way the controller doesn’t need to be dependent on a specific implementation of store and DI framework may inject the dependency at runtime.

Okay…so now since we’ve the initial wiring setup, it’s time to plug-in the implementation of the build in DI framework. Right click on App_Start folder and add a new class ResolveController.cs and insert the following code:

using System;
using System.Collections.Generic;
using System.Web.Http.Dependencies;
using SensorDataTracker.Controllers;
using SensorDataTracker.Store;
namespace SensorDataTracker.App_Start
{
    public class ResolveController : IDependencyResolver
    {
        private static readonly ISensorReadingStore ReadingStore = new SensorReadingStore();
        public object GetService(Type serviceType)
        {
            return serviceType == typeof(SensorReadingController) ? new SensorReadingController(ReadingStore) : null;
        }
        public IEnumerable<object> GetServices(Type serviceType)
        {
            return new List<object>();
        }
        public IDependencyScope BeginScope()
        {
            return this;
        }
        public void Dispose()
        {
           
        }
    }
}

Let’s quickly walkthrough the code before moving further. Here we’re creating a DI controller by implementing the inbuilt IDependencyResolver interface. You need to provide implementation of service finder methods GetService and GetServices both accepting a type as parameter. Since we’re creating a simple implementation of DI framework, we may ignore the GetServices method for the time being and simply return a collection of objects which is the recommended approach. In our over-simplistic model, we’re leaving Dispose method empty since we’re not holding onto an expensive resource that needs to be released. For BeginScope, since in this case we don’t have a concept of a scope or resource release, we may simply return this object!

Crux of the implementation is GetService method. Since we’re dealing with only one implementation of controller, we’re checking the type of the passed in controller and if it’s of type SensorReadingController we’re creating a new instance of controller and passing it the default implementation of ISensorReadingStore and that’s it!

Next step is to let the framework know about the dependency resolver we’re using and we’re going to do this in WebApiConfig.cs file that contains the HTTP route mapping table.

Expand the App_Start folder and open WebApiConfig.cs file. Replace the existing code with the following:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web.Http;
using SensorDataTracker.App_Start;
namespace SensorDataTracker
{
    public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
            // Uncomment the following line of code to enable query support for actions with an IQueryable or IQueryable<T> return type.
            // To avoid processing unexpected or malicious queries, use the validation settings on QueryableAttribute to validate incoming queries.
            // For more information, visit https://go.microsoft.com/fwlink/?LinkId=279712.
            //config.EnableQuerySupport();
            // To disable tracing in your application, please comment out or remove the following line of code
            // For more information, refer to: https://www.asp.net/web-api
            config.EnableSystemDiagnosticsTracing();
            config.DependencyResolver = new ResolveController();
        }
    }
}

Notice the highlighted statement where we’re telling the Web API infrastructure which DI implementation to use. Rest of the code remains unchanged.

So now we’ve completed all the steps that are required to provide a simple implementation of inbuilt DI framework in a Web API service. Now you may build and run the service in the IIS Express host that comes with the IDE. If you set a breakpoint in GetService method and invoke the service from web browser such as below:

https://<host>:<protocol>/api/SensorReading

You should hit the breakpoint in GetService method which proves that our DI implementation is working as expected! On completion of the call, you should get a JSON string or HTML based on the default accept-header of the browser you’re working with.

And that’s it for now! In the next series of articles, I’ll demonstrate how to write a WPF client, a Windows Phone 8 client, Windows Store client and unit testing strategies to go along this approach.

NOTE: The application shown in this example is part of the code that I wrote for Continuous Delivery Release Pipeline with TFS project (by Microsoft Patterns and Practices team).

Next in Series –>Writing BDD style unit tests to verify the MVC based Web API