- Check if you need to refresh data from an online source that might have changed while the app was suspended.
- If you were offline when suspended, check whether connectivity exists on resuming, and switch into online mode. The opposite is also true, especially if the user got on an airplane while you were suspended.
- Refresh any sensor input that you’re tracking, such as the compass, orientation, or geolocation.
- Refresh the app’s layout, because it’s possible for the app to resume directly into a different view state than when it was suspended, even to a different resolution and scaling if the device has been connected to an external monitor, docking station, etc. (or disconnected from such). The user might also have gone to PC Settings > Ease of Access and toggled Make Everything On the Screen Bigger. You’ll also get focus, visibility, and sizing related events where you might do this work already, but in any case it’s a good case to test.
- Enable or disable app bar commands and other on-canvas controls that are dependent on clipboard contents.
- If you make a request to keep the screen on through Windows.System.Display.displayRequest.requestActive, then docs say to call requestRelease on the suspending event. This means that you would then call requestActive again on resuming.
- Check license status for trial apps and in-app purchases if you’re using expiration dates. See yesterday’s post on the licencechanged event. Here, if you’re suspended you won’t get the event; it might fire sometime after you resume, but I haven’t tested that specifically. In any case, resuming is a good time to check licenses in any case.
- If you’re using background tasks of any kind to update appdata, use resuming to refresh the app with that new state.
- Check if there’s new roaming appdata that appeared while the app was suspended. I believe that Windows will queue the Windows.Storage.ApplicationData.dataChanged event if this happens, in which case you could handle it that way, but I haven’t tested this to be sure.
- If you issue tile updates or toasts while the app is running (and aren’t using periodic or push notifications), think about whether to refresh those updates on resuming, including scheduled notifications.
- Refresh any push notifications channels if you’ve been suspended for some time, especially if any channel’s expirationTime has passed.
- If you perform data transfers that might be affected by cost-awareness on metered networks, use resuming to check the network type and respond accordingly. Note that transfers you set up using the Background Transfer API will work with this automatically while you’re suspended.
- If you’re accessing external devices using many of the Windows 8.1 APIs in Windows.Devices, you generally need to close those devices while suspending and them open them again on resuming. One exception are the APIs for point-of-service devices that have a distinct cooperative model through which you need to claim a device, and a claim is automatically released unless you explicitly retain it on suspend. If you don’t retain, however, then you’ll need to reclaim on resume.
In any case where you need to check how long the app was suspended, simply save a timestamp in the suspending event (Windows.UI.WebUI.WebUIApplication.onsuspending, WinJS.Application.oncheckpoint, Application.Suspending, or CoreApplication.Suspending), get another one upon resuming, and check the difference. Whether you take additional action depends on the nature of your data. An RSS feed, for example, might only go stale after a few hours or a day, but a geolocation reading or stock quote is pretty much immediately stale, in which case you’d always get new data on resuming.
In short, you really want to identify any external data or conditions that might affect your apps function, and how the data/conditions might change while an app is suspended. The resuming event is then there for you to know when to update the app accordingly.