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 intent from the "alarmmanager.set()"
operations from an existing set of alarms...
Infact when I do the following
am.set(time1, pendingintent_1);
am.set(time2, pendingintent_1);
Internally the AlarmManagerService is executing
am.set(time1, pendingintent_1);
am.cancel(pendingintent_1);
am.set(time2, pendingintent_1);
Although the "cancel" is done through a direct call to "remove".
Eitheway this is just a clarification, I think the end result is the
same which matches with your explanation, except that it doesn't
happen through hashmap or something like that but seem to be an
explicit removal.
On Wed, Jul 14, 2010 at 1:04 PM, Dianne Hackborn <hack...@android.com> wrote:
> 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> wrote:
>>
>> 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", foo)
>>
>> Conceptually I would have understood if I did
>>
>> pendingintent.gooff("at 11");
>> pendingintent.gooff("at 12");
>>
>> *** AlarmManagerService.java extract
>>
>> 160 public void setRepeating(int type, long triggerAtTime, long
>> interval,
>> 161 PendingIntent operation) {
>> 162 if (operation == null) {
>> 163 Slog.w(TAG, "set/setRepeating ignored because there
>> is no intent");
>> 164 return;
>> 165 }
>> 166 synchronized (mLock) {
>> 167 Alarm alarm = new Alarm();
>> 168 alarm.type = type;
>> 169 alarm.when = triggerAtTime;
>> 170 alarm.repeatInterval = interval;
>> 171 alarm.operation = operation;
>> 172
>> 173 // Remove this alarm if already scheduled.
>> 174 removeLocked(operation);
>> 175
>> 176 if (localLOGV) Slog.v(TAG, "set: " + alarm);
>> 177
>> 178 int index = addAlarmLocked(alarm);
>> 179 if (index == 0) {
>> 180 setLocked(alarm);
>> 181 }
>> 182 }
>> 183 }
>>
>>
>> AlarmManagerService doest maintain separate 'alarm' objects with every
>> "set" even with the same equivalent intent. It then physically removes
>> one of the alarm objects that were scheduled earlier.
>>
>> Is this to avoid a later confusion between two alarms with the same
>> intent??
>>
>> Anyway thanks for chiming in
>>
>> Satya
>>
>>
>> On Wed, Jul 14, 2010 at 1:58 AM, Dianne Hackborn <hack...@android.com>
>> wrote:
>> > If they are the same intent, they can not be uniquely distinguished, so
>> > the
>> > more recent one replaces the previous.
>> > It's like doing:
>> > HashMap<String, Foo> alarms;
>> > Foo foo1 = new Foo();
>> > Foo foo2 = new Foo();
>> > alarms.put("mything", foo1);
>> > alarms.put("mything", foo2);
>> > The second call replaces the value of the first.
>> >
>> > On Tue, Jul 13, 2010 at 8:04 PM, Satya Komatineni
>> > <satya.komatin...@gmail.com> wrote:
>> >>
>> >> It was a bit baffling (Probably there is a good reason, and it doesnt
>> >> take much to baffle me)
>> >>
>> >> AlarmManager am;
>> >> ...
>> >> PendingIntent pi;
>> >>
>> >>
>> >> am.set(pi, ...) at 11pm
>> >> am.set(pi,...) at 2pm
>> >>
>> >> Same "pending intent" with the same intent and request code, in
>> >> otherwords they resolve to same intent on equals.
>> >>
>> >> Although I know what happens (being the latest one takes precedence),
>> >> I would have expected my broadcast receiver to be called twice.
>> >>
>> >> I thought something funny is happening in the PendingIntent.
>> >>
>> >> However when I looked at the AlarmManagerService.java I have noticed
>> >> that the "set.." methods are calling a "remove" using the
>> >> PendingIntent that is passed in, essentially cancelling the one
>> >> before.
>> >>
>> >> Why is that??
>> >>
>> >> It is late, my head hurts, I am hoping someone will throw some light.
>> >>
>> >> Thanks a bunch
>> >> Satya
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Android Developers" group.
>> >> To post to this group, send email to
>> >> android-developers@googlegroups.com
>> >> To unsubscribe from this group, send email to
>> >> android-developers+unsubscr...@googlegroups.com
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/android-developers?hl=en
>> >
>> >
>> >
>> > --
>> > Dianne Hackborn
>> > Android framework engineer
>> > hack...@android.com
>> >
>> > Note: please don't send private questions to me, as I don't have time to
>> > provide private support, and so won't reply to such e-mails. All such
>> > questions should be posted on public forums, where I and others can see
>> > and
>> > answer them.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Android Developers" group.
>> > To post to this group, send email to android-developers@googlegroups.com
>> > To unsubscribe from this group, send email to
>> > android-developers+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/android-developers?hl=en
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>
>
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
