Erik Hellman wrote:
> Using
> intents would require some re-design, which is fine by me but I'm
> looking for the drawback of using this from a performance and power-
> consumption point-of-view. Do broadcast intents consume more power
> than direct service calls? Does sending, receiving and parsi
On Jul 6, 2:20 pm, Mark Murphy wrote:
> If your service is started via bindService(), it will be stopped
> sometime after the last client unbinds.
>
> If your service is started via startService(), it will run into somebody
> tells it to stop (stopService(), stopSelf(), Android terminating the
>
On Jul 6, 7:58 pm, Erik Hellman wrote:
> On Jul 6, 7:35 pm, Mark Murphy wrote:
> > 3. If you use binding to implicitly start your service, Android will
> > shut down the service when there is nothing else bound to it.
>
> ...and I don't want it to shut down because it will keep working even
> af
mjc147 wrote:
> This is probably relevant for nearly all type of music player-like
> apps because they need some kind of UI to get started but still need
> to continue playing once that UI has been exited.
And that's a fine reason for having a service. However, it's a rare
music player that is de
Erik Hellman wrote:
> Yes. But that is my question. What is most effective, considering
> performance, power-consumption and third-party integration (in that
> order); Using a service through AIDL or using Intents (with sticky
> broadcasts for service state)?
As Mr. Hearn indicated, this question
On Jul 6, 2:01 pm, Mark Murphy wrote:
>
> Or register a callback AIDL object with the service.
>
> Or use broadcast intents for the callback-style messaging, though these
> are subject to interception.
>
Yes. But that is my question. What is most effective, considering
performance, power-consumpt
Erik Hellman wrote:
>> 1. You actually get return values.
>>
> The flow of the application is asynchronous, so i would have to poll
> the service for updates in that case.
Or register a callback AIDL object with the service.
Or use broadcast intents for the callback-style messaging, though these
On Jul 6, 1:35 pm, Mark Murphy wrote:
> AIDL has a few huge advantages that may or may not be relevant to you:
>
> 1. You actually get return values.
>
The flow of the application is asynchronous, so i would have to poll
the service for updates in that case.
> 2. You don't need your service ru
On Jul 6, 1:28 pm, Mike Hearn wrote:
> First and most important question - do you really need a service at
> all? Many apps use services but don't actually need to run all the
> time. Using a service is like a tax on your user. It's currently
> invisible but it won't always be that way: expect yo
Beyond agreeing with what Mr. Hearn wrote, a few other points:
Erik H wrote:
> Also, is really an AIDL the right way to allow third-party
> integration?
AIDL has a few huge advantages that may or may not be relevant to you:
1. You actually get return values.
2. You don't need your service runn
It's a bit hard to say what design is right without details on what
the service actually does.
First and most important question - do you really need a service at
all? Many apps use services but don't actually need to run all the
time. Using a service is like a tax on your user. It's currently
in
11 matches
Mail list logo
