What I want is to send an automated push notification to users once a day, and have found a way to do this with automated notifications with OneSignal. The problem is that it asks for a title/message to input on their console, but what I wanted was to have a backend (haven't chosen yet, probably Firebase) with some strings, and each day a string will be randomly chosen and that will be automatically pushed to all of my users. Is there a way to do this with OneSignal, and if not with some other push notification service?
Can I accomplish this with the OneSignal API, or should I write some custom script and host it somewhere (like cron) that sends these using API calls?
thanks
Related
I'm working with AWS SNS API for mobile notification,
along with AWS CloudWatch for message monitoring.
There's currently only 5 metrics to be watched:
NumberOfMessagesPublished
PublishSize
NumberOfNotificationsDelivered
NumberOfNotificationsFailed
SMSSuccessRate
None of these seems to be like message content, recipient platforms, or delivered date/time. (contents that make more sense to marketers rather than developers)
How could I query the history of all my sent messages or a specific message?
SNS does not retain sent messages. You would have to archive the sent messages yourself as you send them.
One idea is to let SNS itself do the message archiving for you, so that you can then query the archive for the analytics that are relevant to you.
This can be done by subscribing a Kinesis Data Firehose to the SNS topic that you use for sending these mobile notifications. You can configure your Firehose stream to store the SNS notifications in S3, Redshift, Elasticsearch, Datadog, Splunk, New Relic, or MongoDB.
Check this out: https://aws.amazon.com/about-aws/whats-new/2021/01/amazon-sns-adds-support-for-message-archiving-and-analytics-via-kineses-data-firehose-subscriptions/
SNS is a wrapper around a number of similar notification APIs. The APIs for Apple (APNS) and Google (Most Android) GCN don't offer any kind of receipt confirmation.
If you need receipt confirmation you would have to build that into the application on the mobile device to inspect messages received that were for that application and there is no universal way to do that either. The other issue is that you are totally at the mercy of the user authorizing notifications.
I suggest you incorporate messaging of your own inside the app and have push notifications as an optional enhancement. In order to get badges to work right you also need cooperation with the app since there is no way using SNS to react to actions taken in the app to clear the notifications or adjust the badge value.
I am working on an app which fetches student info from a server, like absences and events and grades. I have no access to the server, I only have the API.
I am asked to implement push notifications in the app, such that if a teacher marks a student absent, that student get a notification about that. I searched and found several approaches:
1- Background fetch: I tried using background fetch to check if the student logged in to the app was marked absent today, if yes, show a local notification. It worked when I simulated w background fetch, but never worked on the physical device.
2- I searched for using Apple Push Notification Service, and they all wanted me to build a server, and I dont know how to start. Can I build a server which pushes notifications to devices in a way facebook does it? That is, one user triggers a notification at another user, in other words: I dont want to use broadcast notifications.
3- Using third party, like backendless, firebase or any alternatives. Would that be a useful approach?
With Backendless your app (on the student side) can register itself to receive push notifications. This is done with an API call that registers the device on the servers provided by Backendless. Then you would build an additional application (could be a browser web app or a mobile app) for the teachers. The system allows to send targeted notifications, so when a student is marked as absent, you could use the API to deliver a push notification specifically to the student's device. Would be happy to discuss in detail, you can post your question to the Backendless support forum.
For my app I have designed Push service using Java APNS library.
Or You could use Microsoft Azure Mobile services to push a notifications to devices.
I am new to iOS development and started a tutorial on a simple messaging app using Parse as the server. The way they have it coded, the app queries parse every time a message is sent(to save the message) but seeing as Parse only allows 30 req/sec under its FREE plan how would one go about making a messaging app? Is it standard convention to save data to the server for each message? It just doesnt seem practical to have a substantial user base on an app that can only query the serve 30 times a second.
The question simplified is: what is the standard convention for the relationship with servers for a simple messaging apps? Does the app save each message to a server or is there a work around using push notifications? (But even with push notifications the app would have to be opened to receive them, at least thats from my limited understanding of pushes)
It is not practical to have a substantial user base for a messaging app with only 30 queries per second. Parse is running a business. They give you 30 API req/sec so that you can try out their service and see how it works. But if you are designing an app for a significant user base, you will surely have to pay, as you are expecting Parse to run the servers for you.
With that out of the way, it would be normal for a (typical) messaging app to make at least one API request per sent message to the server. The server is responsible for accepting, routing, holding, and delivering messages. It would also be normal for that sent message to result in a push notification, and an API request from the client app to retrieve the message. The general workflow would be:
User sends message
App uploads message to server
Server determines where message is headed
Server sends push notification to recipient
Recipient app queries server for pending message(s)
Recipient app displays message(s) for recipient user
That's two API requests and a push notification for each sent message.
Beyond that, depending on your messaging service design, the server may also store all messages so that later, on a different device, a user can open the app and it will download the history, so as to appear synchronized.
Now, surely there are ways to reduce the number of server API requests. Your app could batch messages locally, your server could batch push notifications, and your clients could batch queries (or you could do all three). All of these options could help dramatically reduce the number of server API requests you pay for, but they will also reduce the responsiveness and user experience of your messaging service.
You could also design a sophisticated peer-to-peer communication system (like Skype was in the past) removing servers from the messaging flow. However, you would have to design complicated authentication and verification systems, complicated routing systems, complicated storage systems, etc. A lot of work. And even if you did, I don't know if Apple would allow it on the App Store. A lot of time, work, and uncertainty to avoid paying the small cost for a server.
Regarding push notifications: Push notifications are sent from a server to a recipient client app. Your iPhone cannot push notification another iPhone. There will always be a server in the middle. Your app does not need to be open to receive a push notification. iOS will receive it, and then deliver it to your app. If your app is closed, iOS will (partly) open it in the background to deliver the message.
I need to update my users for things that happened around their current location while the app is in the background.
To my understanding:
If my server sends a Push Notification to a client, the client would immediately show that message.
I can set up the app so that there is a specific location, with a given radius could fire a message.
So what I want to understand if it is even possible to update my users about things that are new in their locations.
I was thinking of two possible solutions, I am not sure they are possible.
One, I guess if the Push Notifications would allow a function to run prior to its display,
deciding if the message should appear.
For example: something happened in area x,y - The server initiates a message to all devices. Only the devices within range of x,y and a radius z, would show the message to the users.
Maybe the Regional Monitoring service can send a message to my server and my server can then decide if to send a Push Notification back to the client...
For example
The user has entered a defined location, determined by the app. The app sends a message to the server. The server decides if a message is due.
Any ideas? is that even possible?
Filtering push notifications by topic is something you need to do on the server side, not the client side. Apple specifically states not to send messages to users that aren't relevant and you won't be able to block them when the app isn't running. Additionally, if you are using a service to manage your push notifications you don't want to pay for messages that aren't relevant.
So when you register a device into your database, you should register what topics that person is subscribing to (ie. save a list of topics that user is eligible to receive). Then when the event is triggered that generates the push notification only send to devices that are registered to that topic. I believe a number of push platforms have this capability already built in. On UrbanAirship and Azure Notification Hubs you can use their tags feature. Or you can develop it yourself if you do your own push server.
Take a look at Parse. They have this kind of functionality baked right in, just send the push to clients that match a geoPoint query.
I'm trying to figure out how to create a push notification server for a twitter app. I'd like to be able to set up push notification for mentions, stars, follows, etc etc. This is all possible with the API, as Tweetbot does it. If someone could point me in the direction of creating the actual server part of handing the storing of the usernames and pushing the messages out, that would be great. If there is a tutorial on how to do this that would be grand! I'd like to be able to do this through ruby but any method is completely fine.
Thanks
The way I built my push server was like this:
1) Symfony 2 web framework to build an admin portal to manage my entities (Symfony2 is similar to Ruby)
2) A Node.js server that allows me to maintain a persistent connection to Apple's push notification server. (This Node.js beast is epic I tell ya)
3) Node.js will make a HTTP Post request to my Symfony server asking it for new notifications
4) My Symfony server will receive the response from my Node.js server, finds all the new notifications that needs to be sent and returns JSON formatted list of notifications that needs to be sent, the notification contains the message to be sent and an array of unique push tokens (also selectively of the token environment - development vs production) that is to receive the push notification
5) Finally, my Node.js server receives the JSON data, parses the JSON and sends the notification binary stream to Apple's PNS server through TLS socket stream, asynchronously for high performance throughput :D
This method has allowed me to separate PHP Symfony server to manage my data without interfering with my Node.js push server that is abstracted from any data-related logic. The Node.js push server just needs to know the message that needs to be sent and the array of tokens to send it to. At the same time, I can extend and enhance my notification entities such as token groups (allows me to quickly fetch a bunch of token just by choosing a group e.g. members, friends and if you like, enemies :D), notification date (so the notification can be sent at a future date rather than immediately) and more.
Hope that helps.