In your two intents, nothing in the keys (app, type, intent filter, request code) are the same, so these are associated with the same pending intent. What happens when you retrieve the pending intent for the second depends on whether you pass the flag to replace/cancel the first. Either way, you have a single pending intent that is associated with the first intent or the second intent. (Also if you cancel the existing pending intent, of course that also cancels the one the alarm manager has.)
I'm not sure I understand about dealing with the user pressing back. PendingIntent objects are outside the scope of an activity. If you hand them to the alarm manager, it will keep a reference on and and thus the object will remain around until the alarm goes off. You don't need to do anything to prevent it from going away. If you are asking how to remember what alarms you have set... you need to do that in your own persistent storage. Ignoring whether you can get back pending intents, you need to maintain that so if the phone is turned off and back on you can re-initialize your alarms correctly. As far as using the request code to update the alarm associated with a pending intent... no, there is no need to do this. It is just one part of the key that unique identifies a particular pending intent. You could just as well use the other parts of the intent that apply to filtering: action, data, mime type, categories, etc. It can just be surprising that the extras are not part of the filtering, so people call PendingIntent.createXxx() with an intent that is different only in extras, and are surprised they end up with the same pending intent as they had before. The request code is one way to keep it unique. Maybe looking at the platform's alarm clock app would help? http://android.git.kernel.org/?p=platform/packages/apps/DeskClock.git;a=tree On Mon, Oct 25, 2010 at 7:45 AM, Anil <[email protected]> wrote: > Sorry, I don't think I am explaining this well. > You said, "It is not used for sending the intent, but it is part of > the key that unique[ly] identifies a pending intent. " > > Should we use the request code to retrieve the PendingIntent > associated with the alarm we want to pick and update out of the many > alarms? > > I create an alarm. In the Intent bundle extras, I put: name="ring-tone- > type" value=1 > > AlarmManager am = (AlarmManager) > getSystemService(Context.ALARM_SERVICE); > int requestCode = ALERT_ME; > Intent alertIntent = new Intent(AlertActivity.this, > WakeupActivity.class); > alertIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); > alertIntent.setAction(ALERT_ME_ACTION); > > alertIntent.putExtra("iovercomer.AlertActivity.ring-tone-type", 1); > int flags = PendingIntent.FLAG_UPDATE_CURRENT; > PendingIntent mAlarmSender = PendingIntent.getActivity(this, > requestCode, > alertIntent, flags); > // We want the alarm to go off 30 seconds from now. > long firstTime = SystemClock.elapsedRealtime(); > am.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime + 30 > * 1000, > mAlarmSender); > > Now I want to create (add) another alarm with ring-tone-type=2. > > alertIntent.putExtra("iovercomer.AlertActivity.ring-tone-type", 2); > > If we ignore the request code; > > Will a new alarm get added? or will the first alarm simply get updated > to ring-tone = 2? > (It seems to me that a new alarm will not be added. ). > > Further, how to ensure updates are correctly handled? e.g. user > presses back button, comes back later and wants to change the ring > tone of alarm 2 to ring-tone 3. > > It seems to me that I should use the request code to identify and > update the PendingIntent associated with the alarm. Is my > understanding correct? > > thanks, > Anil > --- > see http://longingtoadopt.com > > On Oct 24, 8:24 pm, Dianne Hackborn <[email protected]> wrote: > > Who is "one"? If you mean your app, it is the one that registered these > > alarms, so it presumably knows. But maybe you don't mean your app, > because > > you are associating these with ring tones... but the alarm manager > doesn't > > have anything to do with ring tones. > > > > Do you mean when you receive the broadcast for you to decide what to do? > If > > so, then just put something in the intent to tell you. > > > > > > > > On Sun, Oct 24, 2010 at 3:43 PM, Anil <[email protected]> wrote: > > > So how can one distinguish between alarm 1 (play ring-tone 1), alarm 2 > > > (play ring-tone 2), alarm 3 (play ring-tone 3)...? > > > > > On Oct 24, 3:46 pm, Dianne Hackborn <[email protected]> wrote: > > > > The doc is a little wrong. It is not used for sending the intent, > but it > > > is > > > > part of the key that unique identifies a pending intent. > > > > > > On Sun, Oct 24, 2010 at 1:05 PM, Anil <[email protected]> wrote: > > > > > 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. > > > .. > > > > > "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]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > <android-developers%[email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > > > > > <android-developers%[email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > <android-developers%[email protected]<android-developers%[email protected]> > <android-developers%[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]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > <android-developers%[email protected]<android-developers%[email protected]> > <android-developers%[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]<android-developers%[email protected]> > <android-developers%[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]<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
