I am implementing a webrtc app using twilio platform (for both ios and android). To be consistent with iOS 10, I need to integrate the CallKit which is activted in response to an external notificationn, such as a VoIP push notification. I was wondering which platform is better (e.g Amazon SNS, PubNub, Parse etc) would be better for implementing the push notification in back-end (I use node.js).
Note: I have seen some discussion/question regarding pubub vs SNS (e.g What is advantage and disadvantage of using pubnub over Amazon Simple Notification Service (sns)?). But those discussion are pretty old (3 years ago). In addition, they do not address/cover Callkit!
tl;dr - use OneSignal, stay away from SNS
I haven't tried pubNub, but implementing VoIP Push notifications with SNS in Node was pretty straightforward.
You need to pay close attention that you're signing the SNS platform application with the correct certificate.
Using the aws npm module was a breeze.
Two things I didn't like about SNS:
If SNS fails to send to an endpoint, it'll disable that endpoint,
which can make testing pretty frustrating. The same behavior happens
with normal push notifications as well. That can happen quite often
with QA devices, which undergo frequent factory resets, or where the
tested app is being repeatedly uninstalled/reinstalled.
Compared to other push notifications services, getting proper metrics from SNS is a real pain. Yes, you should be able to connect
SNS them to CloudWatch, but the result is very basic and years
behind the standards that other providers (like Parse or OneSignal)
have been offering for free.
UPDATE June 2018
OneSignal now supports VoIP Push notifications. I would definitely recommend using their services as they are free and are vastly superior to SNS.
Related
I've been researching different options for implementing messaging, specifically sending a message from the server to the client code, in React Native apps. I have found two main options: push notifications and in-app messages.
Push notifications can be implemented with services, such as Firebase and OneSignal, and work well except there is a claim that they are not very reliable and sometimes messages can get lost. The advantage of push notifications is that they work regardless of whether the app is in the foreground or background.
In-app messages can be implemented with event-bus services, such as SignalR (Azure or standalone), AWS SNS or GraphQL subscriptions. These services are pretty reliable, but this approach only works when the app is in the foreground.
However, there appears to be another option which doesn't seem to be as popular as the first two. This option involves running a native background service/process on the mobile device which participates in in-app message exchange similar to the normal in-app messaging. The background service would subscribe to SignalR or SNS or GraphQL and display a local notification on the device when it receives a message.
What are the problems with the last approach and why not prefer it over the hybrid approach (push notifications when app is in background but in-app messages when app is in foreground) which seems to be more commonly used?
Thanks!
The main limit is that mobile devices do not allow applications to keep a long-lived connection open in the background. This limit became more strongly enforced in Android 8 (Oreo) (documented here https://developer.android.com/about/versions/oreo/background#services), and this has always been true on iOS. Exceptions are made for certain VoIP applications, but generally, this rule applies to all apps.
One of the key reasons is battery life. Keeping a connection open takes a small amount of energy and if a user had dozens of apps like this, then it would be a noticeable issue. As a result, both Google and Apple have standardized around having a single connection open to the device that all notifications are delivered through.
For what it's worth, iOS notifications are actually very reliable and consistent. Android is more problematic due to modifications made by various OEMs. (documented here: https://dontkillmyapp.com/)
One workaround is that you could distribute an application outside of the Google Play Store that bypassed this limitation by requesting special permissions, however, it would still be affected by the OEM issues just like FCM is and likely worse.
I'm planning to add push notifications to my web app.
As far as I understand it, to push notifications to my users, I can either use a web push library and deliver the notifications directly, or use a push notification service such as OneSignal, Firebase Cloud Messaging, or Batch.com.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
If I'm focusing only on Web Push for now, is there any advantage I should be aware of, to use one of these services over a web push library directly?
Web Push is a standard which is still under development and subject to change. Also browser support is quite limited at the moment (see https://caniuse.com/#feat=push-api).
The advantage is: you have one API to rule all the supporting platforms (including desktop).
Disadvantage is: You have to be aware that not all platforms support the standard.
Using a notification SaaS solution to handle notifications enables you to handle all platforms. Sending out a notification from your backend will be a single call to your notification SaaS service, but you still have to be aware, when you want to have native notifications on Android, iOS and the browser, you will have to handle the integration of those platforms differently in your client apps (see example here using Google Cloud Message integration in an Android App: https://firebase.google.com/docs/cloud-messaging/android/client).
So your decision should be based on which platforms you have to support.
- If you get away with supporting Chrome, Firefox and Edge browsers on non-iOS-Devices (or handle iOS Notifications differently), you can use Web Push.
- Otherwise i would choose a Notification SaaS Solution.
The most important point for me personally when doing your own implementation is that you control everything. This means that your notifications don't fail when AWS loses a region or pricing changes and you can't afford it any more. Not any provider can ban you because of the content you distribute or the complaints from users. You can implement your own logic for showing the notifications on the front-end, like stacking them or having your own segmentation rules (paying users versus free tier, for instance). I'm not even speaking of the custom subscription UI. No weird copyright in your messages.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
When you've got the server logic to process the app events and send notifications in place, it shouldn't be really hard to extent it do work with mobile push notifications. The only thing that changes is the way you subscribe devices.
And the last, but not the least - it's fun to develop. This is more of a personal matter, I guess, but I like learning new thing :)
Hope that helps you to make a decision.
you can implement push notification to your website without using third-party libraries. You have required to get subscription token from the client and store this subscription token onto the server (Inside database). After when you want to send a push notification to the user then you have to just call endpoint (endpoint is mentioned in subscription token). That's it.
Due to security risk and managing subscription tokens, developers prefer to use firebase, AWS push notification or onesignal.com services. These services are optional you don't need at all.
Read links introduction to push notification and also the same lab code examples. Later I will update with simple working code for further reference to your question.
It depends on what you want. It‘s not possible to use iOS Safari for Web-Push. For notifications to iOS you have to use a service or build your own app.
I use Pushover for notifying myself from Scripts and Software. That may or may not be a solution depending on how much users you have, how many notifications you send and how willing your users are to use a web app like Pushover (or an app on iOS).
A service will keep notifications going when things change. So it should be less maintenance for you.
If you want to target iOS visitors also, this is not possible, as web push notifications are not supported by iOS.
To circumvent this, you need to use a third party service like Wise Notifications.
The alternative is to build an iOS app and send native push notifications.
Our goal is sending notifications to groups of devices from our backend, and only from server side is possible to know which device should receive the notification.
We've done some attempts with AppCenter because we mostly work with Xamarin iOS/Android/Forms, but now we have the doubt that it's probably better to use directly Firebase API because wider and more powerful.
I see that with new version of API (HTTP V1) is not possible to send a notification to a list of tokens, feature that was available in legacy API using registration_ids parameter (https://firebase.google.com/docs/cloud-messaging/send-message).
Device group name (legacy protocols only)
I cannot use topics because when it's time to send the communication is a server's responsibility to prepare the "mailing list" for notifications.
I was thinking to use device group messaging (https://firebase.google.com/docs/cloud-messaging/android/device-group) but these are part of the legacy api, and I'm not sure if it makes sense/it's possible to use them with new version of API.
Is an option to send a batch of 100-200-500 push notifications each one to only one token? In theory there isn't a limit to notifications which is possible to send, but I'm worried that sending too many of them I could risk to be banned.
Is it better to use legacy API? Also AppCenter (Microsoft) uses legacy API, it's evident because of how the setup works and because from AppCenter's console it's possible to send notifications to a list of tokens, feature unavailable on Firebase's console.
Another person just asked something similar but the answer was to use topics (How to send firebase notification for all user at a time?).
Got here from the link in your comment in my answer here. And just to reiterate my response there, when sending messages to multiple tokens with v1, the suggested approach now is to use Topics Messaging, since registration_ids is not supported.
Is it better to use legacy API?
v1 was described as the more secure, cross platform, future proof way of sending messages to FCM clients. More secure since it uses OAuth2 security model.
However, if your use-case is better with using the legacy API, then I suggest you go ahead with using it.
This page suggests that you should stay with the legacy API if you want to continue to use the multicast feature: https://firebase.google.com/docs/cloud-messaging/migrate-v1
Any apps that use device group messaging or multicast messaging, however, may prefer to wait for future versions of the API. HTTP v1 does not support these features of the legacy API.
I have created a mobile app for Android and iOS using Phonegap Build. Last year I had nearly finished writing code to use GCM (Google Cloud Messaging) for remote push notifications - which can go out via Apple's APNS too - but the project was shelved.
This year the project is resurrected and I find Google has changed everything to Firebase (FCM). I then read some enticing things about Amazon SNS handling notifications. Just when I started to think SNS might be a better option, I noticed you still have to set up GCM/FCM anyway, and pass all those details to SNS.
So is there any benefit to using SNS when I've got to do the full FCM setup as well?! Both services seem to offer the same features: interact with APNS if required, subscribe to topics, provide you with a nice API/SDK, etc. The app code, and the server-side code would be no simpler, as far as I can see. Why add another layer (SNS) on top of FCM?
(I'm trying not to let this be an opinion-based question: I want to know whether SNS is saving me any effort, giving me any advantage, or adding any features that FCM does not have.)
Just some thoughts.
If you are already using some mobile AWS SDK, then it's more convenient to use it for SNS too.
That also helps keep your app smaller.
And you're happier as a developer since API calls are somewhat unified.
If your backend is hosted on AWS infrastructure you can use IAM roles for EC2 instances (also Lambdas etc.) to make those call without access key/secret key.
You get metrics in your CloudWatch.
But Firebase Cloud Messaging is free :)
Let's answer a few questions first.
1.Do you want to develop, maintain and run the code to talk to GCM?
2.Do you wish to do the same for another platform (iOS, Kindle Fire), if you choose to develop your app for other mobile platforms.
3.Do you want to manage change of registration_id's by yourself?
4.Do you care if a notification is delivered to your users a few milliseconds later?
If you answered NO to any of the questions above, I recommend using SNS to deliver push notifications to iOS, Android and Kindle Fire devices.
SNS talks to GCM to deliver notifications to android devices. Here is what SNS can offer you.
Simple API to send notification to heterogeneous platforms.
Manages application registration_ids. As a developer you don't have to worry about change of registration_ids.
Scales really well. You don't have to worry about managing infrastructure if your app becomes super popular.
Can tolerate GCM downtime & throttling.
I have the existing app that using GCM and have some issue with GCM reliability. I interested using FCM to replace the GCM, but I doubt about compatibility. I've some google search but still couldn't find a satisfactory answer, here some link:
Migrating from gcm to fcm on android
If FCM inherits from GCM, does FCM also support GCM token? Or we need to some config in the server (using gcm-http.googleapis.com/gcm/ vs. fcm.googleapis.com/fcm/request in one server?)
I still doubt to migrating GCM to FCM, so I need some ideas from you all guys and I think send a notification from FCM console is not scalable for me because of too many notifications that triggered by user activities. Thanks
As much as I have understood from reading various documents and watching youtube recordings of 2016 I/O, FCM appears to be rebranded GCM. Server side integration will stay the same with option to switch endpoint domain name. When look a little closer you see that both domain names are referring to same IP address.
From client side integration much more has changes. FCM has a new SDK which makes certain things little easier to manage. Not sure if there are any improvements in terms of keeping app connected to the backend, listening incoming messages.