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 <hack...@android.com> 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 <anil.r...@gmail.com> 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 <hack...@android.com> 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 <anil.r...@gmail.com> 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 <hack...@android.com> 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 <anil.r...@gmail.com> 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
> > > > android-developers@googlegroups.com
> > > > > > To unsubscribe from this group, send email to
> > > > > > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> > <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@googlegroups.com>
>
> > > > <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@googlegroups.com>
> > <android-developers%252bunsubscr...@googlegroups.com<android-developers%25252bunsubscr...@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<android-developers%2bunsubscr...@googlegroups.com>
> > <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@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<android-developers%2bunsubscr...@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
