Thanks for the clarification. I have a followup. You said, "...there is only one PendingIntent instance for a particular combination of: app, type (activity, broadcast, etc), request code, and intent filter"
You mentioned request code. This is important for me because I need some parameter to distinguish the multiple alarms. However in the docs, it says, http://developer.android.com/reference/android/app/PendingIntent.html#getActivity%28android.content.Context,%20int,%20android.content.Intent,%20int%29 "requestCode Private request code for the sender (currently not used)." If request code is not used, then I am wondering how to distinguish multiple alarms. Passing in extra params to the intent extras bundle will not do because as you say, that is not used as a distinguishing feature when comparing two pending intents. thanks, Anil ------------------ On Oct 23, 10:48 pm, Dianne Hackborn <[email protected]> wrote: > A PendingIntent lasts for as long as things have reference on it. It is > not tied to an activity (well unless it is to deliver a result to an > activity). > > As the doc says: > > A PendingIntent itself is simply a reference to a token maintained by the > system describing the original data used to retrieve it. This means that, > even if its owning application's process is killed, the PendingIntent itself > will remain usable from other processes that have been given it. If the > creating application later re-retrieves the same kind of PendingIntent (same > operation, same Intent action, data, categories, and components, and same > flags), it will receive a PendingIntent representing the same token if that > is still valid, and can thus call > cancel()<http://developer.android.com/reference/android/app/PendingIntent.html...()> > to > remove it. > > The AlarmManager only maintains one record per PendingIntent "instance" (as > defined by the equals operator for PendingIntent). However it is important > to understand the semantics of creating a PendingIntent, in that there is > only one PendingIntent instance for a particular combination of: app, type > (activity, broadcast, etc), request code, and intent filter. The latter is > very important since it means that if you ask for a PendingIntent for Intent > with action "foo", and give that to the alarm manager, and then time goes by > (and your process is killed and restarted etc), then when you again ask for > a PendingIntent for intent action "foo" you will get the *same* global > instance is was returned by the first request, and thus the object will be > the same as the instance the alarm manager has, allowing you to cancel, > replace, or otherwise modify that currently scheduled alarm. > > > > On Sat, Oct 23, 2010 at 8:32 PM, Anil <[email protected]> wrote: > > Trying to write a simple alarm clock with multiple alarms. However, I > > don't understand this part: when an alarm has been set and has to be > > modified or deleted, then the PendingIntent is used to set the alarm > > with flags FLAG_CANCEL_CURRENT, FLAG_UPDATE_CURRENT. > > But how is this checked with those PendingIntents already registered > > with the Alarm Manager? > > Is it just a reference == comparison? (in which case when back button > > is pressed then references to the PendingIntents in my activity are > > lost), or are the parts of the intent compared in a equals() > > comparison? > > > In other words, can we be confident that Alarm Manager will accurately > > say, "This is the same alarm and needs to be updated rather than added > > as a new one"? > > thanks, > > Anil > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%[email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
