Ouch! You can't do blocking operations in the event loop thread of either an Activity or a Service without the component becoming non- responsive. You can't send messages to an Activity by broadcasting a message because an Activity is not a BroadcastReceiver. You can run one foreground Activity at a time and many Services at the same time (theoretically) in a single process. They all have active event loops.
On Jan 19, 4:17 pm, Kevin Duffey <[email protected]> wrote: > Interesting. I've got to read up on services more. I thought when you start > a service it's a new application that is running along with other background > apps. Essentially, I thought you'd have the foreground app PLUS a background > app running. When the foreground app closes, the background keeps on > running. I also read somewhere where you have the background service start > when the phone boots by listening for some intent or broadcast message. > Again I have to refer to Mark Murphy's books.. he explains this really well, > I just read most of it but haven't practiced it yet so it is escaping me. > > If you can start a background service and it polls, then you probably need > that background service to broadcast a message so that when the foreground > app is actually in the foreground and running, it can respond to the message > to get the data. I am not sure (again) how that is accomplished, but that > should be the basic idea. > > On Tue, Jan 19, 2010 at 3:37 PM, Nathan <[email protected]> wrote: > > I haven't implemented something like yours yet, but I plan to. > > > From all I've read, an activity starting a service will launch it on > > the main thread. That's probably why it seems to lock the UI. > > > So what you probably need is a Service that starts an AsyncTask. The > > service's status could still be accessed by the Activity's main thread > > while it's open, and the service could potentially live on. > > > Nathan > > > On Jan 19, 3:23 pm, Flapjack <[email protected]> wrote: > > > Thanks for the replies. Kevin, what I'm trying to accomplish is > > > [seemingly] very common in the mobile world: > > > > 1) User starts app > > > 2) App retrieves info from remote server based on the User's > > > interaction with the app > > > 3) When app is not in focus (or closed) a background service continues > > > to retrieve updates from remote server > > > > For point number 2), I understand that I could simply use a background > > > thread (eg. AsyncTask), since the data is to be returned to the > > > current activity. But for point number 3), a simple background thread > > > is not appropriate. > > > > My question is this: Since I will need to write a service to perform > > > [much of] the same functionality in point 3) as my background service > > > will be performing in point 2), wouldn't it just make more sense to > > > skip the background thread and perform all of my polling through the > > > service - and simply call that service from within whatever activity > > > may need it at the time? But that raises another question: calling a > > > service from an activity seems to lock the UI - so when polling remote > > > servers, shouldn't the service either be run in a new thread, or > > > rather, shouldn't the service spawn its own thread? > > > -- > > 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]<android-developers%[email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en
-- 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
