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
>>> >
>>> > > > > On Mar 24, 3:17 pm, "info+farm" <bilgiciftl...@gmail.com> wrote:
>>> >
>>> > > > > > Hello Mr. Murphy,
>>> >
>>> > > > > > I searched for it before sending my post and looked at
>>> >
>>> > > > > >
>>> http://groups.google.com/group/android-developers/browse_thread/threa...
>>> > > > > > andhttp://
>>> groups.google.com/group/android-developers/browse_thread/threa...
>>> >
>>> > > > > > But both of them could not find the answer to the problem.
>>> >
>>> > > > > > I am afraidPendingIntenthas different Intent
>>> initialization(start
>>> > > > > > ()), from the normal startActivity().
>>> >
>>> > > > > > I am a little bit confused,
>>> >
>>> > > > > > Regards,
>>> > > > > > info+farm
>>> >
>>> > > > > > On Mar 23, 11:32 pm, Mark Murphy <mmur...@commonsware.com>
>>> wrote:
>>> >
>>> > > > > > > info+farm wrote:
>>> > > > > > > > Am I the only one who is having this problem?
>>> > > > > > > > Actually, I am going to find a workaround for this problem,
>>> but I
>>> > > > > > > > would like to know what I am doing wrong.
>>> >
>>> > > > > > > I do not remember the answer, but I do know this was
>>> discussed on this
>>> > > > > > > list within the past few months. Search the list
>>> forPendingIntentand
>>> > > > > > > you will probably find it.
>>> >
>>> > > > > > > --
>>> > > > > > > Mark Murphy (a Commons Guy)http://commonsware.com
>>> > > > > > > Warescription: Three Android Books, Plus Updates, $35/Year
>>>
>>>
>>
>>
>>
>
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---
