I was hoping you forgot about that piece of code...I think I saw that
somewhere (someone else posted it somewhere so I may not be the only one
using it) when I was trying to figure out why i was trying to send multiple,
different pending intents, but the data was not changing - essentially I
think that everytime I thought I was creating a new one, I was actually only
changing the one that I had just submitted.
On Thu, Apr 23, 2009 at 1:55 PM, Dianne Hackborn <hack...@android.com>wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
