Large

Android vs. iOS Development: Background Processing

Insight

Mobile Development, Pervasive Location™, Solution Design

Date: 27/06/2016

We can cut through complexity.

If you are building an app which needs to access resources when the user is not actively using the app then you will need to do some kind of background processing. A popular example at the moment might be a health app which measures motion in order to track your activity. This all sounds very simple but the reality is that mobile development can get quite complex once you want to start doing this sort of thing. We look at what is possible on Android and iOS.

Why Background Processing?

There is one key question you should always ask if you are thinking about doing background processing in an app: "why?" As developers, we can probably think of lots of compelling reasons why we want to do things in the background. Maybe, for example, there is some maintenance processing we would like to do. More appropriately, we may want to access the device's sensors to record activity or location — the most likely scenario for a health app.

The reason for asking "why?" is to make sure that there really is a compelling reason to do background processing. Having a compelling reason means that the user is more likely to allow that processing to take place. For example, if you are building a game, why would the game want to run in the background when the user is not playing it? Everything that runs in the background will use up battery and processing time and games certainly do not get played in the background. If the user works out that your app is running when it does not need to, and perhaps consuming lots of battery in the process, then they are likely to force-quit the app or uninstall it. The operating system might also run out of memory, in which case it will silently kill your app.

This is also true if your app wants to access sensors on the device, such as to obtain location information, or to track motion. We may well allow a map app to know our location when we are using the app, but why would we want it to track our location when the app is closed and we are not using the map? Not only will we not give the app permission to access our location all the time, we are again likely to force-quit it. However, if the app is tracking your daily jog to record distance, plus working out how much exercise you had, then we are almost certain to allow background processing. Of course, there are limits — if the app consumes all your remaining battery charge then it is likely to be uninstalled.

Background Processing on Android

Overall Android is a far more liberal platform to work with. On Android, with the correct permissions granted, you can pretty much do whatever you need. Background processing when the app is paused can be achieved using a service.

A service is simply a component of your app which runs without a user interface. Services can be configured as a processing queue — starting when needed and then shutting down — or as a standalone background processor. As a standard component, services have a context which allows them to access all of the shared resources for the app, as well as sensors. This means that your service could tick along in the background receiving location or motion updates, perhaps saving these to a database. They do not have a user interface, but this just means that when your app is next opened by the user, your app can do whatever it needs to do with the data that has been recorded or processed to update the display.

What about when the Android device is re-booted, can you carry on background processing automatically? Yes. By registering a BroadcastReciever, which responds to the BOOT_COMPLETED intent, you can re-start your service whenever the device re-boots. The only thing you cannot do is stop the user killing your app, which will also kill the service. Once killed, the service will only re-start if you act on the re-boot broadcast, or if the user re-starts your app themselves.

All sounds relatively easy. The problem is perhaps that it is too easy to get carried away and do lots in the background. Remember though, if your app uses lots of battery power, or seems to be doing unnecessary things in the background when your app is not being used, then the user is likely to force-quit it or uninstall. Think carefully what you do in the background and make sure you do not eat battery charge.

Background Processing on iOS

This is where things get tricky. Background processing in iOS is highly regulated, with only certain types of background processing allowed. This is also enforced in the Apple review of your app to make sure you are not trying to circumvent the rules by pretending to do one thing, while doing another.

Apple require you to present a compelling reason for doing background processing. One way to get some time to do some background processing is to request additional time when your app is being put into the background. By beginning a background task, iOS will give your app more time, but still expects this to be finite. Some apps do use this to get around background restrictions by essentially continually requesting more time.

Another, and more legitimate way, to get some long-running background processing time is to use an appropriate background mode. For example, getting the device's location while in the background is a typical background requirement for, say, navigation or tracking apps. To do this you need to enable the appropriate background mode in Xcode, request the relevant "always" permission from the user, start location updates when in the foreground, then do something with the location in the background. This location background mode can also be used as a legitimate way of obtaining accelerometer data, since the two normally go hand-in-hand for health apps. Nonetheless, to pass the Apple review, you also need to put "Continued use of GPS running in the background can dramatically decrease battery life" on the app's iTunes listing.

Following this to get background location updates will get you to the point of being able to do background processing. Of course, even this can be a little difficult to check as different iOS releases and the simulator can all behave differently when an app enters the background. For example, on a real device, your app will be suspended almost immediately after entering background mode without the correct configuration, whereas on the simulator, it will keep on running. Even with the correct configuration, you only have a limited time to complete your background processing for every location update.

The issue with background processing, and particularly with using sensors, is the drain on the battery. Here then, you will need to tune your app to only use the GPS sensor at infrequent intervals to maintain low battery usage. However, even this approach will not solve the problem of re-starting your app's background mode when the device is re-booted. Normally and app is only re-started explicitly by the user. A way around this is to enable one of the various sensor update modes which will automatically re-start your app when an update is received. For location updates, this is via monitoring significant location updates, which will wake up your app, but at the expense of only when the device has moved a significant distance from its last known location (stated as at least 500 meters and no more frequent than every 5 minutes). Apple recommend monitoring significant location updates for background processing since it dramatically reduces battery drain.

Background Processing Made Easy

These two different approaches mean that while Android is fairly straightforward to deal with, iOS is not. Building an app which works for both platforms is therefore more problematic and you have to consider the implications in your design.

If you are dealing with locations (including GPS and beacons) or accelerometer updates, then we think we have a solution. The new Pervasive Location SDK provides a consistent interface to allow you to perform background processing to collect this sensor data without having to worry about how it all works.

Measuring time travel

Background sensor data collection in the SDK is being used in a new app being developed for Furnace Limited and the University of Surrey to support a BBC4 television programme about gravity which will be broadcast next year. The app will use background recording of accelerometer data to calculate how much our relative time slows down due to the effects of acceleration as per general relativity.

During November, the app will be used to find Britain's best time traveller, with the winner announced in the programme. Look out for the app and measure just how much time travel you can do.

We can help

Digital processing is at the heart of innovation. It may be that you have a difficult or complex problem. Pervasive Intelligence have the expertise to cut through the complexity to give you a solution you can use in the real world.

If you would like to know more, or are interested in what support we can provide, take a look at what we can offer and get in touch. To receive similar insight, just follow us on .