Background processes in iOS.

A customer had set the following task: he wanted to receive data to his device from the server in the local network regardless of whether the application was in foreground mode or not.

Previously, the applications were simply killed when the Home button was pressed. But starting with iOS version 4.0, the applications featured a so-called background mode, which automatically pauses all tasks by default (except for those with delays, which should be stopped manually or which will actuate simultaneously in case of return to the application when the delay expires).

In order to execute a code in the background, it is necessary to observe several conditions which the given application should correspond to.

One of the following three main conditions can be selected:

  1. the application should play the music
  2. the application should register the coordinates of the device and update them
  3. the application should use voice communication (like Skype calls)

But let’s suppose that we need to update the coordinates anyway, it’s a part of your program’s functionality. In this case, it’s just logical to write a background process using updating coordinates as a reason for your project’s persistence in the background. However, remember that Apple’s policy requires you to use the coordinates received, otherwise your application will not pass the certification.

"An app should request background location services only if the absence of those services would impair its ability to operate. In addition, any app that requests background location services should use those services to provide a tangible benefit to the user. For example, a turn-by-turn navigation app would be a likely candidate for background location services because of its need to track the user’s position and report when it is time to make the next turn."

So in order to activate the background process to receive the coordinates, you must:

  1. check whether CoreLocation.framework has been added to your project
  2. add the "Required background modes" array in the project's main property list, the first element of which will contain the line "App registers for location updates"
  3. implement the "CLLocationManagerDelegate" protocol in your view controller
  4. create a property with the type "CLLocationManager", initialize it in your viewDidLoad and send the message "startUpdatingLocation" to it, for example, from your delegate right after your didFinishLaunchingWithOptions has been completed.

That’s it. In the implementation of our controller, we then add the message:

- (void)locationManager:(CLLocationManager *)manager didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation *)oldLocation {
// which will be executed once per second consistently
// to display the coordinates on the screen, we can write the following:
CLLocationCoordinate2D currentCoordinates = newLocation.coordinate;
NSLog(@"Latitude: %f Longitude: %f", currentCoordinates.latitude, currentCoordinates.longitude); }

The rest of the code should be written inside.

In background mode, we request the available data from the server, and if there is any, we take it and process it. Of course the request timeoutInterval should not be too long, and should only take a second or less. It is better to not let the request wait for the response rather than to allow it to hang up or to allow the application to lag.

This results in another issue. It is not ideal to allow the application to run without notifying the users. Everything should be transparent. That is why, when we receive data to be presented to a user, we will send a local notification. No Internet connection is needed for this message to be sent. The message will be displayed, and when a user clicks on it, our app will be opened again. In addition, our code will work with the application running in foreground mode, not only in background. If it is important to convey that the application is already in foreground mode, the corresponding message will be send.

The method described above requires sufficient power supply. There is another, more efficient way to detect a user’s location. However, this option is not suitable for us as it is based on another approach associated with significant location change. It allows the application to be launched when a significant change in the user’s location occurs - between 500 and 4000km. One can assume that our users will remain within the same approximate territory of a local network and will not move any significant distances.

At the initial launch, the application will ask the user to give permission to utilize the user’s current coordinates. To receive information about the location, one of the following conditions should be met: there should be an internet connection, GPS, or cellular communication.



Some applications require

Some applications require periodic updates of data from a remote server.

Good work

Neat explanation.