To wrap up this Q&A series and following from yesterday’s Live Tiles Q&A, I have a few more specifically related to toasts. Do note that half of yesterday’s post applies to tiles and toasts equally, specifically those parts related to WNS.

 

Question: Do scheduled toasts work in Connected Standby mode?

Answer: Yes. Typically an app that wants this behavior also needs to be lock screen-capable, and the user will need to add that app to their list of lock screen apps through PC Settings.

 

Question: Is it possible to set the background color of the toast to be different from apps default background color?

Answer: No, the toast background color is tied to the app’s tile background color. This is an aspect of branding so that users can visually see where the notification is coming from. This is one reason why apps cannot access the current system color scheme, otherwise they’d be able to spoof system notifications.

 

Question: I’ve found that is my server sends more than 7 toast notifications only the first 7 will actually appear. Is this a known limitation? Can it be modified on a per app basis?

Answer: Only three toasts can be displayed on the screen at once, and there is a fixed limit on the number of toasts that will be queued for later display. These are per-user limits, shared between apps. An app cannot increase it’s own limit. If there is need to show more information from an app, consider aggregating those notifications such that fewer needs to be send.

 

Question: Can I configure locally-issued toasts to only appear when my app is in the background?

Answer: Not directly, as the toast API doesn’t have such an option. You’ll need to monitor your app’s visibility state directly and suppress notifications when you’re visible.

 

Question: Is it possible for a desktop app (full trust) to suppress notifications like the user can do through PC Settings?

Answer: Toast Notifications will be dropped if the QUNS state is QUNS_PRESENTATION_MODE or QUNS_RUNNING_D3D_FULL_SCREEN. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb762533(v=vs.85).aspx.


Following from yesterday's Store Q&A, I have another collection for live tiles. Note that WNS here refers to the Windows Push Notification Service.

Question: The code sample on Quickstart: Sending a push notification is written in C# but says C++ in the title. How do I do this in C++?

Answer: This code on MSDN is meant to be used from a ASP.NET web service, not an app, hence being written in C#. All that you need to do from an app is post a channel URI to that service, then the service uses the code in PostToWns whenever it needs to send an XML payload to that channel. Presumably this service is running all the time, so push notifications happen regardless of whether the app is running at all. Posting to WNS from an app is generally unnecessary, as a running all can just send the XML update to the appropriate WinRT API to have it show up on the tile or toast as needed. Going to WNS would be a very roundabout way to accomplish the same thing. If you'd like your service to trigger push notifications to other devices, then you'll need a service endpoint for that purpose. Windows Azure Mobile Services makes this much simpler; see Alive with Activity, Part 3: Push notifications and Windows Azure Mobile Services on the Windows Developer Blog.

Question: How do I test the different scaled images for my tiles, such as those in my manifest?

Answer: Scaling goes into effect on devices with different pixel densities (dpi), which is a different concern from screen size. A 1920×1200 screen (like my 15.7” laptop screen or my 24” desktop monitor) are 96dpi devices so Windows employs a 100% scaling. If, however, I had the same resolution on a smaller screen, like the 10.6” on a Surface Pro, then Windows will employ 140% scaling, and then use alternate graphics. You can test your scaled images in the Visual Studio simulator or through Blend’s device tab. In the latter, for instance, you’ll see that the different options indicate the scaling %’s in effect:

6-6 (Blend resolutions)

See Guidelines for scaling to screens and Guidelines for scaling to pixel densities for the differences between screen resolution and DPI considerations.  

 

Question: I've read your book's Chapter 16 [13 in the first edition] with the sample HelloTiles web service to support live tiles. Is there a step-by-step guide to creating a web service in Visual Studio? I'm new to the services scene.

Answer: The main thing is to first understand how the backend in your chosen language gets at the data it needs. In PHP, you might be accessing a MySQL database, which would be very common. In that case, you could try starting at http://www.sitepoint.com/publishing-mysql-data-web/. That would show how to extract the data you want, then it’s a question of wrapping that up into the XML payload.

All this really means is using the PHP echo function to output the XML with the values of variables inserted. The samples that these pages show are outputting HTML, but you’d simply be outputting the XML instead. You can then extend the service by allowing URL parameters, for which you’re use parse_url in PHP to get at the individual components (see http://php.net/manual/en/function.parse-url.php). You can then feed those parameters into your database queries to customize what’s being returned.

Those URL parameters would simply be part of what the client app includes in the URL it gives to Windows for periodic tile updates…Windows will just send a request to that URL. If that’s your PHP page, then your code executes, you process the parameters, run the query, then emit the XML as output (the request response). If it’s properly formatted, you’ll then see the tile update. In ASP.NET you’re pretty much doing the same thing, just in another language, e.g. querying a SQL Server database but again emitting the XML as the “page” that you’re server-side code is generating. You can find many tutorials on http://www.asp.net/get-started, such as http://www.asp.net/web-pages/tutorials/data/5-working-with-data.

Again, these tutorials as going to show creating a web page response (HTML), but you’ll just be emitting the XML instead. Generally speaking, Visual Studio is better set up for ASP.NET/WebMatrix than it is PHP. WebMatrix was designed to be a closer analog to PHP than the full ASP.NET (where you basically never see the HTML or XML output). Also, Windows Azure Mobile Services will be making it easy to create an endpoint without having to spin up a whole service of your own.  Keep an eye on that.

 

Question: Can I use a push notification to reset a live tile previously updated with a push notification, other than just waiting for it to expire?

Answer: Not really. There's not a general purpose "reset" with WNS. One thing you can try is to send your real notifications with a particular tag (X-WNS-TAG), then send another one later with the same tag and a very short expiration time. However, there's no guarantee that the update will go through, so it's not foolproof. In the end, it's probably better to come up with some other interesting content as a generic tile update that would serve as your "clear".  

Question: How do I set an expiration time for a push notification?

Answer: Calculate the number of seconds that you want the update to live from the time you post to WNS. Include that value in the X-WNS-TTL header.  

Question: I understand that WNS does guarantee deliver of push notifications. How often will WNS attempt delivery of cached messages when messages have the X-WNS-Cache-Policy set?

Answer: See http://msdn.microsoft.com/en-us/library/windows/apps/hh465435.aspx#pncodes_x_wns_cache.Cached notifications will be delivered automatically when the device next comes online. They may be dropped by the server after a few days if the device is not seen.

Question: Does WNS support multicasting a single push notification to multiple device endpoints?

Answer: WNS doesn't offer this directly, no. Toolkits built on WNS can offer such capabilities. however.

Question: How do I handle expiration of an OAuth token for push notifications? To be specific http://msdn.microsoft.com/en-us/library/windows/apps/hh465435.aspx says, "An access token is returned in the HTTP response if the cloud service successfully authenticated. This access token can be used in notification requests until it expires." How does one detect the expiration – the response shown in doc doesn’t include expiry or a refresh token. Will the POST to WNS return a 403 or some other code and then I need to reissue request for a new access token? What’s the recommended approach for handling the scenario in code?

Answer: The recommended approach is to store an access token and push notifications using that access token until an error code is returned.  At that point, the app service should reauthenticate with WNS and request a new access token for pushing notifications (again using that token until an error code is returned). The documentation states that WNS uses the 401 error code to indicate that an access token has expired.        


In relation to my series of posts, Alive with Activity, on the Windows 8 Developer Blog (part 1 is there, part 2 will be posted today, and part 3 is in production), I’ve been working some with Windows Azure Mobile Services and am increasingly impressed with what’s being offered here. You owe it to yourself to learn something about them.

As you’ll see in parts 2 and 3 of that devblog post, Mobile Services, which I abbreviate as AMS and which is also referred to as ZUMO (aZUre MObile service), setting up push notifications is really a snap with this technology. That is, if you go through the list of things you have to do to support push notifications, there’s quite a bit on the service-end of things (as part 3 will describe), and these are many of the details that AMS takes care of for you.

The two primary tasks for push notifications are:

  • Sending channel URIs to the service: this step becomes far easier with AMS. Instead of sending HTTP requests that you have to build up yourself, you instead create a database table in the mobile service (through the Windows Azure portal) and simply insert a record into that table with the channel URI and any other key information you need to attach to it. The AMS client library takes care of the HTTP request behind the scenes, and even updates the client-side record with any changes made on the server. Furthermore, AMS can automatically handle authentication through the user’s Microsoft Account or through three other OAuth providers—Facebook, Twitter, or Google—if that you’ve registered your app with one of them. See Get started with authentication in Mobile Services.
  • Sending notification: in the raw, you have to send HTTP requests to the channel URIs used with push notification. With AMS< you can attach scripts (written in the variant of JavaScript known as Node.js) to database operations, and also created scheduled jobs in JavaScript. In these scripts, a simple call to the push.wns object with a channel URI and a payload generates the necessary HTTP request to the channel. It’s also a simple matter to capture push failures and record the response with console.log. Those logs are easily reviewed on the Windows Azure portal.

Now instead of spoiling the fun of my devblog posts where push notifications are concerned, here are other capabilities of AMS that you will want to know about.

  • The ability to authenticate the service with OAuth providers is very cool. Just as you can use OAuth providers to authenticate a user in a Windows Store app (using the Web Authentication Broker), you can also use that same provider on your service back-end. This means that having access to a unique user identity is pretty simple and straightforward, allowing you to manage per-user data in the service.
  • AMS builds on SQL Server databases hosted on Azure. Those databases are just like any other online SQL Server instance and can be accessed in the same way. This means that you can have other services, apps, web sites, etc., all talking to the same database that the Mobile Services part uses. This allows you to use that database as a central gathering point for data that you’d use for things like periodic and push notifications (OK–that’s a spoiler for Part 2…).
  • Whether or not you need push notifications in an app, the client library gives you a very easy way to save records to a database table and have any server-side modifications reflected back in the client. You can, of course, just read, delete, and update those records as well. In other words, the table-management capabilities in AMS can be used by themselves just for data management, which is super-cool. Even more so is the dynamic scheming capability with the database, meaning that you can just add columns (properties) as you need without having to separately manage the database tables.
  • You can easily do paging of data from the database, e.g. having your app only acquire so many records at once.
  • The scheduled jobs feature of mobile services lets you run code on your server whenever, for whatever purpose. You’re just setting up these jobs with little bits of JavaScript, so it’s not like you have to learn everything about server-side programming.
  • AMS works with Windows Store apps, yes, but also Windows Phone, iOS, and basically anything else that can talk to a service. Don’t think of AMS as just a Windows thing.
  • You can use AMS to send emails from the server.
  • AMS also provides mechanisms for managing server-based storage, e.g. for uploading images and other data from an app. You can use the Background Transfer APIs in WinRT to do this directly, but it means writing a service that can deal with those data streams. AMS does that for you, and employs the background transfer APIs on the client side.

And from what I hear, the story will get better in the months ahead when new features are added.

In short, it’s worth spending a few hours just looking through the AMS docs on http://www.windowsazure.com/en-us/develop/mobile/resources/#header-1. I think you’ll be pleased at what you find. ANd check back in every few months to see what’s new.

By the way, if you’ve read this and find yourself a little nervous about all this “service” stuff that takes you away from the concerns of client apps, let me say that I really do understand! Learning about HTTP, etc, well, I didn’t want to touch services for a long time, as it can be a very different world than writing apps. However, in the process of writing Chapter 13 of my book, I really didn’t have a choice. Because no one, to my knowledge, had put up a sample service to work with tiles, toasts, and badges (the Windows 8 SDK only has client-side samples), I took the plunge. Having done so, I have to say I’m really enjoying learning about this space, not just with Azure, which is very cool, but boning up more on ASP.NET, refreshing my PHP (in which I’ve worked a little), checking out Node/node.js (for writing servers), learning about the whole world of web APIs (see http://programmableweb.com), and thinking about how to use services creatively in apps.

And now that I’ve been looking into AMS, what’s so very cool about it is that you don’t have to deal with all that HTTP stuff at all!

So don’t be that afraid of it (I’m still a little iffy on OAuth…but that’ll come!). Take it a little at a time, and I’m hoping my devblog posts will help you bridge to that space as well.

 


Working with tiles, badges, and toast notifications is a wonderful way to have your app surface information to the user when it’s not in the foreground or not running at all. Because of this, however, it can be difficult to debug updates or notifications that aren’t working. If there’s something wrong with the XML or the contents of an update, then it might not display at all, which can be difficult to figure out. So I wanted to offer a number of things you can do or check when you encounter problems.

First, consider something like the following scheduled XML payload for a toast notification:

<toast><visual><binding template=”ToastImageAndText04″>
<image id=”1″ src=”ms-appdata:///local/some_image_created_dynamically.png” />
<text id=”1″>Some text 1</text><text id=”2″>Some text 2</text><text id=”3″>Some text 3</text>
</binding></visual></toast>

Let say you’ve called the necessary APIs to get this up, but it doesn’t appear at the appropriate time. Why? For one, consult the troubleshooting guide that’s found in the docs. But let me add to that some.

For one thing, the XML could be malformed–Windows will reject any tile, badge, or toast where the elements inside <binding> don’t match the template indicated in binding.template. To compare, run the App tiles and badges sample and go to Scenario 5. This is less of a sample and more of tool that lets you generate tile updates, where you can then see the resulting XML. It’s also worth pointing out that the XML text should always be UTF-8 encoded (contrary to the troubleshooting guide’s statement about UTF-16, which is a doc bug). I’ve also found that Windows is somewhat picky about extra line feeds at the top of the XML.

For scheduled notifications, check to make sure that you’re actually scheduling a time in the future. See the Scheduled notifications sample for reference.

Next, be sure that any image.src property is a valid URI, for one, but also make sure that the target image is 1024×1024 or smaller, and 200KB in size or smaller. Windows will not display larger images. In the example above, the overall toast will still appear, but it will have a blank image if Windows can’t find the image file or if the image is too large. In general, a blank image shows up when there is some problem loading that image.

You can also use the event log. In the event viewer, navigate to Application and Services Logs > Microsoft > Windows > Apps > Microsoft-Windows-TWinUI > Operational tile where tile activity takes place. Note that you need to click on the Details tab to see which app was involved as the General tab doesn’t show that.

Speaking of the event viewer, note also that Application and Services Logs > Microsoft > Windows > PushNotifications-Platform > Operational has additional events about push notifications.

For push notifications in particular, it’s absolutely essential that the package ID in your manifest exactly matches what you have in the Windows Store. Using the Store > Associate App with the Store command in Visual Studio will make sure of this.