Background Process to scan the location of the user at regular intervals and update the local database even when the app is not open

Question

I am creating an app that checks for user locations every half an hour and updates the location of the user in the local database and then runs CRUD queries based on the use

Answer 1

1. I think for this requirement, Thread and inside it AsyncTask -- this structure will be useful.

In link provided by you, it is mentioned very nicely here

2. For location related blog, you can check useful materials here :

(1) Difference between Google Map Distance and Directions API

(2) Check this answer also

Hope this will help you

Answer 2

When recording the users position use a service with a notification. Just for the sake of creating a morally responsible app that informs the user the app is tracking them. The service by definition runs in the background.

A fused location provider with setinterval(long) 30 minutes gets the interval. Set fastestInterval() to a minute to receive GPS data when other apps are using the GPS.

Answer 3

I think you are looking for something similar to WakefulIntentService. This handles all your cases completely.

You can do your location and db related work inside doWakefulWork() of said implementation.

Answer 4

I've done what you are looking for, both with GPS and non-GPS.

The project I took as staring point for the non-GPS solution already does all you need, and is battery-friendly (credits should go to Kenton Price):

https://code.google.com/p/little-fluffy-location-library/

Take a look at it, it works like a charm. Just run it in any device. If you need any help customizing just let me know.

Just edit the "onReceive" method in the "TestBroadcastReceiver" to update your DB.

If you need the GPS solution let me know too, but I dropped it for being a battery killer!

Hope it helps.

Answer 5

Have you considered using a SyncAdapter. Its best to schedule jobs at fixed interval and also optimized for battery usage. Also, once started, it can run independently of the app. As per your requirements, I believe this is best suited for your need. You can read about this here. This also removes the corner case of starting the service (generally used) when your device is restarted. Your app will still continue running the scheduled job even if the device gets restarted.

In the SyncAdapter you have to use a ContentProvider so wrap your DB inside a ContentProvider. Also, preferably use a CursorLoader to run longrunning tasks on DB. You should read about CursorLoader. This is a great way to access your resources. Also, you can define an Observer Design Pattern which Observes for changes in a DB and will perform a task when changes are made in DB. This can also be used inside your application itself and also inside SyncAdapter. Cursor Loader is best preferred for background work on DB. You can perform all CRUD Operations using a CursorLoader and ContentProvider.

Answer 6

This cannot perform multiple tasks

Yes, it can. It has only one thread, and so it can only do one simultaneous task.

i have to get the location of the user and scan the database , update the database (3 tasks)

I have no idea why you think that is three tasks. You cannot do them simultaneously.

Your bigger problem with IntentService is that getting location data is asynchronous, and IntentService is not well-suited for calling APIs that themselves are asynchronous.

But since i feel it would be a long operation with the local database, i feel i should ignore this one.

The point behind any service is for "a long operation".

Basically i looking for something like a CRON JOB that runs on a local database while working on the location data

Use AlarmManager to trigger a WakefulBroadcastReceiver, which then triggers a Service. The Service, in onStartCommand(), forks a background thread to (asynchronously) retrieve the location and update the database. The Service can then call completeWakefulIntent() on WakefulBroadcastReceiver, plus stopSelf() with the startId received in onStartCommand() for this work, plus allow the thread to terminate. If no other commands were received in the interim, the service will shut down.