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

Reply via email to