Session 396 - Using Tiles and Notifications

Question

I missed the original presentation last week, and just watched the recording now. Unfortunately, there wasn't any recorded Q&A.

First, regarding the 30 day URI expiration for WNS push notifications, I think this could prove very problematic for some apps. For example, an anti-malware product settings app may not be opened frequently, causing the tile notifications to time out. If this tile showed active/updated information about the anti-malware product, it would appear to freeze. Also, some apps are "report-only" users create a "widget" tile. For example, a weather app that shows local conditions in the tile would expire if it wasn't opened. Is there any way to address this, or are we depending on the user to touch our app?

Second, I assume push notifications are per-user? We can, therefore update tile information on a per-user basis?

Answer 1

Hi Rob - I'll check into your questions and let you know what I find out.

---

Matt Small - Microsoft Escalation Engineer - Forum Moderator

Answer 2

Tiles are not meant to be widgets - app developers should not create apps with the expectation that they're never launched.

Push Notifications are per-user, per-machine. For example if your windows live ID was a user on a laptop and desktop machine, then notifications would be pushed to each independently.

Answer 3

To add to Brendan's point - the Windows Push Notification channels are per-user. Specifically, they are per-user account on the machine. This is independent of how the user logged in (i.e. it doesn't matter if the user is using their Windows Live ID to log in or a standard user account). Since the channels are per-user, you can send different notifications to individual users.

It's also important to note that Windows doesn't force you to use our concept of a 'user' - your application can map your own concept of a user to your channels. For example, assume users log into your application with a username/password. When your app creates a channel for that username, you can store that channel on your app service associated with that specific username. If the user has a second machine where they're using your app, you can store the second channel associated with the same username. It doesn't matter if those two users logged into Windows with different Windows user accounts.

HTH,

Kevin

Answer 4

Whilst I see the point about app developers wanting there app to be launched (and I'm sure we'd all love users to spend all day in our apps!), the behaviour is going to be mostly confusing for users when one of their tiles stops updating for (what to them) appears to be no reason. The only course of action from a developers point of view seems to be to either not make your tile particularly useful (thus forcing the user to launch your app) or sending a "You need to run this app again to get future updates" WNS message if the URI is about to expire. Forcing users to periodically launch and then quit an application just to get the behaviour they want seems flawed.

Couldn't there be some system managed way of extending the URI timeout for tiles that are still in use by the user? That way users can still recieve the updates they want, even for applications that might not require them to always launch the full version.

Answer 5

I guess I'm less concerned about what was meant vs. what can be done with tiles. I'm highly unlikely to open my weather tile on a regular basis, since all of the information I want is already in the tile. In fact, the tile would be really useful if it had active content showing the forecast for the next 5 days on different pages. In that case, most users would never open the app, and the tile would eventually "die".

Please take this thread as constructive feedback and consider providing us with an option to renew our URI in a different manner. There are many kinds of apps that won't be regularly opened but still have active content (like anti-malware).

Answer 6

Rob & Andy,

This is great feedback - I appreciate it. I definitely see your point on this and we'll look into addressing it.

Thanks,

Kevin