I am (still) working on a WIn8-UI-App (previously called Metro...) and I implemented Periodic Tile Updates. (Also with your help, see this post.)
I have two follow-up questions:
How can I set an expiration date for periodic tiles? As written in the documentation I have to provide a X-WNS-Expires header of the notification's HTTP response message. The message is the XML-(tile)-file. How can I add the expiration date (example)?
While I was reading a couple tutorials and the documentation, I read that the notification service (the abonnement which renews the tiles) never expires. In a sample code (by MS) I read that it expires after 30 days and I should renew it whenever the app is launched and that I should consider using a background task. What is right now and what should I do for my app that might get only used once every two months (but the notification tiles have to be on the whole time)?
Thank you for your help!
The endpoint that you specify for the periodic notification needs to serve the XML content and set the X-WNS-Expires header (and perhaps X-WNS-Tag). If, for example, you're using Windows Azure blob storage or Amazon S3 to host the template XML and sending that URI to startPeriodicUpdate, then you don't have the opportunity to set those headers. You'll need to set up a lightweight service that passes through the XML content and sets the headers appropriately.
The 30-days refers to a push notification channel, not the periodic notification registration, which is just a URI that's polled on whatever interval you specify. That URI will be checked until you call stopPeriodicUpdate; see Periodic Notification Overview:
Polling continues until you explicitly stop it or your app is uninstalled. Otherwise, Windows will continue to poll for updates to your tile or badge even if your app is never launched again.
Lastly, the Guidelines and checklist for periodic notifications does recommend:
Call the StartPeriodicUpdate or StartPeriodicUpdateBatch method each time your app is launched or brought into focus. This ensures that the tile content will be updated each time the user launches or switches to the app.
Related
We've recently started adding programmed radio to our existing SMAPI implementation. I've followed the Sonos Developer documentation and (eventually) got it working as expected. I'm just seeking for some clarification around the 'auto updating' based on the 'queueVersion' value.
Our schedules which are feeding the programmed radio can change from time to time. These changes should be reflected on the Sonos Players as soon as possible. For what I understand this should be possible by modifying the queueVersion property in both GET /context, GET /itemWindow and GET /version.
Looking at the GET /version documentation I see that Players "[...] are responsible for periodically polling this [QueueVersion] value to detect changes in the cloud queue track list, [...]".
I've monitored our API logs for about 15 minutes in which I would expect at least a GET /version request, but none showed up. The only calls I'm seeing are POST /timePlayed.
Can anyone (from the Sonos team perhaps?) clarify what this interval is set to, or how it can be controlled?
Given that you aren't seeing GET /version requests, there may be an error in your configuration.
The player sends a GET /version request every 5 minutes when paused and every 10 minutes when playing. This is by design, not depending on any setting that you can control. However, players fetch new tracks as needed using GET /itemWindow. The player requires a version in your response, so it doesn't send a GET /version request in this case. After the player gets a new item window, it resets the polling interval to another 10 minutes.
See the Play audio (cloud queue) page for details.
Hello I am trying to create a simple push-notification system similar to this common use case:
1. The user gets a chest and can either watch an ad to skip the wait time or wait one hours for the chest to open. The app sends an upstream request which sets up a downstream push notification that shall be delivered in one hour to let the user know the chest is ready.
2a. The user then waits an hour, gets a push notification (outside of the app) to open their chest and they do!
or
2b. They wait 20 minutes then decide to watch the ad. The app sends an upstream request which cancels the pending push notification which would have otherwise been delivered in 40 minutes.
Okay awesome so that is the problem and I am having a hard time understanding how to do this. I have looked over the documentation for each of these programs but they seem designed for downstream push notifications. It just seems odd there is no built-in support for this use case. It seems like such a common use case.
I so far found 3 solutions that will integrate into my cross-platform Unity setup and provide services for free or super-cheap:
Amazon Simple Notification Service (SNS)
Google Firebase Cloud Messaging (FCM)
OneSignal
Amazon seems to group clients into "Topics" so I guess I would be setting up a one-device-topic and essentially. I can subscribe and unsubscribe from them but it doesn't seem to support a topic with a 60 minute delay.
2a. Create a topic: https://docs.aws.amazon.com/sns/latest/dg/sns-tutorial-create-topic.html (it would just include the current device)
2b. Subscribe to it
2c. Send a message to it https://docs.aws.amazon.com/sns/latest/dg/sns-tutorial-publish-message-with-attributes.html
So basically I can add attributes to my message but it would seem I need to implement the server-side code to read a delay attribute then somehow queue a message for delay. Maybe I am missing something?
For Firebase I pretty much see the same thing as Amazon. There are topics https://firebase.google.com/docs/cloud-messaging/android/topic-messaging and a means to send upstream messages https://firebase.google.com/docs/cloud-messaging/android/send-with-console but with the messages I don't see anyway here to get the time delay https://firebase.google.com/docs/cloud-messaging/unity/topic-messaging I see conditions towards the bottom of that article but I don't know if it is meant for this use case.
OneSignal has the easiest to scroll-through API. I'll refer to some strings that you can CTRL-F by using the format ("Create Notif") because everything is on this one page: https://documentation.onesignal.com/reference
So basically I can ("Send to Specific Devices") which I guess would be the sending device, then I can ("Schedule notification for future delivery.") using the send_after parameter. And finally, if need be, I can ("Cancel notification"). So this appears to be everything I need. I'm currently looking at this option and trying to figure out how to actually get this working.
So there is my progress over the last few hours researching each of these options. I am hoping you can help me better understand how I may be misunderstanding the above options as this seems to me a very common use-case. Perhaps I am just not googling the question correctly. Any help appreciated.
Whenever there's a likelihood that you'll need to cancel a significant percent of the notifications you send, you should use local notifications. That way you can easily schedule and cancel them locally without making any network requests. Also, this solution works for offline devices which is great for games (played on planes, etc...)
RFC 5277 defines notification replay support. Just wondering what customer problems this notification replay can solve? What could be the need to scan through list of past notifications? At any point of time, controllers can always fire "get" RPC and determine current state.
Any inputs on this are appreciated.
Notification replay is mostly required to sync NETCONF clients with servers without the need to do a full RPC.
In some systems, the configuration + operational data becomes quite large, so the notification replay allows for a delta sync.
The main problem with this is that the server will only keep a limited time window of notifications; so if a client asks for a replay of the last week, the server may be only able to provide a subset of that.
RESTCONF has a different solution for this same issue, the last-modified header field(https://www.rfc-editor.org/rfc/rfc8040#section-3.4.1.1), which allows for doing a get of 'data that has changed since timestamp x'.
I need to pass messages between a WP8 app and a Windows Store app. It's sort of a "peer-to-peer" situation in that they will both send and respond to messages from each other, but it's also sort of a "client/server" situation in that the Windows Store app will have 1..N WP8 apps that it is conversing with.
After being beaten about the head and shoulders for my first ideas of trying to use either email or SkyDrive rather sneakily, I'm now considering these possible architectures:
1) Direct Push Notifications
(a) The WP8 app sends Push Notifications to the Windows Store app via a URI it is provided after this conversation takes place:
Windows Store app: "Will you send me updates?"
WP8 app: "Yes."
Windows Store app: "Okay, here's where to send them."
(b) Windows 8 responds to the arriving msgs.
2) Push-Pull using the Cloud
(a) WP8 sends data to the cloud (Azure?)
(b) Windows 8 app periodically polls for it
3) SSL (Using components from someone like /NSoftware (IP*Works))
The messages from WP8 are rather frequent (every 15 minutes, on average), but small/short (short enough to be a Tweet, in fact). The Windows 8 app deals with these msgs "behind the scenes." The user is not aware of them until he runs the associated app.
There weren't any question marks :) but here's my take:
Push notifications would certainly work, but given your "behind the scenes" comment, you may want to look specifically into "raw notifications", which do use the push notification mechanism but aren't associated with UI (like a tile, toast or badge). Pushed toast notifications, for instance, are dropped if the client if off-line.
The frequency of the messages makes me leery of the polling approach given impact on battery life (that said, not sure how a push notification with background task would compare). With the polling approach too you'd need to have some way on your "cloud service" to maintain messages (storage) and then feed back the right messages on each poll, etc. You'd also need to handle the scaling and availability aspects that WNS would do 'free.' Not rocket science, but more work. The push notification is kind of 'fire-and-forget'.
With sockets, you might have more control to the extent the sandboxed model exposes functionality you need. It seems like more moving parts though, and I'd likely go that route only if the other two approaches are otherwise unviable.
I am working on a Win8-UI-App (previously called Metro...) and trying to implement Periodic (Documentation for different methods) Tile Updates (Live Tiles) for the first time.
I found a couple of very good resources on the internet and was able to do it. Unfortunately the question of where I should register for the notifications remained unsolved:
Do I have to register for Notifications every time the app starts (e.g. in the App.xaml.cs OnLaunched() Method)? - Or is there an other, more professional way to do so? (I could imagine to save if I already registered for the service or is there a variable I can access to see whether notifications are registered?)
thank you!
PS: For everyone who is also new to this see this StackOverflow post, this example, the tile template types and the Dev Center for quick starting :)
Periodic updates will continue until they are explicitly stopped or your app is uninstalled. Technically, you only have to do that once. But, the Guidelines and checklist for periodic updates states
Call the StartPeriodicUpdate or StartPeriodicUpdateBatch method each
time your app is launched or brought into focus. This ensures that the
tile content will be updated each time the user launches or switches
to the app.
According to that, App launch and App resume are good candidates for a call to StartPeriodicUpdate.