UWP

Changing the Start Up App on Windows 10 IoT Core

Changing the start up application on your IoT device running Windows IoT Core seems to be a common requirement once the device is out in the field so I hope this post exploring a few different ways of doing this will be of value to people.

To clarify the behaviour we will achieve below is from device power on our Windows 10 IoT Core operating system will boot up. But instead of starting the default application which is originally named ‘IoTCoreDefaultApp’ we will load our own custom created UWP app executable file. I will not talk about deploying your UWP app to the device, the assumption here is that has already been done and a complied .EXE file is living on the devices local storage.

Application & Package Name

Before diving into any changes it’s worth taking a moment to figure what our UWP application is called. This might seem obvious but depending on how you make this change (via the web portal or PowerShell) it’s referred to by different names. Both are configured in Visual Studio under the Package.AppxManifest and do not have to be the same. See below with screen shots from a new vanilla UWP project.

  • Firstly, the application name which is the friendly display name given to solution on creation and the EXE file presented in the settings web portal.

UWPAppName

 

  • Secondly, the package name which is the not so friendly value (defaulted as a GUID) is used as a prefix for the package family name. This is what PowerShell uses and needs to be exact.

UWPPackName

Assumed you’ve navigated that mine field and you know what your UWP app is called depending on the context where its used lets move on.

Headed vs Headless

Sorry, a tiny bit more detail to gain an appreciation of before we actually do this. Start up apps here can take 2x different forms; headed or headless. The difference between them is best thought of as running in the background or running in the foreground. With the foreground apps being visual via the devices display output.

  • Headed = foreground. Visible via display.
  • Headless = background. Not visible, like a Windows service. Also you have no head 🙂

Choose as required and be mindful that you can only have one of each running.

Web Portal

Ok, the easy way to make this change and make your app start up post OS boot: navigate to your devices IP address and authenticate against the web portal. Here in the Apps section you’ll find anything currently deployed to your Windows IoT Core system. Under the Startup field in the Apps table simply click the application you now want to start after the operating system has booted up using the Set as Default App link.

UWPPortalStartupAPP

At the point of making this selection the table content will refresh to reflect the change and the application will also start running.

You can now restart you device and your app will load without any further intervention.

PowerShell

Given the ease of the above why would you want to use PowerShell Paul? Well if you’ve got to do this on mass for 30x devices you’ll want to script things. Or, as I found out when Windows 10 IoT Core was still in preview for the Raspberry Pi 3 the App panel in the web portal above had a bug and just didn’t display anything!

Moving on, create yourself a remote management session to your IoT device. If your unfamiliar with doing this the IoT Dashboard can help. Check out my previous blog post Controlling Your Windows 10 IoT Core Device for guidance.

Within the remote management session you’ll need the command IoTStartUp. When using a new command for the first time I always like to add the help switch /? to check out what it can do.

Next work through the following commands in your PowerShell session.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
## 1.
## Review the list of apps currently available on your device.
IoTStartUp List
## If your expected app isn't there then it hasn't been deployed to the device.
 
## 2.
## Copy the package family name from the list or from Visual Studio if you still have it open.
 
## 3.
## Set the app as headed using the following command.
IoTStartUp Add Headed YOURAPPFAMILYNAME
 
## 4.
## To confirm which apps are now set for startup use:
IoTStartUp Startup

Here’s the same thing in a PowerShell window just to be clear.

UWPPowerShellStartupApp

Again to prove this you can now restart the device. From PowerShell use shutdown -r.

Restoring the Start Up Default

To change this back to the default application either repeat the above PowerShell steps for the package family name IoTCoreDefaultApp_1w720vyc4ccym!App or in the web portal set the app name IoTCoreDefaultApp as the default.

Many thanks for reading


Windows IoT UWP Tasks Tickers and Threading

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.

UWPRefManager

This limit includes the well known System.Threading and classes like the following example from MSDN.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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.

1
2
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:

  1. Send JSON messages containing your data to an Azure IoT Event Hub (Device to Cloud)
  2. 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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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


Paul’s Frog Blog

Paul is a Microsoft Data Platform MVP with 10+ years’ experience working with the complete on premises SQL Server stack in a variety of roles and industries. Now as the Business Intelligence Consultant at Purple Frog Systems has turned his keyboard to big data solutions in the Microsoft cloud. Specialising in Azure Data Lake Analytics, Azure Data Factory, Azure Stream Analytics, Event Hubs and IoT. Paul is also a STEM Ambassador for the networking education in schools’ programme, PASS chapter leader for the Microsoft Data Platform Group – Birmingham, SQL Bits, SQL Relay, SQL Saturday speaker and helper. Currently the Stack Overflow top user for Azure Data Factory. As well as very active member of the technical community.
Thanks for visiting.
@mrpaulandrew