That said... I would be -very- suspicious about the code you posted where
you are effectively creating random identities for your pending intents. In
most of the places where one uses a pending intent, you give it to something
that holds on to it indefinitely, so you need to be able to recover the
previous pending intent so you can give it back to have it unregistered.
That is why the API works the way it does. This API is really not intended
to generate tons of pending intents whose lifetime is not being managed.
On Thu, Apr 23, 2009 at 10:52 AM, Dianne Hackborn <hack...@android.com>wrote:
> Different request codes is a perfectly fine way to do it.
>
>
> On Thu, Apr 23, 2009 at 9:48 AM, Rob Franz <rob.fr...@gmail.com> wrote:
>
>> So with all the input from this thread, what's the proper way to send x
>> number of pending intents that are unique?
>> I guess I'm doing it not 100% correctly (even though it seems to work for
>> me and the intents are spaced out enough not to interfere with each other).
>> I was doing it
>> as setData((Uri.parse("custom://"+SystemClock.elapsedRealtime())).
>>
>> -rob
>>
>> On Thu, Apr 23, 2009 at 12:40 PM, Dianne Hackborn <hack...@android.com>wrote:
>>
>>> No, I mean setting the explicit component to your broadcast receiver
>>> component on the Intent class. I strongly strongly recommend this for this
>>> kind of situation where you want someone to deliver some specific thing to a
>>> component in your app. Please read the Intent java doc for more info.
>>>
>>>
>>> On Thu, Apr 23, 2009 at 4:01 AM, Fuzzmonkey <she...@gmail.com> wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> By explicit component do you mean <data android scheme="custom"></
>>>> data> in the intent filter or code in the broadcast receiver? Is that
>>>> all i'd need?
>>>>
>>>> Thanks,
>>>>
>>>> George
>>>>
>>>> On Apr 23, 1:29 am, Dianne Hackborn <hack...@android.com> wrote:
>>>> > You didn't include all of your code, but you definitely what to set an
>>>> > explicit component for your receiver, and then the rest of the intent
>>>> data
>>>> > doesn't matter for deciding where or whether it will be delivered.
>>>> >
>>>> > On Wed, Apr 22, 2009 at 5:19 PM, Fuzzmonkey <she...@gmail.com> wrote:
>>>> >
>>>> > > Done a bit more digging.
>>>> >
>>>> > >
>>>> proxIntent.setData((Uri.parse("custom://"+SystemClock.elapsedRealtime
>>>> > > ())));
>>>> >
>>>> > > If i add this line, the proximity alert is still triggered but the
>>>> > > intent is never received. That is I assume it's still being fired
>>>> but
>>>> > > not received. I just get..
>>>> >
>>>> > > I/LocationManagerService( 57): Entered alert
>>>> >
>>>> > > Rather than..
>>>> >
>>>> > > I/LocationManagerService( 57): Entered alert
>>>> > > D/DEBUG ( 319): Broadcast received
>>>> > > D/MyActivity( 319): Proximity alert fired
>>>> > > D/MyActivity( 319): 2 2
>>>> >
>>>> > > Those log commands are in my broadcast reciever btw. Do i need to
>>>> > > change my intent filter with regards to the data bit? I've also
>>>> logged
>>>> > > SystemClock.elapsedRealtime to see if the pending intents were being
>>>> > > added at the same time, they aren't.
>>>> >
>>>> > > Thanks,
>>>> >
>>>> > > George
>>>> >
>>>> > > On Apr 22, 11:53 pm, Fuzzmonkey <she...@gmail.com> wrote:
>>>> > > > Hmm.
>>>> >
>>>> > > > I'm currently using unique request codes and i'm still getting
>>>> this
>>>> > > > problem. I'm trying to add multiple proximity alerts, with each
>>>> alert
>>>> > > > containing different information. For example, i have 4 gps co-
>>>> > > > ordinates belong to the same group. I want the intent to contain
>>>> the
>>>> > > > extra information reflecting this.
>>>> >
>>>> > > > Intent proxIntent = new Intent
>>>> > > > ("android.intent.action.PROXIMITY_ALERT");
>>>> > > > proxIntent.putExtra("goal", goalid);
>>>> > > > proxIntent.putExtra("mgoal", mgoalid);
>>>> >
>>>> > > > I then add this 'unique' intent to a pending intent. r represents
>>>> a
>>>> > > > unique request code, generated at random.
>>>> >
>>>> > > > PendingIntent pi = PendingIntent.getBroadcast(this, r, proxIntent,
>>>> > > > PendingIntent.FLAG_CANCEL_CURRENT);
>>>> >
>>>> > > > And then add this pending intent to the location manager.
>>>> >
>>>> > > > lm.addProximityAlert(latitude, longitude, radius, -1, pi);
>>>> >
>>>> > > > The problem i'm finding that if a add 4 proximity alerts quite a
>>>> > > > distance appart, say 500m and set the radius to 50 the information
>>>> i'm
>>>> > > > receiving when a proximity alert is fired is always that of the
>>>> last
>>>> > > > alert added. I'm assuming this is because the pending intents are
>>>> not
>>>> > > > being seen as unique, and is being over written every time i add a
>>>> new
>>>> > > > proximity alert. If i had the line..
>>>> >
>>>> > > > i.setData((Uri.parse("custom://"+SystemClock.elapsedRealtime())));
>>>> >
>>>> > > > The proximity alerts don't seem to fire at all! It's all very
>>>> > > > confusing. Any one shed any light on this?
>>>> >
>>>> > > > Thanks,
>>>> >
>>>> > > > George
>>>> >
>>>> > > > On Apr 22, 9:06 pm, Rob Franz <rob.fr...@gmail.com> wrote:
>>>> >
>>>> > > > > Yeah I agree - it is ugly, but for my purposes it worked... the
>>>> intents
>>>> > > > > wouldn't be fired one right after the other for me.
>>>> >
>>>> > > > > On Wed, Apr 22, 2009 at 4:02 PM, Tom Gibara <m...@tomgibara.com
>>>> >
>>>> > > wrote:
>>>> > > > > > Setting the data uniquely in this way is a bit ugly - and what
>>>> if you
>>>> > > post
>>>> > > > > > two intents within the granularity of the clock?
>>>> > > > > > I use unique request codes. I can't claim that this is the
>>>> intended
>>>> > > use for
>>>> > > > > > them (the documentation is a bit sparse) but it seems to work
>>>> well.
>>>> > > > > > Tom.
>>>> >
>>>> > > > > > 2009/4/22 Rob Franz <rob.fr...@gmail.com>
>>>> >
>>>> > > > > > Hi Dianne,I thought that the goal was to create unique
>>>> > > pendingIntents...
>>>> > > > > >> i.e. don't cancel or change the currently pending one.
>>>> >
>>>> > > > > >> For me, changing the extras didn't work - doing the setData()
>>>> with
>>>> > > the
>>>> > > > > >> random value made the intent 'unique' in the eyes of the
>>>> > > notification
>>>> > > > > >> manager...i wanted the ability to send multiple different
>>>> pending
>>>> > > intents,
>>>> > > > > >> and that's worked for me thus far.
>>>> >
>>>> > > > > >> -rob
>>>> >
>>>> > > > > >> On Wed, Apr 22, 2009 at 3:44 PM, Dianne Hackborn <
>>>> > > hack...@android.com>wrote:
>>>> >
>>>> > > > > >>> I hope you aren't writing constants into real code like
>>>> that. :}
>>>> >
>>>> > > > > >>> For changing the extras -- you need to use cancel, and this
>>>> will
>>>> > > result
>>>> > > > > >>> in a new PendingIntent that you need to send to the
>>>> notification
>>>> > > manager.
>>>> > > > > >>> As of cupcake you can alternatively use the new
>>>> > > FLAG_UPDATE_CURRENT.
>>>> >
>>>> > > > > >>> On Thu, Mar 26, 2009 at 7:05 PM, Rob Franz <
>>>> rob.fr...@gmail.com>
>>>> > > wrote:
>>>> >
>>>> > > > > >>>> Actually it looks like
>>>> > > > > >>>> PendingIntent pendingIntent =
>>>> PendingIntent.getBroadcast(context,
>>>> > > 0,
>>>> > > > > >>>> intent, 0x10000000);
>>>> >
>>>> > > > > >>>> ...works for me (0x10000000 represents
>>>> FLAG_CANCEL_CURRENT). I
>>>> > > can
>>>> > > > > >>>> verify that the appropriate extras data makes it to the
>>>> intent.
>>>> > > Hope this
>>>> > > > > >>>> helps.
>>>> >
>>>> > > > > >>>> -Rob
>>>> >
>>>> > > > > >>>> On Thu, Mar 26, 2009 at 9:29 PM, Rob Franz <
>>>> rob.fr...@gmail.com>
>>>> > > wrote:
>>>> >
>>>> > > > > >>>>> I'm running into the same thing - sending multiple PIs
>>>> with the
>>>> > > extras
>>>> > > > > >>>>> data changing each time. If I send two PIs, I get the
>>>> first PI
>>>> > > extra
>>>> > > > > >>>>> data. I'm glad someone else ran into this, because I was
>>>> going
>>>> > > crazy
>>>> > > > > >>>>> trying to find out why my stuff wasn't working.
>>>> >
>>>> > > > > >>>>> Seeing a couple of different opinions here... what's the
>>>> Google-
>>>> > > > > >>>>> preferred way to do it? I'm in the US on TMobile so I
>>>> believe
>>>> > > it's
>>>> > > > > >>>>> RC33 that I've got.
>>>> >
>>>> > > > > >>>>> Thanks
>>>> > > > > >>>>> Rob
>>>> >
>>>> > > > > >>>>> On Mar 26, 7:08 pm, "info+farm" <bilgiciftl...@gmail.com>
>>>> wrote:
>>>> > > > > >>>>> > Thank you for your detailed answer Blake B.,
>>>> >
>>>> > > > > >>>>> > First of all I understood that different Extras are not
>>>> act as
>>>> > > a
>>>> > > > > >>>>> > difference on PendingIntent comparison.
>>>> >
>>>> > > > > >>>>> > In the first option assigning a stub data element seems
>>>> > > reasonable
>>>> > > > > >>>>> but
>>>> > > > > >>>>> > I did not like the approach to put not only irrelevant
>>>> but also
>>>> > > not
>>>> > > > > >>>>> > necessary data on each intent call to distinguish them.
>>>> >
>>>> > > > > >>>>> > With the second approach, assigning FLAG_CANCEL_CURRENT
>>>> flag to
>>>> > > the
>>>> > > > > >>>>> > PendingIntent worked well on button calls but did not
>>>> work on
>>>> > > > > >>>>> > notification calls. I received "Sending contentIntent
>>>> failed:
>>>> > > > > >>>>> > android.app.PendingIntent$CanceledException" error in
>>>> logcat on
>>>> > > each
>>>> > > > > >>>>> > different PendingIntent start. I have seen a bug report
>>>> is made
>>>> > > about
>>>> > > > > >>>>> > this issue(#13) on android-astrid.
>>>> > > > > >>>>> > In the issue, it is said that although the javadoc says
>>>> > > requestCode
>>>> > > > > >>>>> is
>>>> > > > > >>>>> > not used, the real OS code consider the value specified
>>>> there.
>>>> > > Then,
>>>> > > > > >>>>> I
>>>> > > > > >>>>> > used the requestCodes to distinguish the PendingIntent
>>>> starts.
>>>> >
>>>> > > > > >>>>> > Is it possible to get information from the API builders,
>>>> what
>>>> > > will be
>>>> > > > > >>>>> > the purpose of the requestCode parameter on
>>>> PendingIntent
>>>> > > creation in
>>>> > > > > >>>>> > the future? The reason is I want to be able to sure that
>>>> my
>>>> > > code
>>>> > > > > >>>>> won't
>>>> > > > > >>>>> > stuck at that time of API change.
>>>> >
>>>> > > > > >>>>> > Regards,
>>>> > > > > >>>>> > info+farm
>>>> >
>>>> > > > > >>>>> > On Mar 25, 5:01 pm, "Blake B." <bbuckle...@yahoo.com>
>>>> wrote:
>>>> >
>>>> > > > > >>>>> > > To correct my previous statement, PendingIntents are
>>>> cached
>>>> > > by the
>>>> > > > > >>>>> > > system, not Intents. The note about how to
>>>> differentiate
>>>> > > Intents
>>>> > > > > >>>>> > > still holds though, so if you need to replace a
>>>> current
>>>> > > > > >>>>> PendingIntent
>>>> > > > > >>>>> > > with a new PI that has a new Intent that only differs
>>>> by its
>>>> > > > > >>>>> Extras,
>>>> > > > > >>>>> > > be sure to use the flag FLAG_CANCEL_CURRENT so that
>>>> the
>>>> > > cached PI
>>>> > > > > >>>>> is
>>>> > > > > >>>>> > > not used.
>>>> >
>>>> > > > > >>>>> > > From Intent.filterEquals(o):
>>>> > > > > >>>>> > > Returns true if action, data, type, class, and
>>>> categories
>>>> > > are
>>>> > > > > >>>>> the
>>>> > > > > >>>>> > > same. <== note does not include Extras
>>>> >
>>>> > > > > >>>>> > > From PendingIntents javadoc:
>>>> >
>>>> > > > > >>>>> > > * <p>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
>>>> > > > > >>>>> > > * {...@link #cancel} to remove it.
>>>> >
>>>> > > > > >>>>> > > On Mar 25, 7:48 am, "Blake B." <bbuckle...@yahoo.com>
>>>> wrote:
>>>> >
>>>> > > > > >>>>> > > > Intents are cached by the system, and two Intents
>>>> are not
>>>> > > > > >>>>> > > > differentiated by their Extras. So your two intents
>>>> look
>>>> > > like
>>>> > > > > >>>>> the
>>>> > > > > >>>>> > > > same Intent and the second one is being tossed out.
>>>> You
>>>> > > must
>>>> > > > > >>>>> differ
>>>> > > > > >>>>> > > > Intents by their Action/Data/Category. I will
>>>> sometimes
>>>> > > use the
>>>> > > > > >>>>> Data
>>>> > > > > >>>>> > > > field to hold a simple ID that is not really a URI
>>>> to make
>>>> > > two
>>>> > > > > >>>>> intents
>>>> > > > > >>>>> > > > appear different. Look at the code for
>>>> Intent.equals() I
>>>> > > > > >>>>> believe, and
>>>> > > > > >>>>> > > > you will see that Extras are not considered.
>>>> >
>>>> > > > > >>>>> > > > On Mar 24, 12:47 pm, "info+farm" <
>>>> bilgiciftl...@gmail.com>
>>>> > > > > >>>>> wrote:
>>>> >
>>>> > > > > >>>>> > > > > Are not Google developers looking into this forum
>>>> > > anymore?
>>>> >
>>>> > > > > >>>>> > > > > Then, I will be missing the detailed answers.
>>>> >
>>>> > > > > >>>>> > > > > Regards,
>>>> > > > > >>>>> > > > > info+farm
>>>> >
>>>> > ...
>>>> >
>>>> > read more ยป
>>>>
>>>>
>>>
>>>
>>> --
>>> 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.
>>>
>>>
>>>
>>>
>>
>> >>
>>
>
>
> --
> 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.
>
>
--
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
-~----------~----~----~----~------~----~------~--~---
