Note that using android:process on a Service doesn't change its semantics w.r.t. its main thread. No matter what process it is running in, the lifecycle callbacks happen on that process's main thread, and you don't want to block the main thread. Running the service in a process that doesn't have UI may make the problem less visible, but it is still there. For example, the system will at various points ask your process to do something -- to call your service's onStart() or to dispatch a broadcast or various other things -- and if it isn't responsive to that then it will be considered not responding and dealt with. For stuff that isn't related to UI, this is just a little different: the timeout is a bit longer (currently 10s) and if an ANR does happen on user builds the process will be silently killed rather than annoying the user.
On Sun, Sep 12, 2010 at 5:23 PM, Lance Nanek <[email protected]> wrote: > The non-default situation I was thinking of was there not being > anything like android:process=":remote" on the service declaration in > the manifest. Without any specific settings to prevent it like that > one, setting an alarm for a PendingIntent from > PendingIntent#getService will start the service on the same main/UI > thread that the activities in the app run on. > > On Sep 12, 6:29 pm, Indicator Veritatis <[email protected]> wrote: > > But just as you say, that is by -default- that it is on the same > > process and thread. Now does anyone actually use it with that same > > process being an Activity? Often (though not always), it is launched > > by an Alarm, not by the main process hosting the UI thread in the > > first place. Then it is the Service that sends messages to the > > Activity that currently has the UI. > > > > Now since the whole purpose of AsyncTask is to provide communication > > and coordination between a UI thread and a worker thread (more > > conveniently than with java.lang.thread), it might make sense to use > > AsyncTask in a Service only if the Service itself has a UI thread. But > > although the docs you mention admit to this possibility, I am having > > trouble seeing why that would ever be good design. > > > > But knowing this group, if there are any such, someone will pop up out > > of the woodwork and show us:) > > > > On Sep 11, 2:36 am, Lance Nanek <[email protected]> wrote: > > > > > > peculiar problems in the way the classes are designed. Service by > > > > definition is already in the background, it HAS no UI thread, so why > > > > > Services, by default, run in the same on process and on the main/UI > > > thread. > > > > > >http://developer.android.com/reference/android/app/Service.html > > > > Note that services, like other application objects, run in the main > thread of their hosting process. This means that, if your service is going > to do any CPU intensive (such as MP3 playback) or blocking (such as > networking) operations, it should spawn its own thread in which to do that > work. > > > > > On Sep 11, 4:55 am, Indicator Veritatis <[email protected]> wrote:> > Option 4 certainly sounds like it will work, but it suggests some > > > > peculiar problems in the way the classes are designed. Service by > > > > definition is already in the background, it HAS no UI thread, so why > > > > do I need an AsyncTask there at all? The whole point of the latter is > > > > to communicate between UI thread and worker thread. > > > > > > As for documenting what works, I hope Google takes your hint and > > > > documents what the right way to do this really is. After all, these > > > > are the same people who keep warning us that "if it's not documented, > > > > then it is subject to change w/o notice". > > > > > > On Sep 10, 10:04 am, Mark Murphy <[email protected]> wrote: > > > > > > > On Fri, Sep 10, 2010 at 12:46 PM, Romain Guy < > [email protected]> wrote: > > > > > > Option #1 is a lot more intrusive. You lose the ability to > > > > > > automatically switch layouts, drawables, etc. > > > > > > > Worst-case scenario: > > > > > > > Step #1: Take your UI setup that is in onCreate() and move it to a > > > > > separate method (e.g., setupViews()) > > > > > > > Step #2: Call setupViews() from onCreate() > > > > > > > Step #3: Call setupViews() from onConfigurationChanged() > > > > > > > Done. ~4 lines of code. And it's the exact same code path that a > > > > > destroy/recreate will go down, so it's not like this adds unusual > > > > > performance overhead. There are certain circumstances where this > may > > > > > not work (e.g., GLSurfaceView and a game), but you needed to do > extra > > > > > work for those cases, anyway, to handle the destroy/recreate cycle. > > > > > > > > Saving and restoring an AsyncTask is not difficult. > > > > > > > No, it's not. The question is: is it reliable? > > > > > > > None of the AsyncTask documentation (class, article, etc.) covers > this > > > > > case. It *appears* that you can write an AsyncTask such that > > > > > onPostExecute() or onProgressUpdate() will not be called in the > middle > > > > > of the activity transition. However, that's not documented and > hence > > > > > not guaranteed, and so while I'll describe a pattern that seems to > > > > > work, I personally don't trust it any further than I can throw your > > > > > large Froyo lawn ornament. If somebody could give us the recipe > that > > > > > is guaranteed to work (i.e., works today, and is going to work in > > > > > Android 2.3/3.0/Turbo System 5000), that'd be *wonderful*. > > > > > > > Actually, I lied earlier. I'd choose Option #4: > > > > > > > Option #4: Don't do the AsyncTask in an activity. Use a Service and > > > > > have it do the AsyncTask, or use an IntentService if the sole > purpose > > > > > of the service is to do stuff in a background thread. In > particular, > > > > > an IntentService would be good for a download that you want to > happen > > > > > regardless of what may go on with an activity (e.g., Android Market > > > > > downloading an APK), and so you don't need to worry about canceling > > > > > it. > > > > > > > -- > > > > > Mark Murphy (a Commons Guy)http://commonsware.com| > http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > > > > > > Android Training in London: > http://skillsmatter.com/go/os-mobile-server > > -- > 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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
