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] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
