Maybe FLAG_CANCEL_CURRENT does cancel the current intent if it has the same uri, action but also the same request code (since it's part of the identity) ?
2008/12/5 Dianne Hackborn <[EMAIL PROTECTED]> > FLAG_CANCEL_CURRENT will almost certainly work. If you look at the code, > if you have the flag set it just removes any existing intent and creates a > whole new pending intent with the intent you provide. The returned > PendingIntent can't contain the old intent data. > > > On Thu, Dec 4, 2008 at 1:19 AM, Matthias <[EMAIL PROTECTED]>wrote: > >> >> I'm pretty sure I used FLAG_CANCEL_CURRENT to no avail... passing >> different request codes each time was the only way to create a new >> intent. I spent a whole day on this combining flags to no avail, until >> I tried the workaround by Guillaume. >> >> On 25 Nov., 19:24, "Dianne Hackborn" <[EMAIL PROTECTED]> wrote: >> > It may or may not be the right thing to do. If you are not going to use >> the >> > old intent, you should just use FLAG_CANCEL_CURRENT to first cancel the >> > existing one so it can be replaced with your new one. >> > >> > On Tue, Nov 25, 2008 at 12:29 AM, Guillaume Perrot < >> [EMAIL PROTECTED] >> > >> > >> > >> > > wrote: >> > > Yes using request codes is the right thing to do, this is just a >> > > documentation bug in the end. >> > >> > > 2008/11/25 alex <[EMAIL PROTECTED]> >> > >> > >> Ok, so I ran into this exact issue too. I need to send different data >> > >> via the extras of the intent, but the old intent with the old extras >> > >> keeps getting delivered unless I pass unique values into the >> > >> mysterious requestCode parameter. >> > >> > >> So this begs the question: is using the requestCode in this way >> > >> kosher? Is there a better way? >> > >> > >> BTW, I'm using PendingIntents for alarms and notifications. >> > >> > >> On Nov 21, 2:47 pm, Guillaume Perrot <[EMAIL PROTECTED]> >> wrote: >> > >> > Thanks for your answer, it eventually solves the mystery \o/ >> > >> > I quoted it in the Issue 863. >> > >>http://code.google.com/p/android/issues/detail?id=863 >> > >> > >> > On 21 nov, 23:38, "Dianne Hackborn" <[EMAIL PROTECTED]> wrote: >> > >> > >> > > Ah you are right, the request code is also part of its identity. >> > >> > >> > > For the nitty gritty details, this file defines a PendingIntent >> > >> maintained >> > >> > > by the system and the full key used to match them: >> > >> > >> > > >> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;. >> > >> .. >> > >> > >> > > On Fri, Nov 21, 2008 at 3:07 AM, Matthias < >> [EMAIL PROTECTED]> >> > >> wrote: >> > >> > >> > > > And to further clear up my intentions: >> > >> > >> > > > I have a model class called "Event". It represents user >> activity in >> > >> my >> > >> > > > system (such as rating items or writing messages). These events >> are >> > >> > > > delivered to the user through NotificationManager. For every >> such >> > >> > > > event, the NM calls Event.toNotification() and delivers the >> > >> > > > notification. >> > >> > >> > > > Furthermore, I have an activity called EventDetailsActivity. >> This is >> > >> > > > triggered whenever the user taps on the notification to read >> the >> > >> event >> > >> > > > info in full length. This implies primarily two things: >> > >> > >> > > > 1. I must be able to pass an Event model object to >> > >> > > > EventDetailsActivity whenever the user taps the corresponding >> > >> > > > notification >> > >> > > > 2. I must be able to reuse EventDetailsActivity even it is >> already >> > >> > > > displaying another event (e.g. update it via onNewIntent()) >> > >> > >> > > > Thus, in Event.toNotification(), I do this: >> > >> > >> > > > public final Notification toNotification(Context context) { >> > >> > > > Intent intent = new Intent(context, >> > >> > > > EventDetailsActivity.class); >> > >> > > > intent.putExtra("event", this); >> > >> > > > intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK >> > >> > > > | Intent.FLAG_ACTIVITY_SINGLE_TOP); >> > >> > > > configureIntent(intent); // template method for >> subclasses >> > >> > >> > > > PendingIntent contentIntent = PendingIntent.getActivity >> > >> > > > (context, >> > >> > > > requestCode++, intent, 0); >> > >> > >> > > > Notification notification = new Notification >> > >> > > > (getNotificationIcon(), >> > >> > > > getTickerText(), getDate().getTime()); >> > >> > > > notification.setLatestEventInfo(context, getTitle(), >> getText >> > >> > > > (), >> > >> > > > contentIntent); >> > >> > >> > > > return notification; >> > >> > > > } >> > >> > >> > > > Hope that clears up my intentions. >> > >> > >> > > > On 21 Nov., 11:14, Matthias <[EMAIL PROTECTED]> wrote: >> > >> > > > > Well, when /do/ PendingIntents match? All I can say is that >> > >> calling >> > >> > > > > PendingActivity.getActivity() created a new PendingIntent >> each >> > >> time I >> > >> > > > > called it (I checked the OID in the debugger), and in this >> new >> > >> object, >> > >> > > > > I always store a new Intent object. >> > >> > >> > > > > As Guillaume suggested, I solved the problem by calling >> > >> getActivity() >> > >> > > > > like this: >> > >> > >> > > > > private static int requestCode; >> > >> > > > > ... >> > >> > > > > pi = PendingIntent.getActivity(context, requestCode++, >> intent, 0) >> > >> > >> > > > > and now everything works as expected. As for the intent >> itself, I >> > >> > > > > instantiated it using FLAG_ACTIVITY_NEW_TASK and >> > >> > > > > FLAG_ACTIVITY_SINGLE_TOP. >> > >> > >> > > > > On 20 Nov., 22:55, "Dianne Hackborn" <[EMAIL PROTECTED]> >> wrote: >> > >> > >> > > > > > I am really not clear on exactly what you are doing or >> > >> expecting, but >> > >> > > > one >> > >> > > > > > thing to watch out for -- when you get a PendingIntent, if >> there >> > >> is >> > >> > > > already >> > >> > > > > > a PendingIntent matching the Intent you have been given >> (NOT >> > >> including >> > >> > > > the >> > >> > > > > > extras), then you get that PendingIntent, NOT a new one. >> So if >> > >> you >> > >> > > > want to >> > >> > > > > > change the extras you will either need to cancel the >> existing >> > >> one, or >> > >> > > > modify >> > >> > > > > > something in the action, type, data, or category so that it >> > >> doesn't >> > >> > > > match >> > >> > > > > > the existing one. >> > >> > >> > > > > > This is covered (not very well) in the last paragraph of >> the >> > >> > > > PendingIntent >> > >> > > > > > documentation: >> > >> > >> >> http://code.google.com/android/reference/android/app/PendingIntent.html >> > >> > >> > > > > > On Thu, Nov 20, 2008 at 8:38 AM, Matthias < >> > >> [EMAIL PROTECTED]> >> > >> > > > wrote: >> > >> > >> > > > > > > This gets weirder every minute. >> > >> > >> > > > > > > Just out of curiosity I just called setIntent(null) in >> > >> onPause() to >> > >> > > > > > > make sure the Intent the Activity was started with is >> always >> > >> reset. >> > >> > > > As >> > >> > > > > > > soon as I start the Activity again though, getIntent() >> will >> > >> AGAIN >> > >> > > > > > > return the Intent I supposedly set to null before...... >> this >> > >> Intent >> > >> > > > it >> > >> > > > > > > returns even exists across re-deployments of the whole >> > >> application >> > >> > > > > > > (not across emulator reboots tho)! >> > >> > >> > > > > > > Am I the only one having these problems? ^^ This whole >> thing >> > >> looks >> > >> > > > > > > completely broken to me. None of the functionalities I >> used >> > >> exposed >> > >> > > > > > > the behavior that was documented. >> > >> > >> > > > > > > On 20 Nov., 17:03, Matthias <[EMAIL PROTECTED]> >> > >> wrote: >> > >> > > > > > > > I think this may be a bug in Android. I also tried >> following >> > >> the >> > >> > > > > > > > instructions from the docs under section "Launch Modes >> and >> > >> Launch >> > >> > > > > > > > Flags" with no success. That section suggested to >> declare >> > >> any >> > >> > > > Activity >> > >> > > > > > > > launched from NotificationManager to set the >> taskAffinitity >> > >> to "" >> > >> > > > and >> > >> > > > > > > > finishOnTaskLaunch to true, so that the Activity does a >> > >> clean start >> > >> > > > > > > > everytime it is called. >> > >> > >> > > > > > > > Even though the Activity is completely restarted now >> > >> (onStart() is >> > >> > > > > > > > called), getIntent() always yields the same intent, the >> one >> > >> it was >> > >> > > > > > > > started with for the very first time... >> > >> > >> > > > > > > > On 20 Nov., 14:17, Matthias <[EMAIL PROTECTED] >> > >> > >> wrote: >> > >> > >> > > > > > > > > Hi, >> > >> > >> > > > > > > > > I have the following problem: When posting a new >> > >> Notification, I >> > >> > > > pass >> > >> > > > > > > > > along a PendingIntent used to fire up an Activity >> that >> > >> shows >> > >> > > > details >> > >> > > > > > > > > about this Notification. These details are passed as >> a >> > >> > > > Serializable >> > >> > > > > > > > > Extra. >> > >> > >> > > > > > > > > However, the Intent holding the Extra is only updated >> > >> once, when >> > >> > > > the >> > >> > > > > > > > > Activity was started for the first time. If a new >> > >> Notification >> > >> > > > arrives >> > >> > > > > > > > > however, although I instantiate a new Intent, neither >> > >> getIntent() >> > >> > > > nor >> > >> > > > > > > > > onNewIntent() of said Activity deliver this new >> intent, >> > >> instead >> > >> > > > they >> > >> > > > > > > > > always deliver the Intent that was active when the >> > >> Activity was >> > >> > > > > > > > > started for the first time. >> > >> > >> > > > > > > > > I tried combining many of the flags that can be >> passed to >> > >> Intents >> > >> > > > and >> > >> > > > > > > > > PendingIntents (in particular >> FLAG_ACTIVITY_SINGLE_TOP >> > >> which is >> > >> > > > said >> > >> > > > > > > > > to do exactly what I need, namely calling >> onNewIntent() >> > >> with the >> > >> > > > new >> > >> > > > > > > > > intent, but that's not the case), but no luck. >> > >> > >> > > > > > > > > So, how can I update my Activity with the Intent used >> to >> > >> fire it, >> > >> > > > > > > > > whenever the Activity is already running? >> > >> > >> > > > > > > > > Thanks, >> > >> > > > > > > > > Matthias >> > >> > >> > > > > > -- >> > >> > > > > > 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. All such questions should be >> posted on >> > >> public >> > >> > > > > > forums, where I and others can see and answer them. >> > >> > >> > > -- >> > >> > > 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. All such questions should be posted on >> > >> public >> > >> > > forums, where I and others can see and answer them. >> > >> > -- >> > 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. All such questions should be posted on public >> > forums, where I and others can see and answer them. >> >> > > > -- > 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. All such questions should be posted on public > forums, where I and others can see and answer them. > > > > > -- Guillaume Perrot Software Engineer at Ubikod BuddyMob developer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
