>>>>> "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
