Apple’s newest iPhones promise improved battery life. However, much of the improvement has been achieved through constraining background processes, rather than improvement in hardware. The implications on app development has been significant. This article discusses battery life management in light of recent mobile apps we have designed and built for our clients, which connect to IoT (internet-of-things) devices via Bluetooth.
Bluetooth Connectivity
Bluetooth is a great option for communication between devices because it requires very little energy in the process. However, the downside is that it only works for short range communication, and can lose connection in certain conditions e.g. low battery, issues on the device.
Different Bluetooth Profiles
There are many different profiles associated with bluetooth connectivity – it is all bluetooth, but the profile will have implications for the functionality that can be achieved for your mobile app. The available options are governed by the hardware and software in the device to which your app is connecting. We regularly work closely with the IoT equipment designer, so can have an influence on the selected profile and information delivered between the device and the mobile app, but this is not obviously possible when your app is connecting to a device with a previously established bluetooth profile.
There are many different bluetooth profiles – below is a list of those more likely to be involved in a mobile application:
- Bluetooth Low Energy (BLE). An even lower power consumption protocol, natively supported by Apple, Android, Linux, Windows and Mac operating systems.
- Bluetooth A2DP – Advance Audio Distribution Profile. Used for streaming audio from one device to another over a Bluetooth connection.
- Bluetooth HFP – Hands-Free Profile. Used to allow car hands-free kits to communicate with mobile phones in the car.
- Bluetooth HDP – Health Device Profile. Facilitates the transmission and reception of Medical Device data including heart rate monitors and temperature monitors such as that collected on a smart watch or fitbit style device.
- Bluetooth HSP – Headset Profile. Used to interact with the user via a headset.
- Bluetooth MESH – Mesh Profile. Used for efficient smart lighting systems and IoT networks.
- Bluetooth SPP – Serial Port Profile. Allows setting up virtual serial ports and connecting two Bluetooth enabled devices.
- Bluetooth VDP – Video Distribution Profile. Allows the transport of a video stream.
Two examples of recent apps we have designed and built for our clients, utilising bluetooth technology, are described below.
Travel Dua App
For this app we used Bluetooth A2DP profile to the play a sound file over a car audio system (most recent motor vehicles which provide bluetooth connectivity support the A2DP protocol). Before playing the audio, the mobile device (smart phone) with the app installed must be paired with the car via bluetooth. The app we designed and built for our client continually checks for any paired A2DP devices, so that when a driver gets into their vehicle and starts their car, when the paired device is found the app immediately plays the sound file embedded within the app using the vehicle’s audio system.
It is also possible that the user would like to play the prayer sound file at other times, so the app allows the user to also manually play the sound file, at which point the sound will play over the mobile phone’s speaker instead.
PlumbGuard – Plumbing Safety Device App
The purpose of the HLP Control’s PlumbGuard app is to provide an additional way to alert a plumber when a hazardous risk is present. Designed and built by Contactpoint, the app scans for and receives data from plumbing safety devices within range, which use beacon technology to advertise their current status. Without pairing to the device, the app can read the advertising packet broadcast by the device.
The app on the plumber’s mobile phone shows the status of all the devices being monitored as reported by the received data set, including the presence of any hazards, the current mode of the device (charging, self-test etc), and battery level.
If the device is low power mode or hazard status, the app will alert the user by playing the relevant warning sound and vibrating.
Battery Management
Battery life is a very important aspect of mobile app development. A device without power offers no functionality at all, and users will notice if a particular app drains their battery more quickly than normal and will likely remove it.
In addition, smart phones are judged by consumers, among other things, on the average time their battery lasts before it needs to be re-charged. For this reason, both Google (Android) and Apple (iOS) provide several external APIs for use within mobile apps, and they employ several internal mechanisms to help conserve battery life which are partly dependent on the platform and device speed. As app developers, we must work within these constraints to deliver the required functionality.
App States
When developing a mobile app, we have to consider each of the following app states, to achieve the most efficient use of memory and battery life, whilst delivering the required functionality:
- Not Running – the app has not started yet, or was running and has been terminated by the system.
- Foreground:
- In-active – the app is running in the foreground but not presently receiving any event. This could happen for example when an inbound call event occurs or a message is received. In this state we can’t interact with app UI.
- Active – the app is running in the foreground and receiving events. This is the normal mode of an app.
- Background – an app is running in the background and executing its normal function. Freshly launched apps commence in an in-active state and then to active state (there platform specific differences in this behaviour).
- Suspended – an app is in the background and is not executing the code. The system moves the application to this state automatically and does not notify. This usually occurs in the situation where the device has low available memory, and is also platform specific.
Background services
It is also possible in very specific states to program an app to perform certain functions within background services. Background services operate without direct interaction by the user. A background service has no user interface and is not bound to the life cycle of activity. Background services are used for repetitive and potentially long running operations such as checking for new data, connection management, data processing etc.
Apple has significant restrictions in place for the use of background services, in an effort to improve user experience and extend battery life.
Summary
Depending on the functionality of your app, you may need to specifically program for different states of operation (aside from the suspended state which is controlled by the platform).
As part of building the two apps mentioned above, we utilised local notifications for the Apple versions to ensure that the app is woken up at the appropriate time, in response to the likelihood that the app would be moved by Apple to the background. Local notifications effectively bring information into the foreground to make it easy for the user to bring the app back into an active state by pressing on the notification. Local notifications are triggered at the point that the app goes into the background, and therefore are available from the app lock screen when the user is ready to resume use of the app.