That is not an activity that extends a Broadcast receiver. That is a
class that extends a Broadcast receiver, making AlarmReceiver a broadcast
receiver, not an Activity.
On Thu, Feb 24, 2011 at 1:27 PM, Neilz neilhorn...@gmail.com wrote:
Like this:
public class AlarmReceiver extends
Ok, that's a receiver.
I am guessing that your receiver uses startActivity. If you do that,
beware of sleep/wake states, it's documented here:
http://developer.android.com/reference/android/app/AlarmManager.html
Android guarantees that for Wakeup-type alarms delivered to a broadcast
24.02.2011 1:06, Neilz пишет:
I'm using an Activity that
extends a BroadcastReceiver...
An Activity that extends a Broadcast receiver? Sorry, I'm not sure I
understand what this means.
Do you mean something else - like a BroadcastReceiver subclass that
starts an Activity subclass?
--
If your device switches off the networking connection while sleeping,
then yes, that line can throw an exception.
It should be an IOException, which should go into the log, but since it
doesn't seem to be - add a catch block for Exception (or even better,
Throwable) and log it, see what
20.02.2011 16:18, Neilz пишет:
I did the network test...
Active network info: NetworkInfo: type: WIFI[], state: CONNECTED/
CONNECTED, reason: (unspecified), extra: (none), roaming: false,
failover: false, isAvailable: true
That's good.
And added a general Exception block, which still didn't
This means Android decided to get rid your process, thinking it wasn't
important.
http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html
Add a call to startForeground while updating data, and stopForeground
when done.
And btw, you are using AlarmService to
No, AsyncTask has nothing to do with when your process is killed. In both
ways -- it can not allow it to be killed, nor can it *prevent* it from being
killed (having a Service, Activity, etc running is what lets the system know
how important the process is to be kept around, and thus whether it
Neil,
A background service may be stopped by Android at its discretion.
The beauty of AlarmManager is that it doesn't matter - when an alarm
fires, the component that the pending intent is intended for will be
started as necessary.
The alarms are not kept in the application's process, they
Yes, this was discussed recently here:
http://code.google.com/p/android/issues/detail?id=14536
and there appears to be no workaround, except explaining this to the
user (in the application's UI or if he contacts you).
I was just saying that there are devices out there with pretty weird
On 5 February 2011 13:40, Neilz neilhorn...@gmail.com wrote:
Ok, one problem with this alarm service.
I schedule it for some time in the morning, and when I get up and
check the phone, the alarm didn't get called, because it thinks
there's no network connection.
Alarm manager makes does not
05.02.2011 15:40, Neilz пишет:
Ok, one problem with this alarm service.
I schedule it for some time in the morning, and when I get up and
check the phone, the alarm didn't get called, because it thinks
there's no network connection.
I'm sure the alarm did get called, as the AlarmManager
Neil,
That's pretty much how I test too, except my code lacks a check for
isConnected, only for null.
This is what I get in my app's log:
NetworkInfo: type: MOBILE[EDGE], state: CONNECTED/CONNECTED, reason:
apnSwitched, extra: internet.mts.ru, roaming: false, failover: false,
isAvailable:
On Sat, Feb 5, 2011 at 10:22 AM, Neilz neilhorn...@gmail.com wrote:
Yes, looking at the log output, it seems the device disables the
wireless connection after a few minutes while the phone's sleeping, to
save resources I suppose. So I'll just have to code around that, and
reset the alarm to
Interesting.
I take it by wireless you mean cellular?
My HTC Hero has an option for always on cellular data connection - I
guess it's specific to HTC phones, as neither my Samsung Galaxy S or
Motorola Milestone have that.
Is your phone made by HTC by any chance? If so, perhaps you could
05.02.2011 18:47, Neilz пишет:
No I'm testing on a Nexus...
Ok.
But I can't be responsible for user's individual settings, so I'll
just have to assume that in some cases the network will not be
available during the night. Unless there's a command to explicitly
wake up the connection?
Well,
Right, alarms are not persistent.
Implement a receiver for android.intent.action.BOOT_COMPLETED, and set
the alarm again after the device reboots.
-- Kostya
01.02.2011 20:22, Neilz пишет:
Thanks... this seems to be what I'm after.
However I just put together a simple repeat alarm,
01.02.2011 20:35, Neilz пишет:
Right, thanks. And will that stay on the device as long as the app is
still installed?
Yes.
(And, I suppose, will it get removed if the app is
uninstalled?)
Believe so.
-- Kostya
On Feb 1, 5:25 pm, Kostya Vasilyevkmans...@gmail.com wrote:
Right, alarms
Neil,
You can set a non-repeating RTC or RTC_WAKEUP alarm at a fixed time,
then when it fires, set the next one.
Rinse, repeat :)
-- Kostya
02.02.2011 0:22, Neilz пишет:
One thing I'm unsure of is how to schedule an alarm for a certain
time, like 8am every day.
All I can see is setting a
18 matches
Mail list logo
