I was thinking about adding a timer to my app so I can use it to refresh data in the background on a regular basis, instead of sending silent notifications through APNs with a server.
Will Apple reject my app if I do this?
After 8 seconds in background the app will pass to the state of suspended and it will simply stop to execute any code. Plus, there is no warranty that the app will not be killed by the system.
It will simply not work.
For the periodic update using APNs with silent notifications, most likely apple will ban you from sending APNs, if you send too many of them.
The way you do periodic updates for your app while in background/suspended/dead is by using Background fetch Background mode.
Please note: You don't decide when or how often the background fetch is executed. it's iOS that will decide based on your app usage per user.
Here a link to a tutorial for background modes including background fetch.
Here the app life cycle and states.
Related
Id like to know how to get iOS to fetch data from a server on receipt of a silent notification while the app is in the background.
For background, I'd like my app to fetch fresh data from my server while the app is in the background.
I first looked into BGAppRefreshTask but it seems very unreliable.
From what I can gather it only runs when the system 'thinks' it should so this wont really work for my needs.
In fact, I'm positive that I have implemented BGAppRefreshTask correctly but I have never seen any of the tasks actually execute.
What I would like to do is trigger the fetching of data while my app is in the background by responding to a silent notification.
Can this be achieved somehow with BGAppRefreshTask by responding to a silent notification?
If this is not possible how can I achieve my goal of reliably and predictably fetching data while the app is in the background?
I'm thinking in making an app that send e-mails without showing the native iOS mail app. For that I'd be using sksmtpmessage framework.
I'd like as well to keep sending the e-mail when the app goes in background. According to this thread, it would be doable.
I know that Apple limits a few tasks to be done is the background (Audio, VoIP and location). Then my question is, would Apple reject an app using sksmtpmessage framework to send an e-mail from the background?
Cheers :)
If you're just "completing a task" (i.e. the user loads the app to send some e-mails, then quits before they're all sent), you're fine - that's what the Task Completion multitasking mode is for. If you want to run constantly in the background sending e-mail, then it'll almost certainly be a reject (if they spot it) - this isn't something they envisage being done on the iPhone.
From the app docs : An application can call the beginBackgroundTaskWithExpirationHandler: method to ask the system for extra time to complete some long-running task in the background. If the request is granted, and if the application goes into the background while the task is in progress, the system lets the application run for an additional amount of time instead of suspending it. (The backgroundTimeRemaining property of the UIApplication object contains the amount of time the application has to run.)
You can do preceding in time, because iOS 4 gives you a 10 mins of time for task completion after you exit an app.
I have noticed that some apps e.g. Skype run in the background.
I would like to have my app run in the background also, waking up every 1 seconds to update some data and then going to sleep again.
How can I do this?
I gather that NSTimer's do not work in the background.
You can't. Voice-over-IP apps get a special exception for this, basically the system manages a network socket for them and wakes them up if there's data. There's no way to do the same with a timer.
By the way, waking your app every second, your battery wouldn't last half a day.
See Executing Code in the Background
You would need to use push notifications to push information to the app (like the Facebook or Skype app). See this documentation from Apple on how to use push notifications.
Not every second though, that would drain the battery. Other than that, there isn't really a way unless you are running a VoIP app.
Is it possible to keep a socket connection alive in background, to be able to push new data and alert users at all times?
The answer to this question is a definitive yes. If you are in the background state, then you can keep a connection open and process messages from a server.
Unfortunately the complexity here is that you don't have a lot of control over the state your application is in:
foreground - The user has tapped your icon and the app is running with the UI visible.
suspended - The user was previously running your app in the foreground, but suspended it by hitting the home button or receiving a call. Basically your app is 'freeze dried' and will remain inactive until it is resumed by the user (starting where it left off) or it is terminated by the OS (see below).
background - The app was previously running in the foreground but has moved to the background state as a result of something the user has done. Normally your app will move to the suspended state in this case, but there are things you can do as the developer to prevent the instant 'freeze dry' and go into the background instead (see below). Your app will also be in the background state if it is woken up for a significant change event.
terminated - Your app has been unloaded from memory and the next time it starts will be from scratch. This is what happens when you double click the home button and then tap the x next to your app icon. It moves the app from the suspended state into the terminated state. This will also happen if the OS decides it needs room for more recently running apps and your app has been suspended for a long time.
So obviously the trick here is how do I stay in the background state as a long as possible. There are a couple of ways to do this:
Beg for more time - You can get up to 10 minutes of additional background processing when your app is closed if you ask for it.
Use UIBackgroundMode - You can declare youself a voip, audio or location app by adding the corresponding UIBackgroundMode value to the pList. There are special requirements for these types of apps which you can check out here.
So these approaches are not without their own problems (getting approved on the store being one of them) and as such I tend to agree with the other answers that using push notifications is probably your best approach for notifying your users. With the notification improvements in iOS5 this is going to be the best user experience going forward.
You can keep a socket connection alive (or do whatever else you want) in the background for about 15 minutes after your app closes. There are also more specialized background processing modes (specifically, audio, voip, and location) which Apple supports if your app fits into one of their supported categories. See here.
If you want to keep sending the user notifications indefinitely, you want to use the Apple Push Notification Service. This allows your app to continue to receive notifications when it's not running, and it conserves resources since there's only one connection to the APN service at a time.
You can definitely alert users with local and push notifications.
And as far as I know, you can keep a connection open only for limited time.
Look here for more details.
I can't seem to find a clear answer to this-- I'm spec'ing out an iPhone app that I'd like to have live in the background and notify the user at certain periods throughout the day. So the user would launch the app in the morning and then continue to use their phone, then every few hours the app would pop open a notification dialog.
Will my app ever be shut down (automatically) by the OS? Or will it just live forever, notifying user when it needs to?
thanks,
Eric
Basically there are three kinds of running in the background on iOS 4:
Running in the background to "finish" stuff (e.g. upload a posting or a picture, finish processing something etc.). You ask the OS to grant you extra time after the user switches to another app, and it will tell you how much time you got. You can't run in the background for an indefinite time.
Running in the background to do specific stuff: VoIP, tracking location (e.g. for GPS navigation), or playing audio. You can only do the stuff that you told the OS you would do in the background.
Local notifications (UILocalNotification). From your description, this is what you're looking for. You're not actually running, you just schedule notifications, and when it's time to notify the user, they'll be notified and can go to your app. If you need to notify the user dynamically (i.e. you don't know ahead at what times they need to be notified and it's not location or VoIP triggered), you might want to look into push notifications.
Apple has a good overview here:
https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/about_the_background_execution_sequence