Background:<\/strong> We found that Location handling was really one of the areas in android app development where there was some persistent confusion. Trainee staff in our own team had to be explained how to map user requirements to a workable location strategy.<\/p>\n Excluded:<\/strong> Actual code for implementing the fused location which we will look into in a subsequent article.<\/p>\n LEVEL:<\/strong> BEGINNER TO INTERMEDIATE<\/div><\/div>\nBackground:<\/strong> We found that Location handling was really one of the areas in android app development where there was some persistent confusion. Trainee staff in our own team had to be explained how to map user requirements to a workable location strategy.<\/p>\n COVERAGE:<\/strong> Code snippets provided without full working code.<\/p>\n LEVEL:<\/strong> BEGINNER TO INTERMEDIATE<\/p>\n Lets Assume the following use cases for the application of this article: Tackling Location Permissions in Android<\/p><\/div>\n If you see carefully, case a), b) , c) are somewhat similar in the sense that a periodic tracking is required whereas case d) is mainly that of retail shops \/offices at a single point where periodic tracking of the service provider is not required to know of his location. Just a user initiated update is enough.<\/p>\n How to provide periodic Tracking from the Mobile Phone itself?<\/strong> And this brings us to an important Question, which is: <\/p>\n First up, location was earlier requested through android.location API<\/strong> but since 2014, Fused Location through Google Play Services<\/strong> has been available to get location updates. This is compatible Android 2.3 onwards, so pretty much covers all devices.<\/p>\n Fused location has many advantages and is a recommended way of getting location details according to Google. We assume here that you would know it’s background but if you don’t check out the details here<\/a>.<\/p>\n So coming back, lets look at how location permission is saved in a typical android phone (Nougat, Marshmallow included).<\/p>\n A) Either the location is completely off. Fused location provider<\/strong> API (now FusedLocationProviderClient) actually takes care of all these situations and removes the guesswork by automatically changing the appropriate system settings based on desired accuracy and available options \/permissions.<\/p>\n Typical run-time Location Permission Popup in Android<\/p><\/div>\n <\/div> Power Consumption options when choosing Location in Android app<\/p><\/div>\n <\/div><\/div>\n Keep in mind that many a times networking or low power or what is denoted by COARSE_LOCATION Permission will SUFFICE for your needs. According to Google the accuracy is 50-100 metres for COARSE_LOCATION. If you are in suburb or city in India, i think we can take a worse case scenario of 75-100 metres accuracy.<\/p>\n I would say that this is sufficient for most logistics and delivery app situations such as b) and c) and definitely acceptable for case d). Another aspect that we found was that in many cases, developers had made GPS usage mandatory<\/span> even when unnecessary. <\/p>\n GPS is mainly necessary for Taxi or Cab hailing apps: where a more frequent update of location as well as direction and speed calculations are required. Practically, one should set Limits of accuracy and \/ or update as per the business requirements. More frequent or more accurate location settings will lead to greater battery drain.<\/p>\n The App may also provide the user, options to change his \/ her location settings if he or she wants to – taking full benefit of the location feature. Ideally, it should work with the low power setting also, except where GPS is compulsorily required – such as a cab hailing App. As a far as permissions are concerned if location is required regularly, it would be better to take permission on install but switch location services off whenever not needed. If it is infrequent or based on a specific activity or event then you can give permissions at Runtime. In order to use the location services provided by Google Play Services Fused Location Provider, connect your app using the Settings Client, check the current location settings and prompt the user to enable the required settings if needed.<\/p>\n Import Google Play services from Android SDK (..\/sdk\/extras\/google\/google_play_service\/libproject\/google-play-services_lib) as a library in your application<\/p>\n In this case lets assume we have a case where infrequent location updates are fine – say every 10 minutes is more than enough. Also lets assume a very high accuracy is not required and we can do with 100 metre error. Typical settings in such as scenario would probably be like this: After creating the locationRequest – get the current location to begin with: Apart from this, you can also get the Current Location Settings, prompt user to change settings if required (an optional step in most cases) as explained here<\/a>. NOW you are ready to get the regular Location updates which is required for Tracking.<\/p>\n The API updates your app periodically with the best available location, based on the currently-available location providers such as WiFi and GPS (Global Positioning System). The accuracy of the location is determined by the providers, the location permissions you’ve requested, and the options you set in the location request. <\/p>\n private void startLocationUpdates() { So startLocationUpdates is the main method which is passing the LocationRequest object and Callback. mLocationCallback = new LocationCallback() { Stopping or Pausing a Location Request <\/strong> private void stopLocationUpdates() { Note:<\/span> The important thing to be kept in mind is that the above examples show location requests based on a specific activity but if your requirement is such that tracking continues even if application is in background then you need to use a background service and get the current location. In that scenario , you do NOT need to request Location updates as the background service itself can be run periodically and just get the current location. Further , here the settings need not be configured to Reflect the Fastest interval and just the Accuracy to BALANCED POWER would be enough.<\/p>\n Another option could be to use PendingIntent as explained here<\/a> to get location in background cases.<\/p>\n
\nThe client requires that your mobile app show the nearest service provider to him – it could be
\na) A Cab Hailing App
\nb) A Trucking \/ Commercial Vehicle app
\nc) A Delivery and Logistic app
\nd) A Service provider such as a Carpenter \/ Electrician, Beauty Salon<\/p>\n![\"Handling](\"http:\/\/www.creativesparksolutions.com\/blog\/wp-content\/uploads\/2017\/10\/mainimage.jpg\")
\nSo, in the above scenarios a), b), c) a periodic updating of the location – latitude and longitude is required by the app. We’ve generally seen this done by an API which saves the provider’s location periodically into the database and the android activity can retrieve the lat, long of the chosen provider in the activity’s view from the database. The trick is to do this with proper permissions (chosen either on opening app or install etc.) , and with only the required battery consumption.<\/p>\nWhat is the best way to provide location permissions when developing your Android App?<\/h3>\n
Situations your Android app must tackle when seeking location updates<\/h3>\n
\nOR
\nB)if the Location setting is on – then
\n1) Whether GPS option is on (High Accuracy)
\n2) Whether Networking or Wifi (Low Battery setting) use is On<\/p>\n![\"Typical](\"http:\/\/www.creativesparksolutions.com\/blog\/wp-content\/uploads\/2017\/10\/runtimelocationexample.jpg\")
![\"Power](\"http:\/\/www.creativesparksolutions.com\/blog\/wp-content\/uploads\/2017\/10\/location_services_screenshot1.png\")
Settings and Permissions Strategy<\/h3>\n
\nTherefore, do not restrict the user to use GPS only; unless it’s a business requirement.<\/i> <\/p>\nSteps in getting Location Updates in Fused Location (Location services Android Tutorial)<\/h3>\n
1. Setting the Permission<\/h4>\n
\n{
\nmanifest xmlns:android=\"http:\/\/schemas.android.com\/apk\/res\/android\"
\n package=\"com.google.android.gms.location.sample.locationupdates\"
\n
\n\/manifest
\n}
\n<\/code><\/p>\n2. Create a Location Services Client<\/h4>\n
\nprivate FusedLocationProviderClient mFusedLocationClient;
\n\/\/ ..
\n@Override
\nprotected void onCreate(Bundle savedInstanceState) {
\n \/\/ ...
\n mFusedLocationClient = LocationServices.getFusedLocationProviderClient(this);
\n}
\n<\/code><\/p>\n3. Getting the Last known Location <\/h4>\n
\nmFusedLocationClient.getLastLocation()
\n .addOnSuccessListener(this, new OnSuccessListener
\n @Override
\n public void onSuccess(Location location) {
\n \/\/ Got last known location. In some rare situations this can be null.
\n if (location != null) {
\n \/\/ Logic to handle location object
\n }
\n }
\n });
\n<\/code>
\nNote that null handling has to be done as in some scenario location may not be returned. Also, the above step is not really necessary if we’re requiring periodic location updates.
\nTo get periodic location updates, and in our own control we need to set up a Location request client and get location requests from it at pre-configured periodic intervals. <\/strong>
\nAnd to do this you have to define all these configuration settings. Which brings us to Step 4.<\/p>\n4. Set Update interval, Fastest update interval and Priority Configuration for Location Updates.<\/h4>\n
\n
\nprotected void createLocationRequest() {
\n LocationRequest mLocationRequest = new LocationRequest();
\n mLocationRequest.setInterval(900000);
\n mLocationRequest.setFastestInterval(600000);
\n mLocationRequest.setPriority(LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY);
\n}
\n<\/code>
\nSo as you can see – we’re defining these settings in the LocationRequest<\/strong> object just created. We have the setFastestInterval as upper limit for any location update (which other apps may also be getting ) to be used by you. So for us since 10 mins is the minimum and we can do with 15 minutes as well – we’ve kept the values accordingly (measured in milliseconds).<\/p>\n
\n
\nLocationSettingsRequest.Builder builder = new LocationSettingsRequest.Builder()
\n .addLocationRequest(mLocationRequest);
\n<\/code><\/p>\n5. Getting Regular Location updates from Fused Location.<\/h4>\n
\n@Override
\nprotected void onResume() {
\n super.onResume();
\n if (mRequestingLocationUpdates) {
\n startLocationUpdates();
\n }
\n}<\/p>\n
\n mFusedLocationClient.requestLocationUpdates(mLocationRequest,
\n mLocationCallback,
\n null \/* Looper *\/);
\n}
\n<\/code><\/p>\n
\nmRequestingLocationUpdates is a boolean flag which is used to indicate if location requests are ON or OFF by the user of the App.
\nNow the LocationCallback interface also needs to be implemented which actually gets the Latitude and Longtitude.<\/p>\n
\nprivate LocationCallback mLocationCallback;
\n\/\/ ...
\n@Override
\nprotected void onCreate(Bundle savedInstanceState) {
\n \/\/ ...<\/p>\n
\n @Override
\n public void onLocationResult(LocationResult locationResult) {
\n for (Location location : locationResult.getLocations()) {
\n \/\/ Update UI with location data
\n \/\/ ...
\n }
\n };
\n };
\n}
\n<\/code><\/p>\n
\nThis is an important option which can help reduce power consumption to stop getting location updates when not needed. For example, if it’s a regular saving of location in database but when your vehicle is stopping or in rest – on click of your Rest \/ Shift Completed button, the location updates could stop as there is no need to track you. This could even be time based.
\n
\n@Override
\nprotected void onPause() {
\n super.onPause();
\n stopLocationUpdates();
\n}<\/p>\n
\n mFusedLocationClient.removeLocationUpdates(mLocationCallback);
\n}
\n<\/code><\/p>\n