On Wed, Jun 23, 2010 at 6:50 PM, Federico Paolinelli <[email protected]> wrote:
> Every single intent produces an action to be performed. Now the first
> question: should I start a service (maybe with non_sticky option?) or
> should I start a thread (or an async task) directly from the broadcast
> receiver?

Definitely the service. It is not safe for manifest-registered
BroadcastReceivers to fork threads. The receiver is destroyed shortly
after onReceive() ends, and that leaves your thread in limbo.

> If I start a service, should I do all the stuff in its body, or should
> it start a thread.

Ordinarily, I'd use an IntentService, which automatically does the
"stuff" on a background thread, via onHandleIntent(). However, your
later points start wandering away from the broadcast receiver into
activities and services and UI updates, which means you may want to
just use an ordinary Service that you can have the activities bind to.

> I should do the heavy job in a thread if there are time consuming
> operations, but what if the gui of my application is just an activity
> with the options and a button to start the service. What is the point
> in keeping the main thread busy?

That is your UI today. It might not be your UI tomorrow. Also, the
main application thread is at foreground priority, and so anything you
do in that thread will hammer whatever is in the foreground, such as
that real-time game that the user is trying to play.

> Do I risk to be killed for not being
> responsive?

Absolutely.

> I read here and there that I can update the gui from a background
> thread. Can I do that even if it is started from a service?

Yes, though that gets a bit tricky for services that are reacting
(indirectly) to broadcast Intents.

> The AsyncTask's onProgressUpdate is said to run in the application
> main thread, but if the application is made of different activities,
> who tells me which activity is the user looking at while the thread is
> doing all its long work?

You would have to keep track of that yourself. For example, you could
bind to the service in onStart() and unbind in onStop(). While bound,
register a listener with the service to be notified of any events. The
service calls the listener when an event occurs. No listener means no
activity to notify.

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version 1.6
Available!

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

Reply via email to