Need some design advice for on implementing a push notification system. I am using for the backend Symfony 3, Doctrine and postgres as the database. The notification system will have two types of notifications:
1. Instant notifications
2. Scheduled Notifications
Instant notifications are when an action is performed in the backend and a notification is instantly pushed. For example, a notification when a user is deleted in the database.
Scheduled notifications is for a notification that has not been triggered yet but will at some known time in the future. The notification will only be triggered when it reaches that set time. For example an Alarm clock.
Based on this I have designed simple tables as follows with some mock data:
So with above information the API concept is at user’s device such as mobile phone, it will run a GET/notifications API every 2 mins. The API will return notifications that are before the current date and has not been dismissed for that user. For example, if USER2 executes the GET/notifications with the current date at 18th April 2017 it will return record 3.
My question is this type of design acceptable if not what would be the conventional practice? Also with many users running the same GET API every 2 mins is there a potential to slow down the system? I’m guessing about at most 3000 users.
Finally, as the notifications table grows in records will postgres slow down when performing this API?
Who ever has taken the time to read it all the way through thank you, I am very grateful for any advice.
Push Notification.
If your client devices are asking for notifications via a GET API call, Its not called Push notifications. Down the time, it will be heavy on server side to handle too much unnecessary requests as all users might not have that much notifications.
You shouldn't let your clients call. You should push the notifications to client instead. The iOS and Android apps can be configured to get push notifications through deviceId and uuid. Ask your mobile developers for the same. These days even HTML5 browsers are supporting push notifications.
For storage :
I think you don't have to store instant push notifications in database at all, unless you have an application level requirement to store the logs.
You should only store scheduled notifications so that a Cron job can pick and push those notifications when they are due.
Hope this helps!
Related
I'm using with success the flutter local notification plugin. Now I'm struggling for create a page with all notifications.
Is there a way to collect all incoming local notifications of my app (even if dismissed and/or not clicked) in a list (the classic notification page like FB etc.)
I only notice that I can track the tapped notification but not only the arrival notification.
Thanks!
This unfortunately is not possible, because notifications are not stored anywhere. They exist in memory on the device, until the user dismisses them, or they are replaced with a message of a similar ID, or the OS just removes them altogether.
Your best bet, is to generate a table on your mobile backend, that will store these notifications (the same ones that will be broadcasted to the users notification center), then get the app to read directly from this table, and store it on a local SQLite database.
These notifications that are broadcasted, will need to be sent from the backend itself, with the exact same content, as that being stored on the table I mentioned. This will ensure data integrity between the notification center, and that of the app.
[EDIT]
Please make sure that you use FCM (Firebase Cloud Messaging) for mobile push notifications. These are completely free, as per the documentation:
https://firebase.google.com/docs/cloud-messaging
For Tutorials, please look at these:
https://medium.com/#jun.chenying/flutter-tutorial-part3-push-notification-with-firebase-cloud-messaging-fcm-2fbdd84d3a5e
https://www.freecodecamp.org/news/how-to-add-push-notifications-to-flutter-app/
I am developing an application which requires push notification.
I have provided Push Notification feature but I need to know what if a user has turned off his/her iDevice for 2-3 days or for whatever reason, the device is turned off for few hours/days/minutes etc.
If I send a push notification at that point of time, would the user receive the notification when he turns on his device.
Thanks
If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one.
Here's why. The device or computer acknowledges receipt of each notification. Until the push service receives that acknowledgment, it can only assume that the device or computer has gone off-line for some reason and stores the notification in the quality of service (QoS) queue for future redelivery. The round-trip network latency here is of course a major factor.
All of this points out that the intent is that a notification indicates to an app that something of interest has changed on the provider, and the app should check in with the provider to get the details. Notifications should not contain data which isn't also available elsewhere, and they should also not be stateful.
Any push notification that isn't delivered immediately was queued for future redelivery because your device was not connected to the service. "Immediately" of course needs to take latency for your connection into account. Outlying cases would be beyond 60 seconds as APNs will time out at that point.
Still you have any query then you can refer the below link
http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
In didReceiveRemoteNotification, is it possible to see if there are other/older push notifications that haven't been responded to?
I have a scenario where each notification contains different data, and unless you exit app and select every single notification for your app. You app wont be able to get to that data.
I'm thinking that iOS must be storing that information in an array somewhere, but haven't been able to find anything through Google.
Advice please? Last chance saloon would be re-writing it to poll a server for notifications.
You cannot guarantee that your app will ever receive any push notification sent to it. The only way it does is if it is running when it receives the message or if the notification is used to launch your app.
I would recommend implementing a web service on your server that allows your app to pull down the data it needs from these notifications when it is running.
I have implemented all recommended methods in AppDelegate to get working Remote Notifications service.
I can accept them while running, while launching and while turned off.
But there is an issue, since I can't work with many received notifications while in background. I can work only with latest notification.
What is recommended manual to do that? How can I got all notifications received while in background? Is it only solvable via manual call to my service provider (sender of apns data)?
With all the projects I've worked on there hasn't been a way to locally store this information if the push notification is dismissed. In all those cases we used a small file on the server that the app would connect to and pull when it became active again. There was also some place in the app where the user could see all their notifications which, again, were stored on the server for quick retrieval.
With the way I understand push notifications to be setup, if the notification is dismissed the system discards it. It'll perform anything it's supposed to do (such as update the badge number and play the correct sound) but any additional information specific to that notification is lost.
Not sure if this helps, but if you just want to know how many notifications you have missed while you were in background. You can create a variable which contains notification number and store this in the app every time you handle notification. When you come out of background and receive a new notification you can subtract the new number with the stored number to find out the number of missed notifications. I don't think there is a way where iOS can give you complete data associated with all the notification device have received while the app was in background.
The best solution is to keep a list of sent notifications with all relevant data on your server, so the app can access that data when it launches. Sending multiple notifications with data that is not stored on the server can be risky, because the application only receives the notification when the user opens the app from that notification, so if they tap on one notification, the app will only every receive that one.
If you have them all in a list on your server, the app can simply go and pull that list down, and process it, making sure no data is lost.
I have just heard that - " push notification " is possible in iPhone
I need following details.
what is push notification ?
How it works ?
What does it requires ?
Any sample code link is available ?
Any documentation link if available ?
Some guidance/tips from "StackOverFlow Masters" about developing the above requirements.
Thanks in advance for sharing your knowledge with Stackoverflow family & me.
The sort of background processing you're looking to do is not possible with push notification.
Push notification allows you to notify the user of something. An example would be a Twitter client that sends a notification when the user receives a direct message on Twitter.
Push notification can not react to things happening on the iPhone when the app is not running. Instead, it depends on you having a server that determines when to send a notification and then sends one.
I'm not seeing any need for background processing in your application. If you store the user's initial location, the next time the app loads you can get their location and calculate the distance between the two. If you're looking for the route travelled, you're out of luck unless you make a deal with AT&T like Loopt just did.
Push notification is not really for that purpose, you should read up on push notification in apples site here http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction/Introduction.html, its more for when theres data like a m essage for your user, you can have the user get it without having them open t he application. Now for your purpose, why cant you store the location when htey close the app, once the reopen the app you can reget a location, use the previous location and the new location to calculate the km travelled?
Although only tangentially related to this discussion, I think you might be interested in Loopt's agreement with AT&T to track user's iPhones (for a monthly fee).
Apple Push Notification service (APNs for short) is the centerpiece of the push notifications feature. It is a robust and highly efficient service for propagating information to devices such as iPhone, iPad, and iPod touch devices. Each device establishes an accredited and encrypted IP connection with the service and receives notifications over this persistent connection. If a notification for an application arrives when that application is not running, the device alerts the user that the application has data waiting for it.
Software developers (“providers”) originate the notifications in their server software. The provider connects with APNs through a persistent and secure channel while monitoring incoming data intended for their client applications. When new data for an application arrives, the provider prepares and sends a notification through the channel to APNs, which pushes the notification to the target device.
Check this link clearly explained Apple push notification services
http://mobiforge.com/developing/story/programming-apple-push-notification-services