I'm developing a Windows 10 application (UWP) which can send and receive notifications through a SignalR hub. Everything works perfectly and clients (an AngularJS webapp) are able to also send and receive notifications.
The problem is, when the UWP app goes to a suspended state (Windows Mobile goes to lock screen or whatever), the connection is lost (SignalR can't keep connection when app is not alive), and I lose ability to send/receive the notifications.
I would like to find a way to be able to send and receive notifications, even if the UWP app is not alive. I've heard about Notification Hub on Azure, but I don't know if it solves my issue and if it's possible to plug this into my AngularJS webapp.
EDIT May I prevent my app being suspended by Windows? My app looks like a turn by turn navigation service, so I would like not to be suspended or worse, terminated (even though, it seems I can't avoid this behavior when the OS needs memory).
You could use WNS/ Azure Notification Hubs to send a push notification to an individual authenticated user when your app is suspended. You will need to create a background task to do this. Your background task could send a message at an interval of 15 minutes or when it is waken up, by the toast notification.
Using Maintenance triggers
Send push notifications to authenticated users
With this you could receive notifications to your app while it is suspended.
Related
I want my app to be able to listen to onSnapshot while it is in background , I know that I can use background task for this by I don't know how to set it up .
btw I'm trying to implment this so that my app can push a notification whenever a new doc is received while app is in the background .
Most mobile operating systems severely limit what the app can do while it is backgrounded. Keeping an active connection open to a server is one of those things that has never been allowed on iOS, and has gotten more restrictive with recent Android versions.
The better approach is to run the code that detects a relevant change on a server, and then use Firebase Cloud Messaging (or APNS directly if you're only targeting iOS) to send a notification to the user. When they they tap on that notification, your app is started and you can load the data from Firestore.
If you don't want to run your own server, Cloud Functions is a common alternative for this, as it has built in triggers that respond to changes in Firestore. For an example of this exact scenario, see the documentation on notify users when something interesting happens.
I plan to create a business app that runs on iOS and communicates with a webservice. The app is meant to be an online app, but when there is no internet connection, the user should still be able to register a notification locally and the app should send the notification automatically (without further user intervention) as soon as there is an internet connection again. This should also work when the user closes the app while he has no internet connection.
Is it possible to do this on iOS? (I know it works on Android with a service)
Does this need a special permission ?
Thanks
Check out this developer guide section, specifically the part about local notifications in iOS and Android.
Notice that services can work in native code but the local notifications are portable.
I'm at the beginning of spec'ing out a project to implement browser notifications. From a high level it appears like it will be something similar to:
Create a service worker which subscribes to a pubsub topic.
Leverage the Notifications API and WindowClient to publish a browser notification when an event happens and the window is in a non-foreground state.
Seems, straightforward enough. However, I'm getting a bit hung up from a mobile perspective. Namely, it seems to be the typical pattern that if a mobile device has both the mobile website open and an application installed, the native notification should take precedence and the browser notification should be silenced.
However, I can't seem to figure out how a service worker would inspect for the presence of a mobile application. It is entirely possible that I'm approaching this problem from the wrong perspective though, and the typical recipe for this is handled differently.
Brent, IIUC your question is a non-issue because topic-based subscription is simply not supported by either the W3C Push API or the IETF webpush protocol. I'm afraid that this is by design :-(
Therefore your native app will not be delivered the same broadcast message as your browser UA.
If OTOH you were talking about save-to-homescreen WebApp and a web-page running in a tab then, I believe, your service worker can choose which member of the active client collection to foreground (if necessary) but there will only be one toast message (if at all given rules governing blind/invisible notifications)
OK, how do push notifications work?
I found a nice tutorial: http://lessons.runrev.com/m/4069/l/59312
I get the concept that the device needs to register with the server but does the app essentially hold an AJAX connection to server or does the server somehow plug into the mobile phone network... ?
There are three essential components when talking about push notifications:
Your server
The providers server
Your mobile device
Your server is the sender. It sends the push notification to the providers server, which in turn sends it to the device. Your device, therefore, is the receiver. (Concluding that you don't have to "plug into the mobile phone network", this is all done by your provider - Google in this case)
Within your mobile application you just register an eventhandler which is fired when you receive a push notification.
Google called this C2DM (Cloud to Device Messaging), now GCM (Google Cloud Messaging) - you can get an introduction inclusive of an architectural overview and demos here at android.com.
To answer your question I know:
Both push notifications services (Apple's and Microsoft's) are using a persistent IP connection for implementing their push notifications functionality.
I think Android works the same way (at least with Android Cloud to Device Messaging (C2DM)). "It uses an existing connection for Google services". http://en.wikipedia.org/wiki/Android_Cloud_to_Device_Messaging_Service
But the answer is closer to AJAX, except I assume it is a simple "http" connection to Google Messaging service from Android, and the OS gets an alert of a new message and relays it back to a program that registered on it to want notifications.
I am currently developing a C# Windows Form Application that I intend to let it interact with a server. The server will receive posting from a mobile application that I have developed and whenever a posting is received, my Windows Form Application should be notified and give me a notification.
E.g. My mobile application sends an posting over to my server. Once my server receives the message, my windows form application should display a new notification showing the content of the message received and updates the UI accordingly.
In this type of scenario, it is better to use duplex WCF service or the just the regular WCF service?
If duplex, mind explaining why do I need to use duplex service? Thanks!
A duplex service is a service where two channels are created.
The first channel is the ordinary client -> server channel using your service contract. This is what you'll find in every WCF service, and is how your client can send a request to the service and it can respond.
The second channel is a server -> client channel using a different service contract that you define. This second channel is how the server can send messages to the client without the client requesting them.
In your scenario, you seem to indicate that an event taking place on the server should send a message to your client. If this is the case, then yes, you need a duplex service so that the second channel exists, which allows the server to notify your client without the client initiating a request.
Working on the assumption that your Windows app and your server are one the same domain I would suggest you use a publish/subscribe pattern for this type of interaction. You could use something along the lines of the IDesign sample which is available on their website. Essentially your Windows app is subscribing to events which are generated by your mobile application sending a posting to your server. Your publisher will then push the event to your Windows application.
To accomplish this your connection to the server/publisher needs to be always open. This is best achieved with tcpBinding as it is bi-directional and allows you to set high timeouts (effectively infinity).
If you cannot use TCP then your job has become a little harder. Using a duplex channel is a little problematic because you have to monitor the channel as well, because neither side will notifiy the other if the channel closes. You will only find out when you try to use it. This can still happen with the TCP connection of course but its a bit more stable that using http.
The other alternative is to use MSMQ binding. This will guarantee the delivery of your message because you are interacting via MSMQ rather than a communication channel such as http or tcp. In this instance you wouldn't even need the pub/sub framework, you could just have the service that receives your mobile posting send on a message to the queue, which your Windows application is monitoring. The upside to using the framework is that you can have multiple applications listening for the same event.
HTH.