I am glad we are on an agreement here.
I created a bug report for this:
http://code.google.com/p/android/issues/detail?id=16314
On Apr 22, 7:27 pm, Mark Murphy wrote:
> And moments after I pressed [Send], I notice Ms. Hackborn indicating
> on another thread that Force Stop from the Settings ap
On Fri, Apr 22, 2011 at 2:02 AM, Zsolt Vasvari wrote:
> You MUST
> start the alarm when the app starts, so it can recover from Force
> Closes or for whatever reason the system decides to terminate it, but
> once you do that, you can get yourself into a cycle where you end up
> never firing the ala
And moments after I pressed [Send], I notice Ms. Hackborn indicating
on another thread that Force Stop from the Settings app will get rid
of scheduled alarms as well.
Given that, I'll agree with your general assessment -- inexact
repeating alarms are practical for relatively short periods (e.g., a
If I want to set an exact time, I can do that, of course. But the
whole point of using inexact timers is that the system decides when
it's the most efficient time to fire the alarm, which was perfect for
my app.I cannot do this reliably without being able to query the
AlarmManager.
On Apr 2
On Fri, Apr 22, 2011 at 1:09 AM, TreKing wrote:
> When your alarm goes off, one of the actions you take is to reset the alarm
> for the next run.
And update the shared preference to indicate what time the next run is
supposed to go off.
-
On Fri, Apr 22, 2011 at 12:47 AM, Zsolt Vasvari wrote:
> How would that work?
>
> If the alarm is killed by the system for whatever reason, how would the
> preference let me know if I need to restart the alarm or not?
>
The preference would tell you the next time for which you had scheduled your
Basically, the more I think about it, unless I am missing something, I
came to the conclusion that non-exact repeating alarams cannot be made
to work reliably. They are fine for cases when you need to do
somtheing somewhat frequently, like every hour, but for a long period
repeat you have no way o
> Store a SharedPreference value that indicates the time you last set the
> alarm for, defaulting to 0.
How would that work?
If the alarm is killed by the system for whatever reason, how would
the preference let me know if I need to restart the alarm or not?
I think the only way to do this relia
On Fri, Apr 22, 2011 at 12:20 AM, Zsolt Vasvari wrote:
> So, long story short -- how can I make sure that the alarm is
> only recreated when if it doesn't yet exist?
>
Store a SharedPreference value that indicates the time you last set the
alarm for, defaulting to 0.
> I don't see anything in
Ok, I know why both alarms are effected. I was using
String.startsWith to check the package name in my PACKAGE_REPLACED
receiver. So that's solved.
But, I start my Alarm in a various places to make sure it's running:
BOOT_COMPLETED
PACKAGE_REPLACED
and every time when the app itself is opened b
10 matches
Mail list logo
