I am working on an application which GET and POST information to a server. I am doing so using AFNetworking framework. My aim is to push a notification to a client whenever someone posts new info to the server. Eg: a new grade is published, the student who's grade was published must receive a notification on his iDevice.
Although I am not familiar with how Apple Push Notification works, from what I read I concluded that I need to add server side code in order to trigger a notification.
Note that I don't have access to the server. Service is provided by Fedena.
Any suggestions or hints from where to start?
APNS needs a server in order to work. The usual flow goes like this:
The iOS Application asks user to enable push notifications
Upon access granted, a device token is generated and then must be sent to the server.
Your server must be setup with the proper APNS certificates generated from the Apple Developer site
Then in your server's, when a new post is created, you need to add some logic where you load all the APNS token you've received already and then send the notification to the devices.
This is a very simple flow description but I guess you understood that you need to have access to the server to be able to do what you are trying to achieve.
Some third parties exists to handle push notifications (like Urban Airship), but those push notifications are usually pushed manually from a person, and not triggered from a server event
I recommend that you can use secondary server of your own as intermediate and use it as infrastructure back bone.You can use SignalR library. Use secondary server as to create connection between two devises. One client will push events and another client will listen to events.
Here is the link to the signalR library code written in IOS.
I am currently using these library. What you can do is start hub and connection using these library.
This library allows invoking method on server. Something like this.
[_hub invoke:#"MehtodName" withArgs:params];
What i would do is to create event registry on server. So one client can listen to event on server and other can push events or vice versa.
So your student device can invoke method "subscribe to events" and server will add it into the registry list. You can create secondary service "Publish Events". Grade publisher can publish via calling this method. Here publish events will look up registry and find interested clients and call desired method on client.
Read more about signalr through this site.
Benefit of using Signalr Over APNS.
Cost Effective. As this will save you money which you might have to pay to Apple for pushing notification.
Can Easily make it cross plateform in future. Just have to impletement similar library in Android/Windows.
Quicker as the data does not travel to apple server from your server.
Worst case you can fallback to apns any day, just put push notification code in any of your secondary server methods.
I have done battery and performance testing as well and works perfectly fine.
If you wanna know, here how it handles connection which is very reliable.
SRAutoTransport chooses the best supported transport for both client
and server. This achieved by falling back to less performant
transports. The default transport fallback is:
SRWebSocketTransport
SRServerSentEventsTransport
SRLongPollingTransport
Let me know if you have anyother question. i am currently doing similar work, might be able to help you with your issue.
Related
I have an iOS app which displays some information fetched from the server.
The app communicates with the server using REST API, and makes GET requests periodically (or when user pulls-to-refresh). However, we need better synchronization. As soon as data changed on server, we want to reflect it in the mobile app.
How can I get notifications from the server when data changed and update needed? I thought about silent push notifications, but they do not look a right choice here.
Are there alternatives? May socket programming help? I have no an experience in it, but I it is relevant, I will start digging.
I have a service that allows user to enter the type of events they like, and whenever a new event that fits those criteria is available in my database, I want them to get a notification.
I have been looking around at the best way to handle it and I have found two possible solutions, but I'm not very clear with which one I should use and how.
First, a solution that looked great was the didReceiveRemoteNotification method and the usage of remote silent notifications to tell the app that new content was available. But my questions remains: how can I send this remote notification to the user if I don't know which criteria he has. I mean, how can I send this notification using PHP? I'm a bit lost here.
So I found another possible solution that does look a lot like a hack (iPhone - Backgrounding to poll for events), to be able to make your app execute a method every XX minutes while it is in background. This would be way more battery consuming and I'm not even sure it would be accepted by Apple, but at least it is clear as to how it works: the app downloads data from a link with the parameters that fit the special criteria, and if there is new data, it sends a notification.
How could I combine both these methods?
EDIT
I think the main issue on my side is that I don't understand how I could check a certain PHP file whenever new data is added into mysql and make sure that it fits the criteria of the user and then send the notification. That is the part that I don't understand in the backend PHP usage.
Your flow should be like this -
Mobile -> BackendServer(PHP) -> APNS server -> Notifications->Back on device.
User will submit her/his criteria to server then server will process on that and send request to APNS server.
The APNS server will send remote notification on her/his device based on criteria requested.
I have recently been assigned a task to develop a notification engine. For the notifications we are going to use Push Notification. I am looking for the best possible solution for the engine because in future we have to scale the application to other devices also. Following are some details of the project
Backend:
Backend of the application is developed in Ruby on Rails as webservices
Devices that will have push Notification
iPhone, Android, Pebble (smart watch), Web application
Current Solution:
Currently, we are thinking to make a back-end database table for notifications. A worker class in Rails will run after 1 minute and it will push all the notifications to the devices stored in the database. From the webservice methods, we will insert the data in the notification table.
For pushing notications we do not want to use services like UrbanShip. We are only going to implement them using Ruby Gems. Currently, we made a small demo based on GCM gem for android push noticiations.
Questions: Is my approach to the solution is correct ? or is there any better solution for this kind of problem.
EDIT:
I think that my previous description of the problem was a little confusing.
Ultimately we are going to use GEMS in Ruby to send push notifications. Forexample for iOS we are going to use Houston or Grocer gem and for Android GCM.
Problem: We need some database tables where we will store notifications so that the GEMS (mentioned above) can use them to send the notification to users. Now, to fill the database tables we need to write the logic somewhere so that we can insert the notification in the table.
Forexample, lets say that when a user first registers in the application we send him a notification. Now, to do this we need to write the code for adding the notification in the Register function.
like
public void Register()
{
//Registration logic
//Add a notification in the notification table
}
Now, this is a problem because we need to add the notification logic in all the functions that need to send notification. Is there any other good solution in ROR or in general ?
Some design pattern ?
I've spent a fair amount of time looking at Ruby based push notification solutions. The best one is RPush https://github.com/rpush/rpush. RPush is very well tested at this point (We use it to send millions of notifications), and handles a lot of difficult edge cases well. I wouldn't recommend building your own from scratch since there are so many potential pitfalls and edge cases. RPush doesn't support Pebble or Web App notifications, but could be extended to do so.
If you decide to explore other alternatives, make sure they:
Handle closed connections gracefully for APNS - In many cases, Apple may close the connection to their server, and your push notification library must handle this correctly otherwise thousands of subsequent notifications can go undelivered
Communicate with Apple's feedback service - Apple requires you to poll one of their endpoints for a list of devices to stop sending notifications to. If you fail to do this, you can get rate limited.
Can send notifications at a fast enough rate for your requirements.
Outside of Ruby, the best push notification libraries seem to be PushSharp (C#), and Node-Apn (NodeJS, iOS only)
Finally, it sounds like you have specific needs that require you to do this yourself. But for others, I would strongly encourage you to use a 3rd party services. Reliably sending push notifications at a high volume is difficult and there are many 3rd party services that will do it for you at low cost. For instance, UrbanAirship, Parse, and OneSignal (My service) are all great 3rd party solutions.
Update to address revised question:
The best design pattern is to have a a second daemon process or Cron Job that handles message delivery. It's not practical to try to do this inside of a Ruby on Rails application.
The RoR application can insert rows into the Notification table as a queue like you describe. Then the daemon process or cron job can fetch notifications from the queue and deliver them.
If you use RPush, this is the pattern that it follows. It comes with both a Gem to load into your Rails application that inserts notifications onto a database queue, as well as a daemon that you keep running on your server that periodically checks for new notifications to send and delivers any that get queued up.
I wonder if this question is still open or you already have a solution, but I'd like to propose this gem I've recently published: https://github.com/calonso/ruby-push-notifications
It's really simple to use, flexible enough to fit your architecture and works!
At the moment is just the gem itself, but I'm working on building a whole Rails plugin around it, with all the tables structure and stuff. You can see some work in progress here: https://github.com/calonso/rails-push-notifications
This article describes a very simple but fairly comprehensive approach to handling push notifications on your Rails backend.
In a nutshell:
Implement a Device model together with some controller actions to record users's device tokens in your DB.
Create a Notification model, which in the article is a Redis list but you can also use ActiveRecord if you don't really want to use Redis.
Create a background worker that is actively running through the incoming notifications and sending them as push notifications. The article mentions grocer and GCM to send them to iOS and Android respectively but you can also use other useful gems such as rpush, houston, etc.
Having a separate worker processing notifications is a good idea because you don't want to be constantly opening and closing connections to Apple and Google's servers with the risk of getting locked out, since it might look like a Denial of Service attack (depending on the frequency of your notifications).
I understand the basic concept of having a provider talk to Apple's Push Notification Server which then pushes the notification to the phone. Usually, the provider is an app server running on some machine somewhere completely separate from the app.
However, we don't currently have a separate server, and don't yet need one as everything is currently handled in-app. So, is there any way we can use the app itself as the provider to send a notification to Apple's server and thus to another phone?
Basic concept: we have a game and when a user completes 70% of the level, we'd like to notify his competitors that he's close to finishing the game (or that he has finished at 100%).
If it's possible, are there any security concerns with this approach?
P.S. The app already knows who the competitors are because it displays them in a UITableView.
Technically it's possible. If you include the push certificate with your app, and you have a way to send the device token of each device to all other devices that may need to push to that device, you can push a notification directly from one device to another.
However, in practice, that would require opening and closing many connections to the APNS servers frequently (you'll need a connection for each device, and every time a device loses network connection - which may happen often - you'll have to re-open that connection), which will probably cause Apple to block your app from connecting to their APNS server (since they would interpret it a DDoS attack).
Therefore you should use a server.
For future visitors to this question: we wound up ditching Amazon SNS since we spent nearly 8 hours and couldn't get it working the way we wanted. Instead, we setup Parse Push in rough 15 minutes with exactly what we wanted to do, so I would definitely recommend giving it a look.
I have to add e-mail notifications to a client server application.
Notifications happen as the user do some particular action on the client UI.
If I had a middle tier or a service running at server I can imagine how to do it:
1) I simply create a DB tables with "pending notifications"
2) as a user does an action that generates a notification I add a record to the table
3) serverside I would continuously try to send those mails and removing them from the table once sending is succesful
Now I cannot do this now, I have a plan to add a service later on, but for now I must go the quick and dirty way.
So somehow what I was thinking to is to implement something like this:
1) as a notify-worth event occurs at client, the same client (my exe) tries to send the notification, upon failure it will log the notification in the "pending notifications" table (failure can be becuase lack of internet connection or any other problem)
2) I add a Timer that will work from any client machine to check for pending notifications. If there are any the client will try to send the e-mail (using a transaction: I will mark a field as "TryngToSendFromClientX" and in case of failure I will reset that field to NULL)
I think this approach would work, it has obvious limitations (if after failure no one logs into the system, no notification will be sent - same would be if service goes "down"). But can you comment on this approach and suggest a better one?
Additional notes (to better understand the scenario):
a) Note: all notifications are sent from the same e-mail account.
b) I don't need to keep track of who sent the e-mail.
c) the problem of creating the service now is that it will basically complicate significantly deployment and I need to create tools for monitoring the status of the service. Something that I will do in future but not now, in future I have plan to add more functionality (not only sending notifications) to the service, so in that case it makes more sense to create it.
d) I will send e-mails by using Indy components and SMTP server.
If you are not willing to create the service now, I think you are stuck with the scenario you describe. There are some things though you could do to circumvent the problem of no user firing up the client anymore while there are still pending messages.
You could add a commandline utility (or commandline parameter as bepe4711 suggested) that will only check for pending messages and try to send them.
Add this commandline utility to the StartUp folder or Run key in the registry. This way messages will at least get sent when the computer restarts, even if the user does not fire up the your app.
Add a scheduled task to run this utility at least once every day. The scheduled task can be added by code or by your installer.
If you do both, you will only have to worry about pending messages of users that never start their computer again.
Perhaps you can add a parameter to your client which causes it to just look at the pending notifications and send them. After this it can terminate itself. It will just act like some kind of service.
Then you install the client on the server and start it every x minutes.
I do something very similar to the approach you describe. Instead of sending emails I need to call a web service. My application is installed on several laptops and they are commonly not connected to any network.
When my application raises an exception I collect various bits of information including user comments and screen shots. Then I attempt to send this to our web service. If by chance the web service is not available. (i.e. not connected to the internet or web service is down) I write the results to an XML file on disk in the User Profile (App_Data) directory.
The one major difference is I don't poll to check to see if the server is up. I attempt to send them again on the startup of the application.
If both Systems are running on Windows, have a look at MS Message Queue. It is designed to send notifications to systems, which are not allways online. I did it in .Net, there are already easy to use classes implemented. Not sure about Delphi.
Latest version of Windows uses much more the Windows Task Scheduler, and now task can be fired on event (i.e. when a network card gets connected...). You could write a separate utility that tries to send pending notification, even if noone is logged in.