Android: Singleton Instance vs Service

Question

Here I want to ask one basic question which I couldn't find the answer while iam doing code.

As I understand, creating a singleton instance in application onCreate() is having less vulnerable than android service. In my application, i want to listen for location update which should have less likelihood to get destroyed. If I keep service it might get killed in low memory but still, the application can run in the background which would keep the instance. So I would like to go with singleton instance rather than service.

Is it a right approach?

Answer 1

Android can (and will) kill background processes in low resource situations, and also sometimes just because it wants to (especially on low-end devices in order to conserve battery and memory resources). It does this by killing the OS process hosting your application . In this case, your app will no longer be running in the background and therefore any singleton you may have created in Application.onCreate() will also be gone.

Android knowns nothing about your singleton and therefore has no reason to restore it.

However, if you create a Service and that Service returns START_STICKY from onStartCommand() , this tells Android that your Service wants to remain running all the time (if possible). In this case, if Android kills the OS process hosting your Service (due to resource constraints, or just because it wants to), Android will then automatically restart your Service (because Android knows about your Service and knows that it wants to run all the time). This is the correct way to do this.

NOTE: There are some devices (notably Chinese devices like Xiaomi, also Huawei, LG, Lenovo and others) that do not automatically restart STICKY services. These devices maintain a list of "protected apps" or "priviledged apps" that are allowed to run in the background and Android will only restart STICKY services for applications that are in this list. You will need to get your user to add your app to this list by hand . There is no way to programatically add your app to this list on these devices.

See https://stackoverflow.com/a/42120277/769265 and https://stackoverflow.com/a/41369032/769265

Answer 2

Best practice is creating Singleton instance in Application class.

So it will be available while Service or Activity exists.

Also you can use Foreground Service , which is not killed if low memory detected.

And also you can handle low memory event in Application class or onDestroy in Service and serialize data to SharedPreferences. With START_STICKY service will be restarted as soon as possible.

Answer 3

If you ask my opinion, I wouldn't recommend either. Because both sucks user's battery in the background.

What I would do is - get location updates only in the foreground in main activity. Also start using Google play services FusedLocationProvider instead of implementing android default one.

Remove location updates when your app goes background. All guidelines are here in android developer site.

https://developer.android.com/training/location/receive-location-updates.html

Answer 4

I think your problem lies in maintaining the component 24 by 7 by 365 so as to manage location.

You can maintain your service to start again in case it is destroyed by managing returning flag from onStartCommand. START_STICKY etc..

Read out more here: https://developer.android.com/reference/android/app/Service.html#START_STICKY

Answer 5

Based on your description I would suggest to take a Foreground-Service . Tracking the users location uses a lot of batterie. So your users should always be aware of the fact that your app is still up and running.

You are also preventing the system to kill your app that way.

A foreground service is a service that the user is actively aware of and is not a candidate for the system to kill when low on memory Source