I would have probably seen that if the operation indicated by the
pendingintent is used as a key.
But I am saying an explicit removal of the alarm containing the
operation (pending intent).
See the code (little) below.
Moreover what one is doing is
alarms.put(at 11pm, foo)
alarms.put(at 12 pm,
PendingIntent *is* a key. When you obtain a PendingIntent with the same
Intent (in terms of intent filter matching) as a previous one, you will
receive a PendingIntent object that is equal to the previous one you got.
On Wed, Jul 14, 2010 at 7:12 AM, Satya Komatineni
satya.komatin...@gmail.com
Dianne,
thanks again.
Sorry to still hang around the issue.
I do understand that the PendingIntent.getActivity, broadcast,
service etc return a key matching the passed in in intent. I think I
got that.
That doesn't explain why the AlarmManagerService **explicitly**
removes the passed in pending
Because that is how we want and designed it to work.
On Wed, Jul 14, 2010 at 11:27 AM, Satya Komatineni
satya.komatin...@gmail.com wrote:
Dianne,
thanks again.
Sorry to still hang around the issue.
I do understand that the PendingIntent.getActivity, broadcast,
service etc return a key
Ok, thank you very much
Satya
On Wed, Jul 14, 2010 at 3:35 PM, Dianne Hackborn hack...@android.com wrote:
Because that is how we want and designed it to work.
On Wed, Jul 14, 2010 at 11:27 AM, Satya Komatineni
satya.komatin...@gmail.com wrote:
Dianne,
thanks again.
Sorry to still hang
If they are the same intent, they can not be uniquely distinguished, so the
more recent one replaces the previous.
It's like doing:
HashMapString, Foo alarms;
Foo foo1 = new Foo();
Foo foo2 = new Foo();
alarms.put(mything, foo1);
alarms.put(mything, foo2);
The second call replaces the value
6 matches
Mail list logo
