Tech in the 603, The Granite State Hacker

C# and WebAssembly

I’m honored to be able to post in Matt GrovesAnnual C# Advent again this year, and today… December 22nd, 2018, is my second year contributing to it.

Last year I talked about ways to unload the main UI thread in WPF/.NET apps.

This year, I want to call attention to the Uno Platform tools I’ve been evangelizing for the past six months or so. 

Silverlight is dead – Long Live Uno Platform!

To understand this perspective, we’ll need to walk through some key terms….

What is Silverlight?silverlight

For those who don’t know, about ten years ago, Silverlight was the way to write C# and XAML to run in the web browser. It required a plug-in to run, much like Adobe Flash Player. Unfortunately, Microsoft announced the…. untimely demise of Silverlight in 2012. Silverlight, to some extent, seemed a more catchy term than other related technology names, so Microsoft used Silverlight as the name for mobile platforms that are also now depricated. As a result, it became almost synonymous with XAML.

What is XAML?

XAML, “eXtensible Application Markup Language” is the markup language behind a few great UI / UX layers in various Microsoft .NET-oid languages.  For those who’ve used it, it’s an addictively cool language family.  Using Visual Studio, Blend, and Adobe DX, you can create first-class UI.  With features like Storyboard animation, basic animation becomes child’s play. Composition makes fast, dynamic animations easy. Once you’ve gotten the basic idea of it, one finds themselves wanting to use it anywhere they can…  or at least that’s been my experience through WPF, Silverlight, Silverlight for Windows Phone, Silverlight for Windows Phone 8 / 8.1, Universal Windows Platform (UWP) and probably others.

The “code behind” XAML is typically C#, and historically .NET based.

What is Universal Windows Platform (UWP)?

UWP is the native platform of Windows 10.  It’s similar to classic .NET in a few ways.  First, UWP feels a lot like Windows Presentation Foundation (WPF) and .NET, being XAML and C# based, respectively.  It differs from classic .NET because it has a lot of fixes, both in terms of security and performance, that .NET can’t afford to apply for various reasons.  More simply put, .NET had some serious technical debt built up, so the easiest way to forgive that debt was to build a new platform based on the old languages.  Your XAML and C# skills are the same, but the namespaces and supporting framework libraries are different.

Don’t fret, though…  UWP runs natively on over 800 million devices (as of today, December 22nd, 2018), and that number continues to grow.  UWP is the native platform for all Windows 10 devices.  This means desktops, laptops, tablets, phones, HoloLenses, Xbox consoles, IoT embedded devices, and more. 

What is WebAssembly?webassembly

WebAssembly is a relatively new bytecode language specification… a virtual machine specification, similar to the Java Virtual Machine (JVM), that is fully supported by most modern major web browsers.  It allows near native performance in the same sandbox that javascript apps run in.  When you run javascript in a web page, the jit compiler in the browser converts the code into tokenized bytecode in order to execute it quicker.  WebAssembly improves on this significantly by pre-compiling the code.  Because the code is pre-complied, it doesn’t have to be sourced from javascript.  It can be compiled from just about any programming language.  Wasm, as it’s called, went from a specification just a few short years ago to being well supported in all major modern web browsers.

What is Uno Platform?uno platform

Uno Platform, for our purposes, is not really a new platform, but an extension to UWP. 

You write your UWP application for your Windows 10 devices the same way you always have.  Uno provides a mechanism to re-compile that UWP app to Web Assembly (and… by the way… using Xamarin tools, also to iOS… and also to Android!)

In a sense, Uno Platform is to UWP as Xamarin is (roughly) to classic .NET.

See the connection? 

Let’s do some math…

UWP = C# & XAML for Windows 10.  (800,000,000 devices)

Uno Platform += UWP for iOS (Millions more devices), Android (over a Billion devices), and WebAssembly (every modern major PC in the world)

Now factor in this…

.NET Core 3 += UWP for services

What does all that add up to? 

One skill set… 

UWP (C# & XAML) = FULL STACK, on all major platforms

From data access layer to REST API to UI canvas.

Wait a minute…  What about Xamarin?

Xamarin is the older way to do C# for cross platform / mobile.  

Coincidentally, just this past Thursday, Carl Barton, a Microsoft MVP for Xamarin presented the Xamarin Forms Challenge at the Windows Platform App Devs users group. The goal of the meetup was to demonstrate creating a simple app in C# and running it on as many platforms as we could in the hour.  He easily pushed ran the app on over a dozen platforms in the hour.

Uno Platform actually depends on Xamarin libraries to support iOS and Android. 

The main differences between Xamarin and Uno Platform are these:

  • Xamarin encourages you to use a Xamarin-specific dialect of XAML, including Xamarin Forms to express your cross platform UI.
  • If you already know & understand Microsoft’s UWP dialect of XAML, Uno Platform uses that dialect.
  • Xamarin enables you to produce binaries for dozens of different target platforms, reaching a billion or more devices.  These include .NET, UWP, iOS, Android, Tizen, Unity, ASP.NET, and many others.
  • Uno Platform only enables you to reach three additional binary output targets…  iOS, Android, and WebAssembly…. but WebAssembly can or likely will soon cover most of what Xamarin Forms covers.

I’ll leave it up to you which to choose, but for me, given the choice between Xamarin with several years of technical debt built up in a distinct dialect of XAML, and Uno Platform, using the fresher, native UWP dialect of XAML…  

Finally… 

Here’s the slides I presented most recently at the New England Microsoft Developers meetup in Burlington, Mass on December 6th (thanks again to Mathieu Filion of nventive for much of the content):

[office src=”https://onedrive.live.com/embed?cid=90A564D76FC99F8F&resid=90A564D76FC99F8F%211297452&authkey=AM6QZrb_6-9ltdE&em=2″ width=”402″ height=”327″]

Tech in the 603, The Granite State Hacker

v.Next Enterprise (You & Kroger)

krogerI ran across this article from Forbes on LinkedIn.  It’s an interesting bit about how Kroger is reacting to the threat that Amazon/Whole Foods suddenly represents in its market segment.

https://www.forbes.com/sites/andyswan/2018/08/14/kroger-fighting-back-amazon-whole-foods/#543edd285ce6

The Amazon/Whole Foods merger represents a heavily modernized re-make of a traditional business, and it is expected to put grave pressure on the rest of the grocery segment.

If your market segment isn’t feeling this kind of pressure already, you likely will be soon.

Your business has only a couple of choices when it comes to modernization.

  1. React to the pressure that your market segment is under already.
  2. Begin preemptively, and be the pressure the rest of your market segment feels going forward.

I remember the days of building “nextgen” software.  That model has scoped up a few times, to vNext services, to next gen infrastructure / cloud, to vNext IT division.

Either way, it’s time to start developing your company’s “nextgen enterprise” strategy.

 

 

Tech in the 603, The Granite State Hacker

Welcome to the new home of The Granite State Hacker Blog

Welcome!  As many folks know, I love helping community members develop their coding careers.

Years ago, I started co-organizing events to reach out to community for the purpose.  Eventually, we had a situation where we needed to support banking to managed money for these events.  I was already running two users groups, and helping organize several “Saturday” events a year.

Rather than create a “SharePoint Saturday New Hampshire LLC”, it made sense to economize on scale, and create an entity to support the users groups and events that I’m already an organizer for…  and so “Granite State Users Groups, LLC” was born.

More recently, I’ve taken on roles beyond treasurer for things like Granite State Code Camp 2018, and so it occurred to me that if we’re going to pay for a website, we might as well economize on scale again…. and so granitestateusersgroups.org now exists.

And while I’m at it, why not make it a blog site for community members that want to blog…. and I’ll conflate it with my own “The Granite State Hacker” blog to start.

So here we are.  Welcome!

I’ll continue to post about coding in the Microsoft tools stack, here. I’ll also continue to post about coding-community related events and goings on in the “Greater 603” area (which may also cover events I’m attending or presenting at…  and by that definition, “Greater 603” as a region may cover all of North America at some point or another.)

Here’s the direct link:
https://granitestateusersgroups.org/category/the-granite-state-hacker/

Enjoy!

Tech in the 603, The Granite State Hacker

Intro to Uno Platform

Uno’s free.  Uno is open-source.  Uno could seriously be the next significant disruption in mobile development.

Apologies that I neglected to hit on the conference call for the introductions.  We did get the bulk of the presentation recorded.

On the call:  Jerome Laban, Architect, and Francois Tanguay, CEO of nventive of Montreal, Quebec, Canada. Participants of the Windows Platform App Devs (including myself) were in the audience, asking questions.

To make up for the intro missed in the call, let me begin with the elephant in the room…

What’s “wrong” with Xamarin?

The relatively well known Microsoft tool set called Xamarin enables developers to write a dialect of C# and Xaml to target a variety of platforms including Windows, Windows Mobile, iOS, Android, MacOS and others.

For that reason, Xamarin’s currently a top choice for mobile developers around the world. Xamarin enables developers to target billions of devices.

The problem Xamarin presents is that Xamarin has become its own distinct dialect of .NET-based development.  Xamarin has its own distinct presentation layer called Xamarin Forms. Xamarin Forms as an employee skill set is not the same as a classic Windows developer set.  It’s not exactly the same as a Windows 10 developer skill set.  It’s a different platform, and requires developers that understand it.

Uno Platform reduces the skillset burden in this problem by converging the main skill set on Windows 10 development. Developers with an appreciation for the future of Windows development will definitely appreciate Uno Platform.

Windows Universal Platform (UWP) targets ALL flavors of Windows 10, including some unexpected ones, like Xbox One, and IoT devices running Windows 10 IoT Core.

Uno bridges UWP to iOS, Android, Web Assembly (Wasm), on top of Windows 10. This targets a huge and rapidly growing range of devices… (currently approaching around 3 BILLION… and that might be a low estimate.)

I’d embed the video, but Blogger’s giving me a hard time with the iframe-based embed code… please click this

Link to the video:

Intro to Uno Platform Skype conference recording.

The meetup:
Granite State Windows Platform App Devs
https://www.meetup.com/Granite-State-NH-WPDev/events/251284215/

Uno Platform’s site:
http://platform.uno

Tech in the 603, The Granite State Hacker

QnAMaker Went Live – Bot in a Day

There were lots of exciting things to come out of Build 2018 in early May this year.

Among the many detail level items was qnamaker.ai came out of beta.

As many folks know, I’ve been hosting Bot in a Day Workshops at various Microsoft Technology Centers (MTCs) in the northeast.

With qnamaker.ai going live, came some changes, including a migration from the beta portal to the Azure Portal.

The general instructions for migrating your QnAMaker knowledgebases can be found here:
https://aka.ms/qnamaker-docs-migrate

Unfortunately, you’ll quickly discover that with that change, there’s a breaking change in code that requires _more_ than just upgrading nuget packages.  (You must update all your nuget packages… in fact, be careful, because some of the new dependencies are out of date… so keep updating until everything is flush)

In the live era of QnAMaker, you must also contact the correct host.

After you’ve re-published your migrated knowledgebase in the live environment, you’ll see the familiar deployment details.  Among them will be one new detail, that host name:

This changes what you have to pass in to the constructor for the QnAMakerService in your code.

The way the Bot in a Day Workshop lab sets up configuration is via web.config.  In your bot project, you’ll need to add a new configuration key to the configuration/appSettings section of the file.

Once you’ve done that, you’ll need to provide the parameter to the constructor of the  QnAMakerService…  see the example below.

https://gist.github.com/GraniteStateHacker/a8d86f28a9bbc86c3c249c173e499643.js

Tech in the 603, The Granite State Hacker

Global Azure Bootcamp 2018 – Manchester, NH, United States

THANK YOU!

Global Azure Bootcamp 2018, held at over 280 locations around the world on Saturday, April 21st, 2018 is in the books.

These are exciting times.  When Microsoft airs commercials that point out that “there is more computing power at your fingertips than in past generations”, I think that’s a severe understatement.  There’s more computing power at your fingertips today than there has ever been, over the cumulative course of human history.

Further, Microsoft has never been more clear about their commitment to Azure, to the point of burying Windows within their own organization.  It’s not that Windows is gone, it’s that Windows is merely a client to Azure, and their new organization structure reflects this.

I was mostly focused on the Granite State event location, and had my hands full with that… though I did assist the Burlington / Boston event as well, especially getting local sponsorship in the form of custom t-shirts from Insight/BlueMetal.

Thanks so much to all the folks who contributed to make it happen… Peter Lamonica of Manchester Community College for making the facilities available to us…   Carl Barton, Xamarin MVP, Roman Jaquez, Patty Tompkins, Marie Patrick in the Granite State (New Hampshire) community for presenting, and Patrick El-Azem, Dave Stampfli, Bret Swedeen, and Gino Filicetti from Microsoft itself, for presenting, and taking the content up a notch.  All helped organize the event.

The event really was perfect for the Granite State Users Groups, LLC, an organization I created several years ago specifically to enable users groups to plan events and manage their own resources in the process.

We shared a lot of learning!

Topics included

  • Azure 101
  • Azure Functions
  • Lift & Shift
  • App Services
  • Azure Resource Management
  • Azure Networking
  • Bot Framework
  • Cognitive Services
  • Azure DevTest Labs
  • SQL on Azure
  • Azure IoT Hub
All of the support from Global Azure Bootcamp central made some of the harder parts easy… in particular setting up lunch, and providing sponsorship for things like $300 Azure passes and the like.
In retrospect, we had a few minor misses:
  • We didn’t print up schedules for everyone, which was a mistake.  We had enough to effectively share, but should have just printed out a copy for everyone.
  • We had coffee, but it didn’t arrive till near end of day.
  • We didn’t take enough photos. 🙂

Azure Passes!

Manchester Community College floor plan

Jetbrains stickers

The “Go-kit” turned into a stack of boxes.

Custom event tshirts from BlueMetal/Insight

Our schedule, with some marked up for specific rooms

Locked & loaded early, ready to roll.

Schedule on display

Our 3rd classroom was a bit remote from the rest of the event.

Carl Barton presenting Azure Functions in session 1.

Panorama of Carl’s session

The school MPR in panorama, rolling with Patrick El-Azeem’s Azure 101, just one of several sessions rolling at the time.
Patrick El-Azeem presenting Azure 101
Tech in the 603, The Granite State Hacker

Locking Resources in C# for Read/Write Concurrency

In a previous project, I became a big fan of System.Threading.ReaderWriterLockSlim.  It was an excellent way to guard a resource against concurrency in a relatively flexible manner.  

C# has a lock(object) {} syntax for simple concurrency locks, but what if you have a resource that can sometimes be used concurrently, and other times, exclusively?

Enter System.Threading.ReaderWriterLockSlim.  This has a few handy methods on it for guarding code on a non-exclusive (Read) and exclusive (Write) mode, with an upgradeable lock, as well, so you don’t have to release a read lock in order to upgrade it.

This source works just as well in .NET as UWP.

I commented the code enough to try to make it so that someone familiar with ReaderWriterLockSlim and using(IDisposable){} would understand the rest, so without further ado…

https://gist.github.com/GraniteStateHacker/e608eecce2cb3dba0dbf4363b00e941f.js

Tech in the 603, The Granite State Hacker

Unloading the UI Thread in C# on Windows 10 + UWP

First I want to thank Matthew Groves for hosting the 1st known C# Advent (English).  I was honored to be able to grab the spot for Friday, December 22, 2017, which, happily, is the start of my Christmas holiday week, as well.

The crux of this post is that most visible performance issues in a Windows application come from the presentation layer.  Specifically, anything that puts load or wait states on the main “UI Thread” will make the app/application appear to hang or become unresponsive for periods of time. This post talks about strategies for getting load off the UI as much as possible, beyond the async/await mechanism in C#.  Most such load can be unloaded to a worker thread fairly easily.  Other tasks can be awaited together. In some cases, a UI component is involved, and it becomes necessary to manage load that, for that reason, reason MUST stay on the UI thread.

I remember when I was a kid hearing of projects for stock traders that handled hundreds of data update events every second and being totally intimidated by the thought of it.  I knew I’d “come of age” in technology when, in 2017, I worked with a focused team (known as “Blockheads”) to build such an app.  This latest generation “stock blotter” ran stable, without memory leakage, and with no apparent lag at tens of Gigabytes per second! These general ideas stem back to the project I worked on in 2016-2017 with BlueMetal for Fidelity Investments’ Equity Trading team, called Artis OMT.  Artis OMT has been on Fidelity’s Equity Trading floor for over a year now, and will soon reach a year of full deployment.  While Artis OMT was WPF, this post looks at similar performance ideas in a similar but different platform:  Windows 10 UWP (store apps).

Artis OMT didn’t start out able to handle 90Gigabytes of incoming data.  We had to use JetBrains tools to identify code that was bogging down or hanging the main UI thread.   That analysis, alone, is perhaps the subject of a different post, or more, some day.

When folks start thinking about UI Thread execution, the first thing most think of is Dispatcher.BeginInvoke().  This method is how you add workload to the UI thread.  I’m trying to talk about how to UNLOAD the UI thread, and/or manage your load so that the user won’t observe UI freezes or lockups.

Here, however, are a few relatively easy ways to really make use of the extra cores in your CPU, and make your apps appear to perform much better:


Task.Run(() => { … });

Classic depiction of processes running in sequence vs in parallel


The title of this says it all, really.  Push a workload off the current thread.  Use whenever you have long running processes that you don’t have to touch UI controls from.   If you have timing dependencies, you can manage them with Task.When, Task,Wait, or even better, Task.ContinueWith().  Examples below cover this a little more.



Batch remote service calls using Tasks and WhenAll()

Service calls are low hanging fruit.  So often I see code that makes calls in series, waiting on the results of one before making the next call, even though the two calls have no dependencies on each other…  it’s just so much easier to write the sequence case that folks let it hang.   await Task.WhenAll(…) is not as syntactically sweet, but still MUCH sweeter than having to set up an aggregate event.

///

/// Does one request at a time, holding up the entire process
/// at each step until it completes. Simpler code but….
/// Total time spent is the sum of all tasks’ time.
///
public async void GetContentinSequence(Session session)
{
    var dbContent = awaitGetDatabaseContent(session);
    var webContent = await GetWebContent(session);
    var userProfile = await GetUserProfile(session);
    var userContext = await GetUserContext(session);
}


///

/// Executes all requests simultaneously, letting the default task dispatcher do its thing.
/// total time spent is no more than the longest running individual task, all other things being equal.
///
public async void GetContentinParallel(Session session)
{
    var contextTask = GetDatabaseContent(session);
    var webContentTask = GetWebContent(session);
    var userProfileTask = GetUserProfile(session);
    var userContextTask = GetUserProfile(session);
    var stuff = new Task[] { contextTask, webContentTask, userProfileTask, userContextTask };
    await Task.WhenAll(stuff);
    var dbContent = contextTask.Result;
    var webContent = webContentTask.Result;
    var userProfile = userProfileTask.Result;
    var userContext = userContextTask.Result;
}

Here’s an example that makes this more clear:

var start = DateTimeOffset.Now;

var task1 = Task.Run(async () => { awaitTask.Delay(1000); });
var task2 = Task.Run(async () => { awaitTask.Delay(1500); }); //1.5 seconds
var task3 = Task.Run(async () => { await Task.Delay(1000); });
var task4 = Task.Run(async () => { awaitTask.Delay(1000); });
var tasks = new Task[] { task1, task2, task3, task4 };
Task.WhenAll(tasks).ContinueWith(t => { Debug.WriteLine(DateTimeOffset.Now – start); });



outputs something like:
00:00:01.5623681

As always, there’s some overhead with task switching.  You’ll notice that the time was just a few ticks longer than 1.5 seconds.

What if you can’t unload the UI thread?  what if your long running process must interact with controls like a huge grid that needs to calculate an aggregation of a data set that lives in it?   
Here’s an option…


DoEvents() erhhh… ummm…  await Task.Delay(…)

I once scrubbed references to Visual Basic from my CV and landed a job that had scrubbed VB from the job description.  I didn’t want to work for a company that would hire a “VB-Weenie” and they didn’t want to hire a “VB-Weenie”, either… but there was VB6 work to do. 

One thing that VB6 had going for it was a concept called DoEvents().   It enabled you to give up processing the current method to allow any pending events to execute. It would then return to finish the calling method.

In C#, the closest equivalent, nowadays, is “await Task.Yield()” or await.Task.Delay(…).

Most folks talk about using “await Task.Yield()” at the start of an awaitable method to make sure the whole method runs asynchronously.  There’s some sense to that.   More importantly, one can interrupt long running processes that must run on the UI in order to allow the UI to respond to user inputs.  In testing, I’ve seen that Task.Yield() often doesn’t allow enough room for redraws of the UI.  Likewise, setting a Task.Delay of a 1 tick timespan isn’t enough, either.  1 millisecond delay, however, does seem to suffice in my basic testing.

private async void LongRunningAggregatorOnUIThread(object sender, object e)

{

    await Task.Yield();
    timer.Stop();
    var timeoutRate = TimeSpan.FromMilliseconds(100);

    
    var timeout = DateTimeOffset.Now.Add(timeoutRate);
    var value = 0L;
    while (true)
    {
        value++;
        if (DateTimeOffset.Now >= timeout)
        {
            textbox.Text = value.ToString();
            await Task.Delay(1);
            timeout = DateTimeOffset.Now.Add(timeoutRate);
        }
    };
}



As always, use this very carefully.  This has overhead of its own, as well, that can cause performance issues…. including potential deadlocks.

Tech in the 603, The Granite State Hacker

Windows 10 IoT Core, C# & Azure IoT Hub for New England Microsoft Developers 12/7/2017

Just wanted to say thanks for inviting me to reprise my Boston Code Camp 28 presentation for the group last night (12/7).   I enjoy talking about development anywhere in the Microsoft stack, and I love that Windows 10 IoT Core + Azure IoT Hub spans a good range of it.  I have a bunch of other topics I’d be happy to share, especially in the Windows 10 domain. Check through this blog, I have a post for each that shares slides, but I know the presentation’s a big part of the value of them.

These slides are really only a tweak of the BOSCC28 slides with the NEMD group title. [office src=”https://onedrive.live.com/embed?cid=90A564D76FC99F8F&resid=90A564D76FC99F8F%211283616&authkey=AH0Ai1kfUL_6WKE&em=2&wdAr=1.7777777777777776″]

Tech in the 603, The Granite State Hacker

MVP IoT with Windows 10, C#, Raspberry Pi and Azure IoT Hub

Boston Code Camp 28 is in the books as one of the greatest community events of recent times in my book.  Attendance was fantastic, we had amazing sponsors, and a ton of great speakers, but the thing that really made things hop was attendance.  I’m personally convinced it was the best attended Code Camp I’ve ever participated in.
As a presenter, I don’t often get to attend as many of the amazing presentations as I’d like, but yesterday I found myself especially regretting that… there was just so much great content from so many great presenters. I did manage to get into more sessions than I usually do… how could I not?

Sure, you get a few “look at this cool stuff I can do” presentations.  These are great for folks looking for inspiration on the tough challenges.  I love the spirit of “look at this cool stuff you can do (if you apply your skills in a modestly different direction)”.
This is why I do this MVP IoT presentation.  This presentation is about taking skills you already know and love (namely C# development) and applying them to what’s classically though of as “embedded” development.  Yes, there’s overhead in this approach…  you might have to use hardware that’s slightly better equipped to handle Windows 10 IoT Core such as the Raspberry Pi 2b & 3b… but the difference is mute at small scale, and masked at large scale by not having to have a separate team with different skills. 

IoT apps on the Windows 10 IoT Core platform ARE Windows 10 apps.


The point I always try to drive home is IoT apps on the Windows 10 IoT Core platform ARE Windows 10 apps.  The very same exe you compile for your embedded device runs just as well on laptop, desktop, server, Windows 10 phone, et al.

I do regret the couple snags I had during my demos.  Still, someone approached me after the presentation with the idea that I should pre-record portions of my presentation in order to avoid these kinds of things.  I like to run live for several real reasons.  1)  I’m a coder, not a professional presenter… I don’t often have time to polish my presentations to that level.  2)  Glossing over rough edges hides what development is.  Development is tough.  You have to have backup plans and contingencies.  My Raspberry Pi didn’t want to connect to the guest WiFi, so I fell back to plan B, and moved on.  It’s a real world scenario;  you hit a snag, but keep pressing on.

IoT is already about the last mile of the Sci-fi story, bringing Internet omnipotence to the fringes of reality, enabling the “Computer” of Star Trek (or the Cortana of the modern desktop) to reach it’s potential (hopefully without becoming Skynet).

It’s the stuff of science fiction… but it’s not fiction.

Visual Studio 2017’s ability to debug into a remote embedded device and make hot changes to a running executable is beyond top notch; it’s the stuff of science fiction… but it’s not fiction.

[office src=”https://onedrive.live.com/embed?cid=90A564D76FC99F8F&resid=90A564D76FC99F8F%211283217&authkey=AKQG9LbQcNcUSkk&em=2&wdAr=1.7777777777777776″]

If you look through my post history, you’ll see how this presentation has evolved over the past decade.  It’s been an interesting evolution…  starting with connecting Windows Phone 7 to SharePoint.  Then Windows Phone 8 and SharePoint online (and the story got really muddy for a bit there).  Then CSOM hit and smoothed out the SharePoint side of things.  I changed the story to Field Enablement using Xamarin for iOS, Android, and Windows Phone with SharePoint as a back end for a bit. (It’s a surprisingly compelling story, even if it’s only academic).  Eventually I started focusing on UWP for Windows 10, and my love of small form factor development drew me back to Raspberry Pi. 
Finally, I’ved bridged off of SharePoint and started talking about Azure IoT Hub, which is the modern accepted best practice in the domain of this development stack.  This change happened so relatively quickly that if you notice, the synopsis for the session didn’t mention it.  (  https://www.bostoncodecamp.com/CC28/sessions/details/16540 )

One can explore the code I developed for the demo at git hub, here:
That leads me to my final bit:  I am sorry I ran out of time in my presentation.  I was so psyched to show how to send telemetry back to Azure IoT Hub, and while I got to step through the code that sends updated reports, I did not get to explore any of what that looks like in the Azure IoT Hub portal, and didn’t get to explore the event-driven API on the embedded side that allows you to send code with Device Twin down to a the device.
Here’s the event that commits the post:

        private async void iotHubButton_Click(object sender, RoutedEventArgs e)

{

try

{

using (var client = DeviceClient.CreateFromConnectionString(

$"HostName=BOSCC-IOTHub.azure-devices.net;DeviceId=GraniteStHacker;SharedAccessKey={Credentials.LuisAccessKeyFromAzurePortal}",

TransportType.Mqtt))

{

var twinProperties = new TwinCollection();

twinProperties["MeasuredTemperature"] = manager.MeasuredTemperature;

twinProperties["HeaterPowerOn"] = manager.HeaterPowerOn;

twinProperties["ACPowerOn"] = manager.ACPowerOn;

twinProperties["Device_BOSCC"] = DateTime.Now.ToString();

await client.UpdateReportedPropertiesAsync(twinProperties);

Console.WriteLine("Done");

}

}

catch(Exception ex)

{

Console.WriteLine(ex);

}

}

}


Click the image below to see the device I was using for the demo in Azure IoT Hub’s Device Twin view.

Here’s the resulting Device Twin JSON:
{
  “deviceId”: “GraniteStHacker”,
  “etag”: “AAAAAAAAAAE=”,
  “version”: 8,
  “status”: “enabled”,
  “statusUpdateTime”: “0001-01-01T00:00:00”,
  “connectionState”: “Disconnected”,
  “lastActivityTime”: “0001-01-01T00:00:00”,
  “cloudToDeviceMessageCount”: 0,
  “authenticationType”: “sas”,
  “x509Thumbprint”: {
    “primaryThumbprint”: null,
    “secondaryThumbprint”: null
  },
  “properties”: {
    “desired”: {
      “$metadata”: {
        “$lastUpdated”: “2017-11-14T01:48:45.8322179Z”
      },
      “$version”: 1
    },
    “reported”: {
      “MeasuredTemperature”: 74,
      “HeaterPowerOn”: true,
      “ACPowerOn”: false,
      “Device_BOSCC”: “11/18/2017 8:34:08 AM”,
      “$metadata”: {
        “$lastUpdated”: “2017-11-18T16:34:20.1258514Z”,
        “MeasuredTemperature”: {
          “$lastUpdated”: “2017-11-18T16:34:20.1258514Z”
        },
        “HeaterPowerOn”: {
          “$lastUpdated”: “2017-11-18T16:34:20.1258514Z”
        },
        “ACPowerOn”: {
          “$lastUpdated”: “2017-11-18T16:34:20.1258514Z”
        },
        “Device_BOSCC”: {
          “$lastUpdated”: “2017-11-18T16:34:20.1258514Z”
        }
      },
      “$version”: 7
    }
  }
}