Single process background tasks are great - now I want a time machine #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

On many occasions in the past, I've made lots of apps that required a level of background processing.
These were typically done by having a second project in a solution that contained a class which implemented an interface to operate as a background task.
Having the task in a separate library often led to architectural issues around how the code was divided up for sharing between the different projects for the app and the task. The juggling of code structuring and dependency issues was also further complicated when functionality necessitating a background task is added to an existing project (or one nearing the end of original development.)
It's not just the division of code that was an issue. Having the app and background task (or tasks!) communicate or share information was also an issue. Managing MutExs, locking and shared files wasn't the hardest thing in the world but it always felt like more work than should have been necessary.

All that should be a thing of the past now though as the Anniversary Update introduced single process background tasks.

A few observations that may help you:

• The docs on MSDN seem incomplete but it really is VERY simple.
• See the background audio sample for the best guidance.
• You don't need to make a declaration in the package manifest to use this.
• A network state change trigger is easy to repeatedly invoke during testing (even when not under debug) - just toggle flight mode
• The `LeavingBackground` event is also fired when the app starts.
• The `EnteringBackground` event is also fired when the app closes.

As the title suggests, I wish this was around years ago. It would have saved me a lot of time and effort.