This is a common enough misunderstanding, I feel it makes sense for me to toss in my own two cents here: a major contributor to the misunderstanding is that the Android online documentation blithely uses the word 'background' in a sense unexpected for the context. In the documentation for the Service classes, when they call the work done by the Service 'background', what they mean is that the Service is running in the -UI- background, i.e., with no focus (the Activity that starts the Service typically keeps the UI focus) It does NOT mean in a background Thread.
Add to that the fact that one of the most common reasons to use a Service in the first place is to offload from the UI thread, and we have all the ingredients for serious and common confusion. The truth is that any Service that really is being used to offload from the UI thread = main thread, must somehow spin off its own new Thread and do the lion's share of the work there. IntentService is one way to to this; AsyncTask offers a similar capability, but must itself instantiated from the UI Thread. Both of these do the Thread management for you, but assume that what you are trying to do really can be done with a particular threading model: create one new worker Thread associated with one new work queue. If you need a more complicated model, you need to either do your own Thread management, or figure out how to use MessageQueues to do it, likely using Looper and Handler. As for your question about 'this' for IntentService, by OOP, every IntentService object is also a Context, so you really should not need to do anything different. I can't even see that adding an explicit cast would help. It should not. On Feb 23, 2:06 pm, Jake Colman <[email protected]> wrote: > >>>>> "MM" == Mark Murphy <[email protected]> writes: > > MM> On Wed, Feb 23, 2011 at 11:50 AM, Jake Colman <[email protected]> wrote: > > >> Looks like the basic difference is that IntentService will > >> automatically spin off a worker thread do the work as opposed to > >> doing in the Service itself? But if the Service is already in a > >> running context unto itself, what is the benefit of splitting its > >> own into yet another thread? > > MM> A Service does NOT run on its own thread. Just as an Activity > MM> does not run on its own thread. Just as a BroadcastReceiver does > MM> not run on its own thread. > > MM> Rather they ALL share ONE thread -- the main application > MM> thread. There are serious limitations as to what you want to do > MM> on that thread, to avoid "janky" UIs and "ANR" crashes. > > So although a service would work from the perspective of off-loading > work from an appwidget, it's still doing it off-loaded work in the same > thread? So in what sense is it off-loaded from the appwidget? > > I've converted my Service class to an IntentService, moved all my > logic into the onHandleIntent() method, and moved my state variables > into the default shared preference. All the pieces seem to be working > but, much to my surprise, RemoteViews updated by the IntentService is > NOT being painted on my screen! > > Is there something different about Context when using an IntentService > in place of a Service? My original code used the 'this' as the context > and passed that to construct the RemoteViews. Do I need to do something > different now that I am using an IntentService? If so, why? > > -- > Jake Colman -- Android Tinkerer -- 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
