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...)
Related
using stackdriver's url monitoring.
When it goes down, one time will come but the next will not come.
I would like you to repeatedly notify this if the situation does not change in the next 5 minutes, but I do not know the setting.
somebody help!
https://i.stack.imgur.com/eLROH.png
I'm a product manager with Stackdriver. This is a feature request that we have heard before and are aware of.
This is, unfortunately, not supported at this time, though there are some workarounds:
PagerDuty can be used as a notification channel, and PagerDuty supports repeated notifications.
Webhook can be used as a notification channel, which can be used to create a fully custom delivery mechanism (including one that delivers repeatedly).
Sorry that this isn't available more simply. Hope this helps.
I just want to find out music from my service is currently playing or not? Usually for our Android or iOS client we used to send a heart beat (ping) to service to notify client is alive, how can implement the same in SONOS. I've tried with getLastUpdate by setting pollinterval but it seems it is getting called only when my controller is in foreground.
Thanks in Advance.
We have several reporting methods that should help you accomplish this kind of reporting. reportPlaySeconds (http://musicpartners.sonos.com/node/388) is probably your best bet, as it will tell you how long a listener was listening to a track (and thus that playback is occurring) and allow you to set the interval at which this is reported back to you. In the future, reportPlayStatus (http://musicpartners.sonos.com/node/389) should also be able to help you track playback (although currently this is only reporting on skip events).
I have an application where I need to create local notifications via polling without doing push - primarily due to client infrastructure limitations and their security model.
I've read: http://www.objc.io/issue-5/multitasking.html, I've seen David Chan's WWDC presentation - where single push messages kick off download tasks - but what I truly need is background fetch - on a regular basis - like every ten minutes - in iOS 7.
I've seen the VOIP hacks. No. What non-hack way is there to do this without user interaction or push messages? Any examples you can point me to?
Here's what I know:
Background data tasks will work in the debugger but if you can get a console on an IPA, you'll quickly find out they really are prohibited (thereby invalidated many examples).
Background URL tasks require custom delegates - but fetch completion handlers are iffy. This too I found with an IPA and console.
I would love to avoid using the AFNetworking lib - for something quite simple.
Background fetch is not a reliable solution - you are at the mercy of the OS, and it is not very merciful. Abusing iOS background modes is not a reliable solution - Apple is known to reject applications that enable background modes, such as location, VOIP and music playback, without a legitimate reason. Background URL tasks are not something you can rely upon to wake your app; they will wake it, but the app will not be awake enough in the background to enqueue a background URL task.
Your best and most intended method is still background fetch, but be prepared to be disappointed. Your app will not be woken app in the interval you need. Also, the user can kill the app in the app switcher screen, causing your app to never wake up until opened.
No real reliable method other than push. You need to insist with your client for the sake of user experience.
Unfortunately there is no "reliable" way to do that on iOS. With the background fetch API you are not guaranteed to have process run when you would like it run. As you've said, you've already looked at the API so i'm probably telling you something that you already know. A local notification wouldn't solve your issue either as this isn't a way that you can wake your application up and kick off network events. This is behavior that Apple doesn't want as this would negate the whole purpose of their background task coalescing.
You really need to have a push mechanism in place for something like this, so if this is something that is needed, then you may have to stress that to the client.
Microsoft Exchange introduced Streaming notifications as an alternative to pull/push notifications with Exchange 2010. Basic introduction on streaming can be found on this msdn article and blog
However, I cant figure out the actual advantage of streaming over push notifications.
The only advantage mentioned in the blog is "..and you don’t have to create a listener application as for the push notifications." Apart from that, are there any other advantages and disadvantages?
How do other factors like managing the subscription, re-subscription logic, scalability, max num of subscriptions, etc compare over push? Also, Streaming subscription has a maximum alive time of 30 mins and I would have to re-subscribe every 30 mins? Isnt that a disadvantage for a large number of subscriptions(my application has to manage 20K+ mailboxes)?
Any light on the comparison factors would be helpful.
The main reason for Streaming Notifications (SNs) is Exchange Online. You can't have EOL opening up an HTTP connection to an application potentially behind a firewall. Even within a corporate network there are firewall issues. I've had several cases where my app could not get Push Notifications (PNs) because of the firewall on its own server.
On the surface SNs would also seem to be more efficient because each notification is not opening up its own TCP connection, but rather they flow in on a single pipe. After doing some Wiresharking on this, I'm not really convinced this is so because it seems like under the covers they're doing Long Polling, so each notification coming in will cause a new HTTP call back up to Exchange.
The 30 minute max is no big deal, just reopen the connection in the handler and you're done--you don't have to actually re-subscribe. In fact, I am of the opinion that I want to lower that even more to say 3 minutes. You apparently cannot add new subscriptions or remove old ones except within the disconnect handler. (Try it, and you get errors.)
And yes, you don't have to code an HTTP handler, which is nice I guess.
I have a Web-Service application, i need to send scheduled GET methods to my server and if a change has happened with my incoming data i have to inform my user about the changes. When my app is in the foreground(in min thread) i fetch some data and pıpulate my tableview, my problem is, i can't realize how to create a scheduled method to the same data source(mean server) and if a new thing has been added, either my app is on bacground or not, inform user(alert) about the changes. Can anyone please share any idea-link.. Thanks in advance
This is exactly what push notifications were designed for, and are, technically the best way to solve the problem.
It does mean the task of 'checking' for new data is shifted to your server but the user is better suited as a push notification will happen, even if your app is not running.
I recommend using a system like Urban Airship.