0

I am using a passcode lock on my app. I set a varibale to true/false in shared preferences using the logic in this answer. But this approach doesn't work when I kill the app while still on foreground (using recent apps). Looks like killing the app kills my TimerTask which is scheduled for 2secs and hence the variable never gets set.

I have tried using services to do the same but no luck, even services get killed when the app is killed. Any workaround for this? Please help!!

Community
  • 1
  • 1
Pareek
  • 153
  • 11
  • What does the variable mean? – weston Jul 30 '15 at 13:24
  • Variable here is essentially a boolean type value stored in Shared prefs. – Pareek Jul 30 '15 at 13:31
  • I know, I'm asking what does it mean. I.e true means ... false means ... – weston Jul 30 '15 at 14:03
  • Sorry for the obvious reply, true here means that the application(not a particular activity) is no longer in foreground, false means that application is still on foreground. – Pareek Jul 31 '15 at 07:35
  • I see, well there is no need to store this off, you can test for in forground at anytime. See this http://stackoverflow.com/questions/3667022/checking-if-an-android-application-is-running-in-the-background/5862048#5862048 – weston Jul 31 '15 at 07:39
  • this will not work for me, as it will mark the activityVisible flag false in every activity transition. I only want it to be false if the app is no longer visible on foreground. Please refer to the link in question, I am using that approach now. But it has issues when I kill the app. – Pareek Aug 03 '15 at 09:57

2 Answers2

0

You can use Service with START_STICKY, which will be recreated after killing. Check AlarmManager for events that will be launched by system even if your app is closed.

I personally suggest using the AlarmManager, instead of keeping long-running services.

mhenryk
  • 551
  • 5
  • 13
  • Isn't AlarmManager same as TimerTask that I am using currently? – Pareek Jul 30 '15 at 13:32
  • TimerTask is a Java object while AlarmManager is a system service where you can post PendingIntents for delayed execution. Both could work here but like you say your application gets killed, and so is your TimerTask, AlarmManager is a system service and will send intent to a killed app too. Just keep in mind that since KitKat all Alarms are inexact, see documentation for more details. [AlarmManager](http://developer.android.com/reference/android/app/AlarmManager.html) – mhenryk Jul 30 '15 at 13:34
  • Thanks, this should solve my purpose. I will try this and let you know. – Pareek Jul 30 '15 at 13:43
  • I tried using alarm manager, but result the same. It doesn;t work in the particular case I have mentioned in question. – Pareek Aug 03 '15 at 09:57
0

The best way to execute background tasks in an efficient way is to use an IntentService

http://developer.android.com/reference/android/app/IntentService.html

An IntentService is going to run in a separate thread as long as the task requires and will be killed afterwards.

Also it will enqueue requests and deal with the queue itself

lgvalle
  • 3,712
  • 1
  • 19
  • 14