I wrote a previous (now out of date) post about the changes that come with implementing background tasks in Windows 10 Anniversary Edition here;
Windows 10 Anniversary Update Preview–Background Tasks
and some of that was based on the //build 2016 session here;
Universal Windows Application Lifecycle: From Activation and Suspension to Background Execution, Multitasking and Extended Execution
and that came before the official article that followed it came out on the Windows blog;
Background activity with the Single Process Model
which went into the full detail and I’ll admit that the last time that I read that document I skimmed some of the pieces that are titled;
“But first, the fundamentals”
and the reason that I skipped them was because I thought that I pretty much knew the fundamentals but, as is often the case, I was wrong and one of the reasons for that is that the fundamentals have changed and I revisited them in the meantime and Matt’s article the other day prompted me to write some of that up;
Single process background tasks are great – now I want a time machine
After the official article came out, I had to have a bit of a re-think around the EnteredBackground and LeavingBackground states that are now part of the app model and every UWP developer should familiarise themselves with how those events work because they have implications for how you do state management in an app.
I had a vague notion in my head around how these events worked but I hadn’t fleshed out the details properly and so in order to play a little with this, I wrote a little code to try and make an ‘app’ that watches various events in this lifecycle. Here’s the app running on my PC;
What app tries to do is to count (across instances) how many times it has been;
- Activations – how many times the App.OnActivated override has been called.
- Primary Tile Launches – how many times the app has been launched from the tile named “App”
- Known Secondary Tile Launches – how many times the app has been launched from a tile with an ID of “App2”
- Launched When Not Running – how many of those launches came when the app wasn’t previously running
- Launched When Running – as above but when the app was previously running
- Launched When Closed By User – as above but when the app was previously shut down nicely by the user
- Launched When Terminated – as above when the app was previously terminated by the OS
- Number of Unknown Secondary Tiles Seen – how many times was this app launched from a secondary tile that it didn’t create?
- Entered Background – count of the ‘entered background’ events
- Left Background – count of the ‘left background’ events
- Suspended – count of the suspended events
- Resumed – count of the resumed events
- Background Activations – count of calls to the App.OnBackgroundActivated override.
There’s also an indeterminate progress bar to see whether the app’s updating its display or not and 3 buttons (left to right);
- Registers a background task that fires when the time zone changes (Matt uses the network in his post, I used timezone here)
- Pins a secondary tile to the start screen with an ID of “App2” and a terrible icon.
- Unregisters the previously registered background task
In the screenshot above, I have launched the app from the primary tile (count 1) and it has been launched when it wasn’t running (count 1) and has left the background state (count 1).
- Does not contain any custom WinRT components – it’s all written with the Single Process Execution model.
- Does not contain any manifest references to background task declarations.
The one part of this app which is perhaps a bit weird is the idea that the app can be launched from a secondary tile that it hasn’t created. That’s one for another blog post but, in the meantime, I found this an interesting little app to play around with and so I’m sharing the code here if others want it (or want to fix it );
The code was written in a bit of a scramble so please apply a pinch of salt and unexpected results might be bugs! Also, forgive the naming of ‘App52’ in there