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
>>>>> >
>>>>> > > > > 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
-~----------~----~----~----~------~----~------~--~---
