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!
Related
Im quite new to iOS programming and now want to implement a periodic background synchronization to synchronize my server data with client data. What I want to achieve is comparable with Androids SyncAdapter where you can define a time interval (for example each 30 minutes) and the system will trigger the defined task automatically in the background.
Until now I could not find such mechanism for Swift 3.0 so I need to ask if somone has experience or some hints for me how I can achieve this.
What I want to do sounds quite simple:
When the app starts for the first time the app should setup a sync manager which automatically triggers a background task every 30 minutes. The background task is responsible to synchronize server and client data (using Alamofire).
How can I do that?
There is an iOS feature called BackgroundFetch, which you can set up for
regularly downloads and processes small amounts of content from the network
You can setup a minimumBackgroundFetchInterval.
In contrast to the mentioned Android feature, this interval is not guaranteed though.
The OS does some heuristic in a blackbox. It rewards you for using a "reasonable" (to the OS) CPU time/ power consumption and also for being used often by the user. On the other hand you get punished for draining the battery or (even worse) never being used/opened by the user.
See: Apple Sample and Apple Docs
Update: Since iOS13, BackgroundFetchis deprecated.
There is a similar, new API named BGTask, BGAppRefreshTask is the equivalent to deprecated BackgroundFetch.
See Apple Docs
Alternatively, depending on your needs, you can post a Silent (push) Notification whenever the users data changes on server side. A silent push wakes up your app without notifying the user, so you can fetch data and maybe inform the user by scheduling a local notification.
See: Apple Documentation
You can't. Apple doesn't allow 3rd party apps to have regular background time like that. You'll need to come up with another approach like implementing a silent push notification from your server when new content is available.
As #ekscrypto points out in their comment, you can use Background fetch to load small amounts of data when the system decides to fetch it. However, you don't have any control over when that fetching takes place. Search on "Fetching Small Amounts of Content Opportunistically" in the Xcode help system for more information.
I am looking for a good way how to make my app "upToDate". These are my requirements:
I have an RESTful Webservice, with tasks for different users. Every user has an iOS App, which should get automatically updated when the Server/Service assigned a task to that User.
So first ill created a manuall "Sync" Button, which checks for new Tasks. Fetches the data with Alamofire, and updated the UI.
But, my goal is automatically sync if there are new tasks.
So, ill guess there are 2 different ways to solve that:
1. Make a Background Fetch (with a NStimer?) every xx Minutes and check if there are new tasks.
After checking that tutorial here:
http://www.raywenderlich.com/92428/background-modes-ios-swift-tutorial i am not sure if a background fetch is a good way to solve that. In that case the App uses an scheduler, to check once for new updates, and not every xx minutes.
So in my case i would create an NStimer in the AppDelegate (maybe in applicationDidEnterBackground) and check every xx minutes for new data (but when there are 3 days not any new task, that would be unnecessary battery consumption, or?)
2. Using Push Notifications.
My other idea is to use Push Notifications, so when there is a new task, ill send a Push Notification an manually start the sync. In my opinion that would use less battery, because he will only start the sync when there is a new task available.
Generaly Questions about using Background Services
So ok, if the user finished the task, some data should be automatically uploaded to the server. Normally not a problem, with the manual sync ill check if there is something to upload. But, what if, when there is no internet connection (ill check if before uploading) - and the user do not press on "manual sync".
So i would prefer to check in my "Background Service" if ill got an Internet connection, and if yes - start uploading some data.
Ill know this is not a specific question, but ill think there are lots of users who have the same requirements and it would be great if someone can help me out whats the best way to solve that in the best and practical way.
Thanks in advance!
Background updates sound wonderful until you realise that Apple throttles them heavily: you can ask to be updated as frequently as possible, but iOS decides what that value actually means based on how often users open your app and when they do so. Apple considers background updates the kind of thing that should happen just before a user opens your app so the latest content is right there, rather than something that runs proactively in the background.
Your push notification solution is a better one, particularly if you use CloudKit to subscribe to record change events using CKSubscription and CKNotificationInfo. If you do this you'll automatically get push messages in your app, so you can get what you want with very little work. You can read my tutorial for more information on subscribing to CloudKit to get push messages.
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'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.
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/.