Upon entering the IoT revolution a few things immediately became apparent;
- We now had the ability to collect and handle more sensor data than we’d ever before possibly conceived.
- These sensors and there data will/are going to change the very way we live… Not convinced by this one? Talk to anybody that has a Fitbit attached to their wrist about how many steps they do each day!
- More relevant to this article. The procedural tools we know and love like T-SQL and PowerShell are no longer going to be enough to deliver these new world real-time data requirements.
Moving on from the philosophy lets focus on my third point and the acceptance that we need to enter the realm of object orientated programming (OOP), specifically in the article C# .Net. Now I will state from the outset that I still consider myself to be a C# novice, but through IoT development the learning continues thick and fast. Although if you ask me directly to explain polymorphism I’ll still be running for Google 🙂
For procedural people already working with Microsoft products this learning and development can be fairly nice and sometimes even natural. However I expect people already involved in hard-core OOP software development and not very procedural this might seem a little backwards or just very obvious. Just a speculation at this point. At the moment I’m the former and if your reading this I hope you are too.
So why do we need OOP for our data? What’s your point Paul?
Well being a Microsoft aligned person more and more I find myself working on Windows 10 IoT Core with C# based on the Universal Windows Platform (UWP) framework to develop apps and drive my sensors collecting that very precious data. For those of you that haven’t encountered the UWP concept yet I recommend visiting these Microsoft pages: https://msdn.microsoft.com/en-gb/windows/uwp/get-started/whats-a-uwp
Assuming you are familiar with a little UWP dev lets continue and dive straight into the first problem you’ll encounter, or may have already encountered.
Threading
In reverse order to my article title I know, but threading is basically the issue that we first need to work around when developing an IoT application. The UWP framework is great and very flexible however it only offers a cut down version of the full fat .Net library (at present). Or to be more accurate when working with a UWP solution the number of SDK’s available in your references will be very limited compared to what you might normally see.
This limit includes the well known System.Threading and classes like the following example from MSDN.
using System;
using System.Threading;
public class MonitorSample
{
public static void Main(String[] args)
{
int result = 0;
Cell cell = new Cell( );
CellProd prod = new CellProd(cell, 20);
CellCons cons = new CellCons(cell, 20);
Thread producer = new Thread(new ThreadStart(prod.ThreadRun));
Thread consumer = new Thread(new ThreadStart(cons.ThreadRun));
producer.Start( );
consumer.Start( );
producer.Join( );
consumer.Join( );
Environment.ExitCode = result;
}
}
Threading is simply not available on the Universal Windows Platform.
Tasks
Enter our new friends async and await tasks or asynchronous programming.
using System;
using System.Threading.Tasks;
Now I’m not even going to try and give you a lesson on C# as I’d probably just embarrass myself, so instead I will again direct your attention to following MSDN pages:
https://msdn.microsoft.com/en-us/library/mt674882.aspx
However what I will do is try and to give you some context for using this new “threading” none blocking concept within your UWP IoT application. The example I like to call on is very simple. You have an IoT sensor device that needs to do two things:
- Send JSON messages containing your data to an Azure IoT Event Hub (Device to Cloud)
- Receive messages containing device management instructions (Cloud to Device)
These two fundamental bits of functionality have to happen asynchronously. We can’t be waiting around to send messages because we are working on what has just been received. To handle this we need something like the following example at the core of our UWP app.
namespace IoTSensor
{
public sealed partial class MainPage : Page
{
private MainViewModel doTo;
public MainPage()
{
this.InitializeComponent();
doTo = this.DataContext as MainViewModel;
Loaded += async (sender, args) =>
{
await doTo.SendDeviceToCloudMessagesAsync();
await doTo.ReceiveCloudToDeviceMessageAsync();
};
}
}
}
Now both send and receive can occur without any blocking behaviour.
Tickers
Lastly lets think about tickers created using something like DispatcherTimer(). The good old fashioned clock cycle if you prefer.
We might need a ticker to cycle/iterate over a block of code that is doing something with our IoT sensors. For example if you wanted to collect a temperature reading every 10 seconds. Using an async task with a ticker would be the way to achieve that. For example.
namespace IoTSensor
{
using System;
using System.Threading.Tasks;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using GHIElectronics.UWP.Shields;
public sealed partial class MainPage : Page
{
FEZHAT hat; //THANKS https://www.ghielectronics.com/
DispatcherTimer sensorCollection;
public MainPage()
{
this.InitializeComponent();
}
private async Task SetupDevice()
{
this.hat = await FEZHAT.CreateAsync();
this.sensorCollection = new DispatcherTimer();
this.sensorCollection.Interval = TimeSpan.FromSeconds(10);
this.sensorCollection.Tick += this.sensorCollection_Tick;
this.sensorCollection.Start();
}
private void sensorCollection_Tick(object sender, object e)
{
//Get values and send to cloud etc...
}
private async void Page_Loaded(object sender, RoutedEventArgs e)
{
await SetupDevice();
}
}
}
I do hope this high level article has been of some use. I will attempt to follow up with a more deep dive look at the above once I’ve slept on the concepts and forced myself to leave the beloved SQL behind for another couple of weeks while we voyage every further into the Internet of Things!
Many thanks for reading
