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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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." <[email protected]> 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." <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 <[email protected]> >> 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 [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
