0

Background: I dump some data in the Application class, and save it to files after a short interval or when the app goes to background (say, when the user presses the Home button or the Task-switcher button). I don't want to use onPause() of Activity class because there are many activities in the app, I have to check onPause() for all of them. And onPause is also called when I jump from one activity to another in my app (which creates unnecessary saving action).

Question: Is there a universal event fired when the app going to background, regardless of which activity it is at?

Thanks

EyeQ Tech
  • 7,198
  • 18
  • 72
  • 126

2 Answers2

1

Check the below code continuously means u can use Timer class.

ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
List<RunningTaskInfo> runningTasks = null;
try {
    runningTasks = activityManager.getRunningTasks(1);
} catch (Exception e) {

}
RunningTaskInfo runningTaskInfo = runningTasks.get(0);
ComponentName topActivity = runningTaskInfo.topActivity;
if(topActivity.getPackageName().equals(your packagename)){
   S.o.p("fine");}
else{
   S.o.p.("application sent to background");}
user543
  • 3,623
  • 2
  • 16
  • 14
  • Thanks, this is indeed a good way to track your application status, but actively rather than passively receiving event. Looks like there is none as other answer points out. – EyeQ Tech Jan 15 '14 at 07:29
0

onStop() is called when activities are hidden from view, i.e. the user pressed the home button. onPause() is only used when an Activity is hidden, that is, partially visible due to some overlap. Of course, onPause() is called right before onStop() is called. You can see all of the lifecycle over at Android Developers. I would encourage you to work with the lifecycle and not against it. Save your data when the state changes.

For scheduled data storage, I would suggest you use a timer. As you commit all the data to the application context, and you can live with fewer recovery points, I would suggest storing the date in the onDestroy() call. If not, I suggest implementing a TimerTask to schedule regular serialisations of your data.

To answer your question, no! It simply is not Android to consider your application in total and have one lifecycle. You have one lifecycle per activity and all activities are tied together by a stack and their respective lifecycles.

Eric Tobias
  • 3,225
  • 4
  • 32
  • 50
  • tks for your tip on sheduled data storage. Back to the `onStop()` thing, your solution is also tied to Activity class, rather than the Application. That's not what I want, because I said there are so many activities, if I use that I have to inject that code to every onStop() function. – EyeQ Tech Jan 15 '14 at 06:47
  • You can extend `Application` and use that class as your context. http://developer.android.com/reference/android/app/Application.html However, keep in mind that the class cannot react to the same lifecycle as activities. Maybe you can play with ` registerActivityLifecycleCallbacks()` but I have no experience with it. A scheduled timer seems to be your best bet as you want timed executions. – Eric Tobias Jan 15 '14 at 06:58
  • Tks for your tip. Yes I save on schedule, but I'm trying to prevent bad thing that happen between saving points, since the user can switch to other app and my app got killed due to low memory. Anyway, I can try the method you mentioned. – EyeQ Tech Jan 15 '14 at 07:24
  • For that purpose you should, as recommended by developers, use the lifecycle changes of activities to save your data when they pause or stop and restore data when they resume. Try to work with the API and use it rather then coding around it. See http://developer.android.com/training/basics/activity-lifecycle/recreating.html#SaveState – Eric Tobias Jan 15 '14 at 07:48