Jon,
ok, I see a big plus for this approach. For a simple trigger interaction I
don't have to define a service interface with a fake trigger method.
I am still a bit unhappy about passing in the wake lock using a static
variable, but well, I'll still go for this approach then.
Thank you, Di
On Mar 2, 8:11 pm, Mariano Kamp wrote:
> And why do you use startService instead of binding to it, get the interface,
> calls something, and get rid of the binding? I was under the impression that
> startService would be for something that runs in the background like playing
> an audio file.
You
Hey Marco,
actually I tried that and hit a ReceiverCallNotAllowedException
[1] . But after using the ApplicationContext this seems to work fine.
Cheers,
Mariano
[1]
http://lampwww.epfl.ch/~linuxsoft/android/android-m5-rc15/docs/reference/android/content/ReceiverCallNotAllowedException.htm
You can't use bindService from a broadcast receiver, since the
receiver might not be around long enough for your bind callback to
happen.
On Mon, Mar 2, 2009 at 12:11 PM, Mariano Kamp wrote:
> Thank you Jon.
>
> And why do you use startService instead of binding to it, get the interface,
> call
Thank you Jon.
And why do you use startService instead of binding to it, get the interface,
calls something, and get rid of the binding? I was under the impression that
startService would be for something that runs in the background like playing
an audio file.
2009/3/2 Jon Colverson
>
> On Mar
On Mar 2, 9:42 am, Mariano Kamp wrote:
> So how does that work?
Here's how nanoTweeter works (slightly abbreviated):
The alarm BroadcastReceiver's onReceive() acquires a WakeLock and
stores it in a static field so that the Service can access it later.
It then starts a Service using Context.star
So how does that work?
(1) I still have a Receiver that is invoked by alarms.
(2) I would bind to my service in the onReceive() method, (3) pass in a
ServiceConnection, and the onReceive() method invocation is done so far.
(4) Then I get notified via ServiceConnection.onConnected() that my service
Thread's should never be started in a BroadcastReceiver because the
containg task ends when the onReceive method ends.
The suggestion at
http://developer.android.com/guide/practices/design/responsiveness.html is;
"But instead of doing intensive tasks via child threads (as the life of
a Broadc
Yeah that is the correct way to do this.-
On Sun, Mar 1, 2009 at 10:50 AM, Jon Colverson wrote:
>
> I don't think it's valid to start a Thread in a BroadcastReceiver. The
> system doesn't know anything about that thread, so it wouldn't know
> that it's supposed to keep the process hosting it aro
I don't think it's valid to start a Thread in a BroadcastReceiver. The
system doesn't know anything about that thread, so it wouldn't know
that it's supposed to keep the process hosting it around. My app
nanoTweeter does similar background polling and I acquire the WakeLock
in the BroadcastReceive
On Sun, Mar 1, 2009 at 9:43 AM, Mariano Kamp wrote:
> Thanks for not giving up on me ;-)
>
> I thought about that, but the log shows that I acquired the lock and then
> nothing more happens.
Except in the last example you gave, where it doesn't even get to the acquire.
> Also I would need to us
Thanks for not giving up on me ;-)
I thought about that, but the log shows that I acquired the lock and then
nothing more happens.
Also I would need to use a Thread.join() in the onReceive Method to wait for
the thread to finish, which would lead to a long execution of the
onReceive() method.
If
One thing you might want to try is to grab the wakelock in the
receiver itself, not in the thread. The way it is now, it's
theoretically possible for the receiver to exit and the phone to go
back to sleep before your threads ever gets a chance to run.
On Sun, Mar 1, 2009 at 9:27 AM, Mariano Kamp
> I realized that almost immediately after hitting 'send' :),
Story of my life ;-) That happens all too often to me.
>but you still seem to be holding a wakelock for 30 minutes.
Yes, I do, but I think for the right reasons. I want to download something
in the background and don't want my Thread to
On Sun, Mar 1, 2009 at 9:20 AM, Mariano Kamp wrote:
> Marco,
>
> thanks for taking the time to respond.
>
> (a) If you look at the code ( http://pastie.org/403831) you'll see that it
> is in fact a custom log file (see class Persistent Log). The reason behind
> that is to be able to have a lo
And btw. I should have mentioned that the 30 minutes sleep is a placeholder
for the real action. In my case that would be downloading stuff from the
net. But to show that it doesn't depend on the workload and make it more
abstract I just put a sleep in there.
On Sun, Mar 1, 2009 at 6:20 PM, Marian
Marco,
thanks for taking the time to respond.
(a) If you look at the code ( http://pastie.org/403831) you'll see that it
is in fact a custom log file (see class Persistent Log). The reason behind
that is to be able to have a look at the problem over a longer period of
time as it doesn't occur
It looks like the output you posted is from your custom log file, so
the first thing I'd do is to look at the system log to make sure that
the problem isn't in your custom logging code.
Also, doing anything lengthy in a broadcast receiver is a Bad Idea,
and keeping the device awake while you're do
18 matches
Mail list logo
