3 Steps for Shutting off GPS and LocationManager on Android

While the code for shutting off the LocationManager on Android is straight forward, sometimes just one misstep and you can spend hours trying to figure out why it doesn’t work. What will happen is you will see in your code that the LocationManager and perhaps even the listeners will be null and the GPS active icon will continue to display and your battery will drain faster than you ever thought possible. There are a bunch of comments already on Stack Overflow about this problem, so this post attempts to consolidate answers and provide some straight forward steps to help with the most common mistakes.

First let’s review the steps for properly shutting LocationManager down:

Step 1. Remove the listener or listeners. If you are using both GPS and network providers you have to remove both. It sounds oversimplified, but you can only remove the exact listener that is associated with a particular instance of the LocationManager. It’s a one-to-one relationship.

Step 2. Set LocationManager to null.

Step 3. Set listeners to null.

Here’s what the code looks like, the names should be self explanatory:

if(_locationManager != null){

    _locationManager.removeUpdates(_locationListenerGPSProvider);

    _locationManager.removeUpdates(_locationListenerNetworkProvider);

    _locationManager = null;

}

if(_locationListenerGPSProvider != null) {

    _locationListenerGPSProvider = null;

}

if(_locationListenerNetworkProvider != null){

    _locationListenerNetworkProvider = null;

}

If these steps don’t work and the GPS icon continues to display, then there are potentially two reasons why:

Reason 1. You have instantiated intentionally or accidentally more than one copy of LocationManager and/or a listener. This is by far the most common and frustrating reason. The easiest way to avoid this mistake is to only start the LocationManager via the onResume() event, and shut it down using onPause(). Carefully control what is allowed to start and stop it. Be mindful when passing around instances of LocationManager between different Activities whether it is a singleton, static class or simply a reference to the actual object. If LocationManager is already running and you spin up a new instance, then you may not be able to shut it off programmatically and you’ll have to manually shut it off.

Reason 2. Something else other than your app is causing the LocationManager to run. This can easily give the appearance that it has not been turned off via your app. Repeated testing can eliminate this as a possibility, and to make sure you can shut off all other non-essential applications that use location.

References

Android Activity and Life Cycle

Migrating from Desktop to Mobile: 6 steps for success

If you have only one web site that is built for desktop browsers then you definately need to read this post. The one-size website-fits-all days are gone along with the AMC Gremlin. Mobile is a much different world than desktop and your visitors, users and customers will know that. This post is based on a presentation that I did at GIS in the Rockies 2012, and another blog post I wrote called 3 Steps for Determining if Your Website is Mobile Ready.

The presentation mentions GIS, or Geographic Information Systems, however it applies to anyone considering mobile.

Why care about mobile? For once the internet analyst firms are clear on one thing: mobile device sales have  surpassed desktop sales world-wide, yep I mean not just in the good ol’ U.S.A, around January’ish 2012. There are more than 835 million mobile users now, and studies show that people are spending the majority of their free time using their devices. And the patterns they use to interact with the devices are becoming ingrained and, for better or for worse, expected. And that expectation has reached a fervored pitch as the iPhone fanboys (and fangirls) demonstrated when the iPhone 5 launched. Everyone wants the latest and greatest even if it’s not all that different.

What about mobile user expectations? Mobile users have significantly different expectations on performance, look-and-feel, and capabilities. There are also differences between devices, for example as you may already know an Android user interface is fairly different from iPhone. Catering to those needs will boost your chances of success. So, here’s just a sampling:

  • Many different screen sizes. Typically smaller screen sizes and a wide vareity of screen pixel densities.
  • The mouse is gone. Navigation is done using fingers for gestures such as pinch and swipe. Greasy, french fry picking fingers are much less precise than any computer mouse.
  • Less memory. Phones have less memory and they can be slower than your high-powered laptop.
  • Poor internet connection. There are no gaurantees on a mobile internet connection, unless you happen to be dragging a CAT6 ethernet cable with you everwhere you go. Connections can be spotty and 4G connections can be inconsistent.
  • Battery life is awful. If you are at a conference, for example, using the phone heavily may kill the battery in  4 – 5 hours. Tablets are typically a bit better. In comparison, desktop computers are always plugged in.
  • Not all mobile devices are the same. iPhone and iPad run a different operating system from Android. Not only are the platforms completely different underneath, but users have different expectations of each platform. You can’t share the same code between iOS and Android, or even Windows Phone.

How about those six steps you mentioned? It’s these differences that really drive the six migration steps. And, these suggestions apply to all the different approaches to mobile whether you are building for mobile web, hybrid, native or responsive*:

  1. Start prototyping today. Let your developers loose to start playing and to get an idea the capabilities of different devices and operating systems. Have them use your existing web site content.
  2. Analyze your existing website usage. Use analytics tools such as Google Analytics to analyze what browser and operating systems your visitors are using. Look to see if there are any trends related to mobile usage. If you don’t use online analytics, there are also tools that can examine your existing web site logs.
  3. Reevalute all use cases and workflows. Mobile is so different from desktop. Refresh your approach on how to work your magic in that enviroment by taking into account how people use their smartphone everyday.
  4. Expect that you will need to rewrite code. Don’t try to make the code fit if it doesn’t meet the requirements. Besides, sometimes it’s a good thing to rebuild so that you clean house and bring a fresh perspective.
  5. Buy as many devices as possible. Since all devices are different, the more you can test on the better. For example, have as many types of Android and iOS devices running different OS versions on several different cell providers.
  6. Dig deep into browser differences. All browsers are different, especially mobile browsers. Check out caniuse.com as your next new best friend.

* A short note on Responsive websites. These use CSS3 media queries to detect and control what HTML content is visible to certain devices. CSS3 is generally considered to be one of the three technologies that together make up HTML5. Those three components are HTML (version 5) + Cascading Style Sheets (version 3) +  some new JavaScript APIs. NOTE: all three of these technologies are built into the browser by the browser vendors such as Google, Mozilla, Microsoft and Apple.

What do you really want in a future smartphone?

I’m voting for five simple things. Note, we are talking about smartphones here and not tablets. I look at the patent fights and all the junk functionality that is being crammed into the newest SDKs, and as a consumer all that I really want is all of the following bolted into one phone:

  • Significantly better battery life – My current phone won’t make it through a typical work day.
  • Faster battery charging time – My original Google Ion used to charge in less than an hour, my Atrix takes at least 2 hours and usually much longer.
  • Better default keyboard app – I probably make six mistakes typing one average length sentence because the tiny keys are so close together. Some third party apps have figured this out.
  • Better control over the camera app – I would stop carrying a separate camera if I could simply adjust f-stop and aperture.
  • Ability to read my screen in full sunlight with polarized sunglasses on – No chance of that on my current phone.

I’m fairly happy with the operating system software. And, my phone already has plenty of CPU horsepower and memory. It appears that in five short years the smart phone market has matured and the phone vendors are struggling to differentiate themselves. The current phone wars remind me of car ads on TV. Everyone is claiming incremental improvements that make your life better, easier or faster.  However, I propose there hasn’t really been any ground breaking innovation in smartphones since June 29th, 2007.

Now if there was a press release that said in the next version I could heavily use my phone for 3 days straight without a charge…that would get my attention!

What do you want in the next smartphone?