Accessing Peripherals

Introduction

A growing trend in mobile app development is for an application to make use of other (peripheral) applications that are on the device, especially, applications that control device hardware.

As today's phones are being loaded up with cool features, the inclination of developers is to use as many of these features as they can. This is not a problem if the app actually needs to utilize those peripherals, but many apps access peripherals that they never use.

The solution lies in managing peripheral applications intelligently.

This Best Practice Deep Dive looks at different types of peripheral applications, discusses the issues involved in using them, and provides recommendations for how to use them efficiently in an application.

Background

Mobile phones continue to become more productive as applications gain the ability to leverage devices and other applications included with the phone, such as:

• Cameras
• GPS
• Bluetooth
• Speakers
• Wi-Fi
• Document writing ability and texting

Other features that are either here, or on the horizon include:

• Cloud storage and backup
• Point and find
• Digital wallets

Phones may soon allow you to transfer or pay money instantly from any bank account or credit line.

If you leverage all of these peripheral applications properly, you can keep adding new features and the capability of your application can keep expanding.

The Issue

With all of these powerful features comes responsibility. Using so many device hardware features in an app can seriously drain the battery and slow down operations.

Avoiding this requires careful management of how the peripheral applications and devices are being used.

Best Practice Recommendation

The Best Practice Recommendations for accessing peripheral applications includes the following:

1. When accessing device hardware, you should ensure that your software has fail-over parameters that are set so that they turn off the accessory after a certain period of inactivity. Turning off the Bluetooth, GPS and other features when they are not in use is an easy way to save battery life in your app.
2. Sometimes, there are more efficient alternatives to using peripherals. For instance, instead of pinging the GPS continually for location, which drains the battery, an app may be able to get the needed location information from the network by using the closest cell tower. This simple solution avoids turning on the GPS altogether.
3. Make sure that you are following the general best practice guidelines of the platforms that you develop for.
   
   User location guidelines for the Android platform:
   
   https://developer.android.com/guide/topics/location/obtaining-user-location.html
   https://developer.android.com/guide/topics/location/obtaining-user-location.html#Adjusting
4. User location guidelines for the Apple iOS platform:
   
   https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/Loc ationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2- SW1
5. If your app uses Bluetooth, camera, GPS, or another device feature, code a standby mode. That way, when the peripherals aren't in use for a pre-determined period of time, the accessory turns off or goes into standby mode. As you'd expect, reducing the power consumed on the device preserves the battery life, and allows users to access your application for longer sessions.
6. Another technique for saving battery life is to turn GPS off when the device is not moving. You can use the device's accelerometer to verify that motion has started, and then re-engage the GPS. For instance, if the user is traveling with the device, the battery savings at red lights can quickly add up.
7. There are specific best practices for using Bluetooth in your application available on Microsoft's MSDN® site Best Practices for Creating Bluetooth Applications.

The following research observations and suggestions pertain specifically to using GPS in an application. GPS is one of the most commonly accessed peripherals, but it is often used inefficiently.

GPS Observations

When testing various applications, we have found multiple examples of apps that instruct the device to continually access the GPS for data, even when the device could not get a GPS fix.

In one test, a 45-minute trace, the app constantly used the GPS in an active state, draining the battery and slowing the app. The GPS peripheral should have timed-out after a specified period of stasis, but it did not. That's why it's important to consider a fail-safe. When the GPS is instructed to turn off, the application should try to turn it off again after a certain amount of time.

When using GPS, you should think carefully about the level of accuracy needed. For example, when the application is determining a local TV station or identifying the local sports teams, a network location would probably be accurate enough, making GPS access unnecessary.

GPS Suggestions

As you can see, the challenge when using GPS in your application is in how to balance the need to provide an accurate user location while still achieving good performance. The Dev Guide on the Android Developers web site has some very useful tips for how to do this, in the topic: Best Practices for Obtaining User Location.

The following development suggestions about balancing accurate location information with application performance are taken from that topic:

• Evaluate the level of accuracy that is needed for your application, and the environment in which it will be used. Depending on these factors, you may only need to use the Network Location Provider or GPS, instead of both. Using only one service will reduce battery usage.
• If the size of the window in which the app listens for location updates is reduced, it will interact less with GPS, and use less battery. The trade-off is that there will be fewer locations from which to select a best estimate.
• You can reduce the rate of location updates by increasing the interval time and minimum distance change in the requestLocationUpdates() method. This will improve battery efficiency but decrease accuracy. Again, this depends on how your application is used.

Note: Developers must comply with AT&T's Privacy Policy and Practices when obtaining an AT&T's users location.