Question

According to J. Likness on page 166 of "Building Windows 8 Apps with C# and XAML," in speaking of the OnResuming event: "The main reason [for this event ] is for applications that provide timely data to refresh their information."

I have one page in my app that has such data; so, if the user has resumed the app, and he explicitly returns or is implicitly/automatically returned to that page (assuming he was on that page when the app was suspended), I want to refresh the data. But how do I know that my app was suspended/resumed?

My idea is to set a bool that the data-rich page can interrogate in its OnNavigatedTo() event; if it is true, I will refresh the data. Is there a better way to do this, and perhaps more importantly: is the OnNavigatedTo() event fired if the user was on that page, the app was suspended, and then resumed? Or does the app view the page as never having been left, and thus it is not being navigated back to? Perhaps another page-level event would be more appropriate?

Was it helpful?

Solution

I'd say you need to determine what the threshold is for when the page of interest needs to be refreshed; I don't think it's as simple as a Boolean. A user could suspend and pretty much immediately resume (say within 15 seconds) and that may not merit a refresh, but that same user could also linger on secondary page, never suspend, and come back to a page 30 minutes later, in which case the page data could be quite stale. Your Boolean may need to be more of a timestamp.

That said, the Resuming event does not fire OnNavigatedTo. If you need to know what page you're coming back to, you'd need to save that info when you suspend, perhaps in LocalSettings. But now consider that if you're using SuspensionManager in C#/XAML, that is already happening on your behalf, and if you think about it, the behavior you want is not too different (if at all) from what should occur when the application comes back from a terminated state.

So in a similar fashion, you could add a call

await SuspensionManager.RestoreAsync()

as your implementation of the Resuming event. That would, in turn, cause an OnNavigatedTo and you'd run through the normal logic of bringing up that page.

It's technically not resuming anymore, you're just using the resuming event to trigger the reload of the entire page. That could be overkill depending on the nature of the page (e.g., maybe there's a lot of semi-static data and only a tiny bit of volatile data - resuming doesn't need to restore the static data). You may want to dial back how much is refreshed on a 'resume' versus a 'terminate,' but since SuspensionManager is code you can see and change, so you can control that level of granularity. And maybe it's here that you introduce you're idea of the Boolean to differentiate what needs to be done in LoadStateAsync when it's invoked by Resuming versus by other means.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top