The idea of using the push notifications is only to have a notification mechanism that will send a notification when there is a new message waiting to download from the backend service: all the notifications are of the same type e.g. "refresh messages from the server" (the same for Android and iOS).
Are there any limits for the Apple/Google push notifications services?
Assuming that my application will handle more that 100k active users (or even 1M or more users) - would there be any problem with the Apple Push Notifications or GCM services?
If using the push notifications for such a service is not a good idea then what is other solution that could be used for mobile chat applications?
Don't forget that on iOS user may forbid sending notifications, so your app won't receive any even in foreground. Thus, you need to implement your own push mechanism.
Need for push notifications
Especially on iOS you don't have a choice but to use their push notifications service APNS. There is no other way to receive notifications immediately because iOS may kill or neglect the TCP connections of your background app.
On Android it seems possible to use your own background TCP connection to avoid having to use push notifications. But you may still consider the use of the push notifications through GCM for the sake of improved battery usage.
Pricing
Neither APNS (iOS) nor GCM (Android) charge you for the service and you are allowed to send an unlimited number of messages.
Limitations and Requirements
Both services will delete message, when there are too many messages accumulated in the queue for an offline device - which makes sense because there is no point in delivering those messages hours later. You have to take that in to account, when writing your app (just do a poll when going back online).
Depending on the app you are writing, there may also be privacy concerns. Even if you encrypt the message itself, at least Apple/Google know when a notification is sent to a certain device, which may be a deal-breaker for certain high-security applications.
You will also need a server that is able to communicate to both APNS and GCM. There are open source solutions for that (e.g. easyApns for iOS and python-gcm for Android), but how easy their integration is depends on your server and the language it is written in.
Related
I host a PWA website and I am trying to integrate push notifications to my users who may have the website open in a browser tab even if their phones are inactive. You notoriously can't send Push notifications to iPhones without using Apple Push Notifications service (APNs).
Seeing as the point of firebase cloud messaging (FCM) is to outsource the message handlers, I kinda assumed it would support sending push notifications to iPhones somehow via APNs, but the information here suggests you still can't do this from the web.
https://firebase.google.com/docs/cloud-messaging/js/client
Safari and iPhones don't support Push API.
According to this answer: https://stackoverflow.com/a/64576541/2116253
Option #2 may be possible if you know the device ID token, which is apparently very hard to get and perhaps not possible anymore because Apple are trying to make it harder to obtain due to security concerns.
I think the actual sending via APNs from server side is quite easy, the problem comes with the initial setup/registration and actually granting permissions that allow notifications to arrive.
So, in short, I don't mind registering my website with Apple, agreeing to terms and obtaining keys for the purpose of interfacing with APNs, but I don't want to make and distribute a whole native iOS app just to send notifications to devices about my website.
Does anybody know the correct way to achieve this in 2022 ?
I'm about to develop an app similar to a birthday reminder and I plan to use firebase for push notifications but what makes me second question my choice is whether users will be able to receive a birthday notification if they are offline(not connected to internet for the whole birthday day). I know firebase has some offline persistence support but I'm not sure if this includes push notifications support. Are there any options to achieve that with firebase or with any other tool compatible with react native?
If the device is not connected to the internet, it is going to be impossible to deliver messages to it through Firebase Cloud Messaging or other internet protocols.
The common way to deal with such a scenario is to deliver the message to the device when the user does have an internet connection, and then only display it once it's the right time. By sending a data-only message through FCM, your application code controls exactly what happens with the message data.
There are essentially two types of notifications: in app messaging and cloud messaging. Both are offered by Firebase: In App Messaging and FCM (Firebase Cloud Messaging).
The details you've given about your app is a little bit vague but if you're asking for push notifications, then FCM does the job. FCM will send notification when the app is on background or killed (exited out). When you say device is offline I'm assuming you mean when the user isn't using the phone. Yes, the notification will still come.
https://firebase.google.com/docs/cloud-messaging
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 am making a website and one of the features is that whenever a contract is nearing its end, the user should be notified about it. So I was looking for a way to notify users and I found out about push notifications.
Now, there are lots of things written about it. I heard a lot about Google Cloud Messaging, Firebase Cloud Messaging and Service Workers.
Now the thing is that my website will probably be on an Intranet. So maybe I won't be able to use GCM/FCM.
But I have a few questions regarding GCM, FCM and Service-Workers:
Why do I need FCM/GCM?
What is the difference between FCM and Service Workers?
Is there a way to push notifications even if the browser is closed?
Because my website is on an Intranet, is there another way to push notifications to the users?
1. Why do I need FCM/GCM?
You may check here the features of FCM.
Notification payload: 4KB, Message payload: 2KB. Note that the notification includes device and app information too.
Stores 100 notification/messages per device if the device is offline.
Stores notification/messages for 30 days if the device is offline, and deleted them all one this period is over and the device is still offline.
FCM supports Android and iOS devices, and even chrome web apps. The notifications are sent to iOS devices in this way: App Server -> FCM -> Apple Push Notification Server (APNs) -> iOS device -> App.
GCM supports 1 million subscribers while FCM do not have this limitation.
Supports programming in C++.
Less requirements for coding.
2. What is the difference between FCM and Service Workers?
Service Worker is a background service that handles network requests. Ideal for dealing with offline situations and background syncs or push notifications. Cannot directly interact with the DOM. Communication must go through the Service Worker’s postMessage method. Service Workers are pretty perfect for creating offline-first web apps. They let you interact with the server when you can (to fetch new data from the server, or push updated info back to the server), so your app can work regardless of your user’s connectivity.
While using FCM, you can notify a client app that new email or other data is available to sync. You can send notification messages to drive user reengagement and retention. For use cases such as instant messaging, a message can transfer a payload of up to 4KB to a client app.
3. Is there a way to push notifications even if the browser is closed?
Check this thread: Notifications while browser is closed
4. Because my website is on an Intranet, is there another way to push notifications to the users?
Unfortunately, I don't see any documentation regarding this.
Hope my answers help you.
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.