skyhigh wrote: > "Note that when you write an activity, you can make it stop or > continue running when it is moved to the background (see onStop() in > Activity Lifecycle). For activities that download data from the > network, it's recommended to let them continue downloading so the user > can multi-task." > > As far as I was aware I had to create a service if I wanted to have a > background activity such as a media player, internet download, or > processing of data in files on the SD card continue when the activity > was no longer in the foreground. > > I went and reread the onStop information on the "Activity Lifecycle" > page, which was referred to. But I didn't find any mention of how an > activity might continue to run in the background after onStop was > called.
Let's ignore activities, services, and the like for a moment. Your Android application, at its core, is an instance of a Dalvik VM, inside a process, with a thread and a message queue. The thread blocks on that queue, pops off a message if there is one there, and takes action based on that message (called "dispatching" back in the bygone era of Win16 programming). Some of those messages will cause an activity to be created (e.g., an activity Intent for your activity is received). Some of those messages will call callbacks into your code (e.g., onCreate() of an activity, onCreate() of a service, onClick() of a View.OnClickListener). As components like activities and services get destroyed, they are (hopefully) garbage collected and no events pertaining to them will ever get onto the queue. When there are no more components running, Android can shut down the rest of the application scaffolding and mothball the process/VM for later reuse. This, however, only deals with the main application thread. You can have other threads, that you fork yourself or that are forked for you (e.g., AsyncTask thread pool). Those threads do not have a message queue (unless you heave a Looper at 'em) and can do whatever you want. So, is there a case where "an activity might continue to run in the background after onStop was called"? That depends on how you define "run" and "activity". Your own threads will continue to run after onStop() is called. If you wish to consider those threads as being part of some activity, so be it. The main application thread will not be calling into your activity while it is stopped. Personally, I prefer to have my threads either be totally "fire and forget" with an AsyncTask, or else be managed by a Service, because of all the joys from dealing with activities coming and going (e.g., screen rotation). But, that's just me. > "In addition, not all activities have the behavior that they are > destroyed when BACK is pressed. When the user starts playing music in > the Music application and then presses BACK, the application overrides > the normal back behavior, preventing the player activity from being > destroyed, and continues playing music, even though its activity is no > longer visible — as a visual substitute, the Music application places > a notification in the status bar so the user still has an easy way to > get to the application to stop or control the music. Note that you can > write an activity to stop when its screen is no longer visible, or to > continue running in the background — the latter was chosen for the > music player." > > Is the information on these pages accurate? Looking at the code, it would appear they use a service. > If the user stays on my activity screen while the background service > processing is running everything works fine. But if they press the > home key and do some other tasks, getting back to the correct activity > stack from the service notification icon is the area where I am not > understanding how to bring that existing activity stack back to the > foreground. Off the cuff, I am not certain that is possible. > As far as I can tell the only way to prevent the service notification > intent from creating a new instance of the activity is to set the > activity launchMode to singleInstance. However that requires the > activity to be the root of a task and so prevents it from being part > of an activity stack. In my case this activity can be reached from > more than one activity, and I need the activity stack to function > correctly so it will return back to the right place. FWIW, the music player (MediaPlaybackService) uses an Intent with the Intent.FLAG_ACTIVITY_CLEAR_TOP flag. I'm not sure that will help you, but I figured I'd mention it, since I'm looking at that code now. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android App Developer Books: http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
