Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Single Process Background Tasks Are Great — Now I Want a Time Machine

DZone's Guide to

Single Process Background Tasks Are Great — Now I Want a Time Machine

Here are a few of Matt Lacey's observations about background processing that could really help you out in the long run.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

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.

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
development ,dependency ,uwp ,mobile

Published at DZone with permission of Matt Lacey, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}