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
Dianne,
On 5 Dez., 00:45, Dianne Hackborn [EMAIL PROTECTED] wrote:
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
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]
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
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
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
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
I retested my application, I can post two notifications with two pending
intents with the same action (but different extra args) and this works only
if put different request codes each time...
I tested to click them in different orders to check it this really works: it
works, the correct extra
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
that's exactly the behavior I am noticing, too.
On 21 Nov., 11:38, Guillaume Perrot [EMAIL PROTECTED]
wrote:
I retested my application, I can post two notifications with two pending
intents with the same action (but different extra args) and this works only
if put different request codes each
On Thu, Nov 20, 2008 at 11:31 PM, Guillaume Perrot [EMAIL PROTECTED]
wrote:
Will the SDK be improved to allow several matching pending intents ?
This isn't a limitation, it is a feature. It allows you to retrieve a
PendingIntent you had previously created, so you can cancel it or do other
On Fri, Nov 21, 2008 at 2:14 AM, 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
Ok, so there is a bug and we are exploiting it.
2008/11/21 Dianne Hackborn [EMAIL PROTECTED]
On Fri, Nov 21, 2008 at 2:14 AM, Matthias [EMAIL PROTECTED]wrote:
Well, when /do/ PendingIntents match? All I can say is that calling
PendingActivity.getActivity() created a new PendingIntent each
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:
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
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,
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..
I have this bug too, It works better when I put a requestCode in the
PendingIntent, but according to the documentation, this parameter is
not used...
Strange...
Even by doing that it sometimes fail, but without that, it surely
fails as you both noticed.
Here is the way I post my notification:
Guillaume,
you're my hero. Thanks! Works like a champ now.
Curse Google and their terrible documentation, I spent the whole day
hunting down a bug that ain't there... great. Now I'll go home and
bang my head at the wall for the rest of the day.
On 20 Nov., 17:59, Guillaume Perrot [EMAIL
Note that your pending intents still may collide with this mysterious
request codes.
Since we have the source code now, it may be good to check if this is really
used or not, and how.
2008/11/20 Matthias [EMAIL PROTECTED]
Guillaume,
you're my hero. Thanks! Works like a champ now.
Curse
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
Will the SDK be improved to allow several matching pending intents ?
2008/11/20 Dianne Hackborn [EMAIL PROTECTED]
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
22 matches
Mail list logo
