4

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?

codewithdk
  • 1,290
  • 1
  • 10
  • 23
  • singleton gets killed immediately after your activities were destroyed, i would rather stay with service – mayosk Mar 17 '17 at 09:11
  • @mayosk is it so? I don't think it will get killed even if I create the single instance in acivity. But anyway I would like to create it application onCreate() only. – codewithdk Mar 17 '17 at 09:16
  • make a test,, in your singleton create method which will every minute log something, try it when is your app visible, then go outside app and check – mayosk Mar 17 '17 at 09:36
  • @mayosk I`m not sure that it will be killed immediately, but in general you are right- Singleton Instance does not make the app unkillable by the system. Foreground-Service & return START_STICKY is what you want – X3Btel Mar 17 '17 at 09:39

5 Answers5

7

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

Community
  • 1
  • 1
David Wasser
  • 93,459
  • 16
  • 209
  • 274
1

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.

Andrey Danilov
  • 6,194
  • 5
  • 32
  • 56
0

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

albeee
  • 1,452
  • 1
  • 12
  • 20
  • But in my application, i want to listen to the location update even if the app is in the background. I know that battery is the main concern but it is negligible for my app. – codewithdk Mar 17 '17 at 09:20
0

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

Ishant
  • 148
  • 7
  • Sticky service also will get destroyed if the app is running in low memory but there is a possibility that app can still be running. – codewithdk Mar 17 '17 at 09:32
  • It shall be restarted by Android.. You can also use redeliver intent to get the data back... – Ishant Mar 17 '17 at 09:34
0

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

IIIIIIIIIIIIIIIIIIIIII
  • 3,958
  • 5
  • 45
  • 70