First of all, many thanks for the quick reply. On 24 Giu, 01:00, Mark Murphy <[email protected]> wrote: > 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. >
Ok, that's a good reason > > 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. > Nice, I missed the IntentService while reading the docs. > > 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. > Good point > > 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. > If I understood correctly, I need to bind to the service in order to provide it a listener, and then if I want to use the onProgressUpdate for an AsyncTask started from the service, I should notify the listener from the onProgressUpdate call. Is it correct? I thought that the standard way to update the ui from a service was to send an Intent (but in this way I wouldn't be aware of the state of the activity). Thanks again for the fast reply and sorry if I keep bothering you all. -- 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
