I Googled around and I can't find many discussions on this. I want to develop an iOS program that would use access a REST service, and I want to get notified of updates so I am thinking of long polling. Does RestKit deal with this?
Another questions is what if I want to run in the background? It seems like the proper way to do is to set up an Push Notification Service and notify the user to open the app to receive the latest message?
Doing a job in background is only possible with special APIs like Music and Location, so you won't even be able to do queries if the user is not using your app.
Instead, you should do all the heavy work on a web service, and setup an APNS server to notify the user when something happens. That way, it won't drain all the battery of your users and use technology in place exactly for that purpose.
There's also a lot of service to send out push notifications, if you don't want all the heavy setup. Take a look at http://parse.com or http://urbanairship.com/.
Related
I'm very new to iOS development. I currently have a fair chunk of the app I want to make done but I'm just now trying to figure out how to implement remote push notifications. I essentially need these to happen automatically and if a certain condition is met.
Basically, I'm using a weather api to do some stuff in my app, and eventually I want to send each user a notification depending on the weather for their location+some other factors (those other factors will be stored in the database, which has not been set up yet) while the app is closed. Would I need server side code to do something like that? And would it simply have to execute once every 24 hours (or some interval of time) for each user?
I've looked at several tutorials about how to set up push notifications but I can't figure out what I need to do to make this work the way I need it to so some explanation would be great. And what service would be best for this (like aws/lambda, firebase, etc)?
Push notifications can be very tricky and are more on the advanced side of iOS Development, it can be a long and complicated process. However, fear not! raywenderlich has an excelent tutorial that can help you implement Apple Push Notifications.
As for sending push notification out at regular intervals, it depends on your type of server. I would normally recommend using a cron job to schedule regular intervals for your push notifications, as I have had good experiences with using them for just this purpose but since you are using firebase which has no cron jobs or any type of scheduling options, you will probably have to use a third party api like Zapier.
Otherwise, Google's Cloud Platform can provide you with ability to schedule tasks for whatever you want to accomplish!
I am working on an app where I would have to implemented at least two background tasks. The scenario becomes like this, I have a web service which tells me when to start the location updates for a user. So, I would need to periodically call this service to check if it's time to start, and/or stop, user's location tracking.
So there are two background tasks, fetch and location tracking. Fetch should run periodically which defies Apple's procedure that it will monitor your app's usage and decide on it's own when to update the content. This has become my first problem, is there any way that I can avoid this? The second problem comes with the multiple tasks, how can I switch between either of them?
What is the best practice here? Dos and Don'ts?
You should use Push notifications through Apple's push servers, or you may find a service like Parse.com easier to work with. You can use the push notification to trigger or create anything in your app delegate (where you handle receiving push notifications). As #Paulw11 's comment states, you can even attach a payload(data) to a push notification and deal with it. So the first part is fire a notification to the user's device when they should start tracking and end tracking.
Most location tracking stuff using an instance of a CLLocationManager can be done via it's delegate methods. However if you want you can use it in a subclass of an NSOperation and manage it in an NSOperationQueue, see here for a tutorial:
http://www.raywenderlich.com/76341/use-nsoperation-nsoperationqueue-swift
And I suggest researching the class documentation.
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 have a chat application developed by JS. I want to send PING to server once in a while. Its not a problem if app runs on fore ground. The problem is when user minimizes it or open another app. My app looses its focus and gets into suspended state.
I have following two use-cases.
To keep the chat session open I need to send PING to server (Its an IRC server) every X minutes even the app runs in background.
We also need to check for new messages (by ajax on a local http server) and add a local notification to the notification queue so when user clicks on it app can resume
I have found apple does not allow running apps in the background. if they allow they require special permission. I found some apps does it by requesting finite length execution time.
What is the best way to get highest possible background execution time? As a chat app can I request permission for voip, location or any other way ?
Note: the app will be running in an environment where there is no Internet. Hence push notification will not work here.
Update: After doing a lot searching I found background fetch. It seem background fetch will suite it. But still the problem remains, its not called in a timely manner.
This sounds like an interesting problem. From reading the various comments, it sounds like you want this to work when you're on a local network - so you have wifi, but the wifi router/base station isn't connected to the actual internet?
Because background refresh isn't going to be predictable - you'll never know when it is going to update - you might want to get creative.
You could look into exploiting iOS VOIP support, only without the Voice! Apple has some tips on VOIP here. VOIP basically uses something called SIP (Session Initiation Protocol), which is signalling layer of the call, and a lot like HTTP. It's this SIP layer that you want to take advantage of.
This isn't going to be terribly easy, but it should be achievable. Setup your app to use VOIP, and then look into something like PJSip as your SIP library. Then, on your local network have a SIP Server (I'm sure there are plenty open source implementations) that you can register your iPhone against (so your server knows where your phone is, pretending to be a VOIP phone). This should work, because it doesn't need to go through Apple as far as I am aware... And will run happily on your local network.
Then, the server can send a message via SIP to the handset, as if it were instigating a VOIP session. You app is awoken, gets the messages - ideally from the SIP message if possible - and then just doesn't start the session. SIP was designed just for creating sessions, not just VOIP. When I worked in Telecoms R&D (a long time ago) we were using it to swap between Text/Voice/Video, all using local servers.
You'll have to jump a lot of hoops to make this work, but it would be pretty awesome. I have never tried this actual use case - especially with iOS, but I'm fairly sure it will work. It is a bit of a fudge, but should get you where you need to go.
Good luck!
You can use something like PubNub to build this chat app with iOS using native Objective-C code, or with the Phonegap (Cordova) libs.
The beauty with using a real-time messaging network like PubNub is that when the app goes to the background, you can easily have the chat messages come in on APNS.
When the app is in the foreground, it can just receive them as the native (PubNub) message. And if it needs to "catch-up" with the messages it missed while in the background (but received via APNS), its trivial to implement.
Also, PubNub is platform agnostic -- so you can easily also use it on Web, Android, BB, Windows Phone, etc.
http://www.pubnub.com/blog/build-real-time-chat-10-lines-code/
http://www.pubnub.com/blog/html5-websockets-beautiful-real-time-chat-on-mobile-using-pubnubs-channel-presence/
https://github.com/pubnub/objective-c/tree/master/iOS
https://github.com/pubnub/javascript/tree/master/phonegap
geremy
I'm trying to look for a way as to how I can notify a user of new updates based off of a .Net API that I created. Much like that notification you get on facebook, I just need to alert the user that something has been updated. So I'm thinking I need a function that runs in the background while my user uses the app combined with a NSTimer.
Based on my research (and on this question https://stackoverflow.com/a/14835300/639713) apparently you can only achieve such a thing for VOIP and location services. And that using push notification is the only way. Is it really the only option that I can use for such a need? Or are there any other ways?
Thank you for your time.
You have two options:
While your app is open, poll the server every so often to see if there are any updates to report.
This will work only as long as the user has your app open, and as you note, your app will only be allowed to stay open for a long time if it happens to be a VOIP or navigation app.
Use push notifications to push updates to the user’s device.
The disadvantage here is that you will need to write some server-side code to talk to Apple’s push notification servers (as described in this tutorial). This may or may not be a big deal in your particular situation, but it’s the only way to get data to the user when your app isn’t open.