In order to run the app continuously in the background on the 3GS and iPhone4 on OS4.1
is it simply enough to call BeginBackgroundTask in the DidEnterBackground callback and then
NOT call EndBackgroundTask ie to leave it running. I understand this will run the battery
down but that is ok as my users will be running on power.
If this is not the way to do it , can someone say how to keep the app running (not suspended)
Thanks
You cannot keep the app running on the background.
You can declare some tasks that the system will run in background.
According to the Apple documentation:
Support for some types of
background execution must be declared
in advance by the application that
uses them. An application does this by
including the UIBackgroundModes key in
its Info.plist file. This key
identifies which background tasks your
application supports. Its value is an
array that contains one or more
strings with the following values:
audio - The application plays audible
content to the user while in the
background. location - The application
keeps users informed of their
location, even while running in the
background. voip - The application
provides the ability for the user to
make phone calls using an Internet
connection. Each of the preceding
values lets the system know that your
application should be woken up at
appropriate times to respond to
relevant events. For example, an
application that begins playing music
and then moves to the background still
needs execution time to fill the audio
output buffers. Including the audio
key tells the system frameworks that
they should continue playing and make
the necessary callbacks to the
application at appropriate intervals.
If the application did not include
this key, any audio being played by
the application would stop when the
application moved to the background.
In addition to the preceding keys, iOS
provides two other ways to do work in
the background:
Applications can ask the system for
extra time to complete a given task.
Applications can schedule local
notifications to be delivered at a
predetermined time. For more
information about how to initiate
background tasks from your code, see
“Initiating Background Tasks.”
Related
I have used ctcallcenter, and use beginBackgroundTaskWithExpirationHandler, so I have only 10 minutes to call my codes. How can I make it longer，the app proxBLE have achieved it?
From the Apple documentation, you can extend the execution time only in the below cases. In order to do that, you need to add the UIBackgroundModes key to info.plist file. See the detailed explanation below.
Implementing Long-Running Background Tasks
For tasks that require more execution time to implement, you must request specific permissions to run them in the background without their being suspended. In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background,
such as a music player app
Apps that keep users informed of their
location at all times, such as a navigation app
Apps that support
Voice over Internet Protocol (VoIP)
Newsstand apps that need to
download and process new content
Apps that receive regular updates
from external accessories
Apps that implement these services must declare the services they support and use system frameworks to implement the relevant aspects of those services. Declaring the services lets the system know which services you use, but in some cases it is the system frameworks that actually prevent your application from being suspended.
Declaring Your App’s Supported Background Tasks
Support for some types of background execution must be declared in advance by the app that uses them. An app declares support for a service using its Info.plist file. Add the UIBackgroundModes key to your Info.plist file and set its value to an array containing one or more of the following strings:
audio—The app plays audible content to the user while in the background. (This content includes streaming audio or video content using AirPlay.)
location—The app keeps users informed of their location, even while it is running in the background.
voip—The app provides the ability for the user to make phone calls using an Internet connection.
newsstand-content—The app is a Newsstand app that downloads and processes magazine or newspaper content in the background.
external-accessory—The app works with a hardware accessory that needs to deliver updates on a regular schedule through the External Accessory framework.
bluetooth-central—The app works with a Bluetooth accessory that needs to deliver updates on a regular schedule through the Core Bluetooth framework.
bluetooth-peripheral—The app supports Bluetooth communication in peripheral mode through the Core Bluetooth framework.
Each of the preceding values lets the system know that your app should be woken up at appropriate times to respond to relevant events. For example, an app that begins playing music and then moves to the background still needs execution time to fill the audio output buffers. Including the audio key tells the system frameworks that they should continue playing and make the necessary callbacks to the app at appropriate intervals. If the app does not include this key, any audio being played by the app stops when the app moves to the background.
I need to have the following things to work while my iphone application is in the background mode.
1.Run a clock.
2.Communicate with the server every 15 mins to get the server time and one another value.
3.Need to start downloading data in background mode.
I searched a lot whether these are possible or not. Kindly give confirmation on these.
I am developing an iPhone application which involves Ticket Booking System. I registered my application as location based beacuse it is using user's location taken in background for a purpose.
My problem is that i need to run an internal clock in my application in background mode. I need to write the codes for internal clock in core location delegate methods, so that internal clock will also run along with the location bsed services. Will my app get rejected? Is anything wrong in doing like this?
I need to get the correct time to use in my app, so that i am running this internal clock. I can use NSDate, but that will return the device time. Anyone can change the device time. So once somebody chaged, wrong time will affect the smooth functioning of the app. Kindly some body suggest to get the correct time with out running the internal clock ?
I suppose you want to do this with your app not running in the foreground - and that is not possible, if you don't use some tricks like playing an empty audio file and pretending to be a music player or the like.
In iOS, you can only execute code of your app while it is actively running in the foreground, except for some specific tasks like VOIP or music playing.
If you want to do this while your app is running in the foreground, just use NSTimer and a background process for loading, like it was suggested. But then you should also prevent the iPhone from entering SLEEP mode after 1 minute, otherwise it won't work when th euser is not actively using the app during the 15 minutes ...
This is possible, what you need to do is,
1] Run a background thread, in which set a NSTimer with 15mins.
2] Set repeat:YES to call it at every 15mins.
3] And start download your need there!
I will do like this if I stuck like your situation!
I have an iphone app that has a 30second process that does some network IO. Basically, while the app is in the background, i want this process to run every hour (actually once a day, but if it fails i want it to re-run in an hours time).
With the background features of ios 4, is this possible? If so, how? What are the limitations that i'll come up against?
Thanks so much!
Take a look at Apple's documentation about running code in the background.
http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html
There are few different ways of approaching backgrounded tasks. The only apps that can have fully backgrounded processes are "audio", "voip" and "location" apps, and this needs to be declared in the Info.plist.
If your app is not of this type, you'll probably find it difficult to do what you want easily. There are methods which allow you to keep your app alive in the background for a finite period of time (also at that link), but eventually your app will be shut down.
Local Notifications will only prompt the user to open the app - do you really want to have an alert pop-up on the phone every 30 seconds?
I was making some kind of similar research, have a look at this SO answer in case you didn't manage to find it before. Applications like DataMan or Data Usage must have some sort of periodic code execution in the background, so I'm not 100% convinced that what you're asking for is impossible..
I believe that Using Local notifications will help....
check following....
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html#//apple_ref/doc/uid/TP40008194-CH103-SW1
An application can create and schedule a local notification, and the operating system then delivers it at the schedule date and time. If it delivers it when the application is not active in the foreground, it displays an alert, badges the application icon, or plays a sound—whatever is specified in the UILocalNotification object. If the application is running in the foreground, there is no alert, badging, or sound; instead, the application:didReceiveLocalNotification: method is called if the delegate implements it.
The delegate can inspect the properties of the notification and, if the notification includes custom data in its userInfo dictionary, it can access that data and process it accordingly. On the other hand, if the local notification only badges the application icon, and the user in response launches the application, the application:didFinishLaunchingWithOptions: method is invoked, but no UILocalNotification object is included in the options dictionary.
I am writing an application that records a users position at regular intervals whilst walking. I am using an NSTimers to schedule "startUpdatingLocation" followed by calling "stopUpdatingLocation" shortly afterwards to save as much battery as possible.
I want the user to be able to start the application and lock the phone thereby putting the application in an inactive state. My question is when this happens my application (when running via Xcode) seems to continue as normal, but I am curious if there are any differences in the way the application runs in this state as apposed to when the application is running as active?
From the docs it only mentions "applicationWillResignActive" with regards to the application passing through that state on its way to the background. I am more interested in how an application behaves when a used locks the UI and puts the phone away, I just want to make sure its going to keep doing what it should be doing or do I need to take extra measures?
When you app hits applicationWillResignActive it can continue to receive location updates if you use the UIBackgroundModes option in your apps info.plist.
Add the location key.
It is important that you do not use a timer in the background as timers will run but hold their "fire" until the app becomes active again. Thus you will only get one read when the user comes back to the app. The GPS location accuracy level is what will drive how much the battery is affected.
In your app description in the App Store, Apples requires:
Continued use of GPS running in the
background can dramatically decrease
battery life.
You app will not be allowed to go live until the above text is in the description for the user to read.
You should definitely be testing this on a device. The simulator doesn't auto-lock, for instance.
applicationWillResignActive is called when the user presses the home button, when another app fires a notification the user accepts (including when a call comes in), and when the device locks.
Look into the multitasking documentation, and what it has to say about background location updates.
My suggestion is that you conserve the user's battery by:
- starting a timer, which when fired, starts location updates (and stops the timer)
- when you get an adequately-accurate position record, stop location updates and restart the timer
- if location updates fail, restart the timer for a longer period. Maybe they're underground.
The most efficient approach is using significant location update service while your application is in the background or the screen is locked on your app. You might get one update every ten minutes or so.
Remember also, the user can disable your app's location services permissions. Especially these days...
Will Core Motion framework work while the app is in the background?
The Core Motion framework allows access to historical data for CMPedometer data, so if your app is only using this there is no need to run in the background.
I have been playing around with CM the last week and in my testing if you have an active query running when your app is sent to the background, the query handler receives a flood of events (that occurred while the app was suspended) upon returning to the foreground. I don't know how many events will be cached, and I haven't seen anything in the docs about this.
This behaviour seems to be sufficient. I can't think of a use case for Core Motion where you need constant background access, historical CMPedometer data doesn't suffice, and fits within the App Store guidelines.
Depends on your definition of working... Will Core Animation need to continue running or are you expecting the view to be frozen? When an app runs in the background only certain processes are allowed to run. (Notifications for example).
For the most part the application UI, and by extension is paused until you trigger applicationDidBecomeActive. Once that starts up again it should resume, but again not continue running in the background. Same can be said for most games on iOS running OpenGL, it's paused until the app is active again.
one of the apps- moves that is used to track your walking steps is quite amazing, because even you make it into background or killed, it can indicate the steps you walked. So some internal mechanism of gyroscope and GPS and other sensors can carry on when the apps are killed.
In order to let your app run in the background, you have to declare it as a background task. The problem is that there are only a few UIBackgroundModes ... and motion isn't one of it.
A workaround could be to enable the UIBackgroundMode location, which is intended to let users know about their location even if the app is in the background. You could then wrap your motion logic within. Nevertheless, the clear drawback of this is that it involves usage of the GPS, which will drain the battery significantly...