We have an app (iOS, Android) where we send push notifications to from the Firebase web interface to all the registered users.
The backend system cannot handle the peak load that occurs when all the users are pulled into the app calling the REST API from the push notifications.
Is there a way to split the registered users to send the push notifications little by little at an appropriate rate?
I suspect that this has to be done programmatically. C#?
Question with workarounds handling peak times when sending push notifications
The web console for sending notifications with Firebase Cloud Messaging does not have a way to throttle message delivery. It's an interesting concern though, so I'd recommend filing a feature request.
For the moment though, I can think of two options:
Create multiple audiences that cover your entire user base, and then send to each audience at a different time.
Use the FCM API to send out the messages to your users in batches.
Hi can I make push notification service with signalR?
for example when user start the app,app can recive message and if app closed again app can recive messgae from servers or clients
Until you can send the message to clients that user is online.
And with the closure of the app, Disconnect Communication server with the client. And the ability to send any message disappears.
If you want to send notification after app closed, It is better to use the google service. (e.g: Firebase Cloud Messaging (FCM) services),
Otherwise you can only use signalR for send message in your app.
I hope this is useful description.
If you want the ability to send messages or have messages available to any client then store them in a database table. When they are connected, you can send those messages to them. When they are disconnected they would stay in the database.
You can control flagging messages as read after they are delivered and then deleting them from the database.
Your "push notification" is just querying for the messages when a client is connected.
I am developing REST API application on Symfony3. I want to register mobile devices and send direct push notifications to them. For example, when one user sends feedback to another, that second user will get push notification.
With Amazon SNS is it possible not to broadcast, but directly notify individual device from server?
yes, is possible, you create a platform and then you can create multiple 'Endpoints' wich represent a devices in SNS with the corresponding token or device id. then you can notify to one device using the endpoint arn value
the thing is that we already have a backend that handles all the push notification process. From device registration on our DB and notification handling on the device and notification sending to Apple and Google servers...Looking into Parse I saw that it has a lot of things that will take us a lot of time to develop but mostly on the process that sends the notification to the devices.
So...I need to know if devices can register in our backend, then from our backend to Parse and then send push trough Parse. Is this possible? Image below.
Thanks!!
Yes this is possible. You'll need setup your push certificates with Parse and register each device's push token with a Parse Installation object's deviceToken field for it to work. All this is documented on their web site. You'll need to setup a Parse User object for each user as well as each Installation is associated with a single User.
I'm trying to understand what I will need to build on my server for Push notifications to work successfully.
My thoughts were:
The phone sends the notify URL to my server
The server stores the information in a Database
A separate process or PHP script will query the database and open continuous looping process for each device. (Each socket will be querying a 3rd party API)
When there is a change detected in the API for that device a push notification will be sent to the device's notify url.
Is this the right method on what needs to be done. Isn't this going to eat up server resources or is it the expected outcome of Push a push notifications server?
I've produced a simple diagram on all this below:
First of all, let's separate the process in the main stages needed for PUSH.
Device subscription.
Send the PUSH
Process the notification on device.
Subscription
For the subscription, your device (more specifically, your App) must call the PUSH api,for enabling PUSH notifications. This call to the push API will give you a URL that uniquely identify the device where your application is installed and running. You should store this URL on your database, the same way you store a user's email, or a user's phone number. No special black magic here. You only use it when you need to send a communication to a user.
Send the PUSH
For the push stuff, the same approach as for email, or SMS messaging here: "One does not simply make an infinite loop and send a message if any change is detected". What you have to do is, just send the PUSH message when your application needs to. So you have the user to which you want to send a message, instead of opening a SMTP connection to send ane mail, just build the PUSH XML Message and call the URL associated with that user. Some things to consider here are:
Network reliability (you need to retry if you can't connect to the server).
Response error code-handling (you don't need to retry if the server tells you that the phone has uninstalled your application, for example).
Scalability. You don't want to send a PUSH message from your PHP code, because you don't know how long it will take for the task to be completed. You have to make this thing asynchronously. So just queue up all the push messages, you can create a separate process (windows service, nodeJS service, cron job, daemon, etc.) to send the PUSH, handle retries and errors and clean the queue.
Process the notification on Device
So now that you are this far, you need to handle the notification on the phone. It depends on the type of PUSH notification that you are sending:
Tile. You will update the image, text and counter of the application tile, if the user has put your application to the start screen. On client side you need nothing to so, as all these parameters are part of your PUSH request.
Toast. This one requires a title, text (limited to some 35 characters more or less) and a relative URL inside of your APP. Your application will be launched (like when you click on a Toast notification from Twitter, for example) using the URI that you specify in the payload. So a bit of data can be already injected here. You may/or may not make a request to your server for new data. It is up to you.
Raw. This one is pretty much silent. Is not seen by the user if your APP is not running. As you might guess, this kind of PUSH is useful to live update your running APP, instead of continuously polling your server, wasting user battery and bandwidth and wasting your server resources. You can send anything (raw bytes or strings) up to the max size of the payload allowed my Microsoft.
If yo have any more questions, don't hesitate to ask.
Bottom line: separate the PUSH sending, make it async, don't you ever forget that...
Your PHP script that continually pings the database for changes...THAT is what will eat up your system resources. Push notifications go hand in hand with Event Driven Programming. This means that ideally, your code shouldn't continuously ping your DB. Rather, when something happens (ie, an "event"), THEN your code does something...like contact your phone via push notification.
Your steps for push notifications are more or less correct, but are incomplete. Step 4: the server contacts the client via the notify url (which you have). Step 5 is that the client then contacts the server to actually pull down the information it needs. That is: The new information is not provided to the client via the notify url. Once the client has its new information, then the program continues as normal (populates a list, downloads skynet, etc.)
Your third step is very wasteful and not practical if your app is installed on more than a few devices.
Instead, each device should be subscribed to types of server updates it cares about. Your server's DB will have a mapping from each type of update you support to the list of notification channel URLs of devices that care about this update type.
When your server detects an update of type X, it would send a notification to all devices subscribed to that type of update.