Every Windows Phone Application Deserves a Tile (Part 3)
Join the DZone community and get the full member experience.Join For Free
my previous post about live tiles showed you how to update the back side of the application tile inside an application. the big drawback of this approach is that your tile will only be updated as a result of your application being executed. depending on the information you want to display on your tile, you might want to take another approach to update your application’s tiles.
this time we will make use of a background agent to periodically update the application tile without the need for the application to actually run. we again work on the same sample application, clicker , and extend its functionality by adding a periodictask . a periodictask is supposed to be lightweight and will run at fixed intervals. a periodictask will not run forever, but it expires after at most 14 days. from within the running application, the periodictask can be renewed before the expiration date. in this way, applications that are not used will not continue to use precious device resources through a periodictask forever.
back to our tile though. the scenario we want to implement is the following. the backside of the tile already displays the high score. it would be nice to alternate between showing the game’s high score and showing the amount of time the game has not been played. to implement this functionality, a periodictask is ideal.
in order to make use of a periodictask, a new project of type windows phone scheduled task agent must be added to the solution containing the clicker application. this newly created project already contains an oninvoke method that is called each time the periodictask executes. inside the oninvoke method, the back side of the live tile is updated. the periodictask will execute approximately once every 30 minutes. it is important to determine how data can be exchanged between the application and the periodictask. the periodictask has access to the application’s isolatedstorage . in clicker, a file is used to save the high score, which in turn is read by the periodictask. since the oninvoke method will execute on a thread and will be terminated after being executed, data needed for the periodictask must also be persisted in isolatedstorage. to store and retrieve high scores, a static class is available inside the clicker application. this class will be used in the application to store high scores. the same class will also be used in the periodictask to retrieve high scores. together with the high score, also a boolean variable is stored, indicating if the high score or an informational message should be stored on the back of the application tile.
the following code shows how the periodictask is created / renewed and scheduled to update the live tile of the application.
to make debugging easier, the periodictask will execute every 30 seconds in debug mode, instead of every 30 minutes. the other important piece of functionality is in the periodictask itself. the oninvoke method is started every 30 minutes (every 30 seconds in debug mode). it retrieves the information to be displayed on the back of the application tile.
at the end of the oninvoke method you will see a call to notifycomplete . this call is important because it releases resources of the periodictask. omitting to do this means the periodictask will not be rescheduled to run again after the specified interval in debug mode or after the fixed interval in release mode.
Opinions expressed by DZone contributors are their own.