You didn't include all of your code, but you definitely what to set an explicit component for your receiver, and then the rest of the intent data doesn't matter for deciding where or whether it will be delivered.
On Wed, Apr 22, 2009 at 5:19 PM, Fuzzmonkey <[email protected]> wrote: > > Done a bit more digging. > > proxIntent.setData((Uri.parse("custom://"+SystemClock.elapsedRealtime > ()))); > > If i add this line, the proximity alert is still triggered but the > intent is never received. That is I assume it's still being fired but > not received. I just get.. > > I/LocationManagerService( 57): Entered alert > > Rather than.. > > I/LocationManagerService( 57): Entered alert > D/DEBUG ( 319): Broadcast received > D/MyActivity( 319): Proximity alert fired > D/MyActivity( 319): 2 2 > > Those log commands are in my broadcast reciever btw. Do i need to > change my intent filter with regards to the data bit? I've also logged > SystemClock.elapsedRealtime to see if the pending intents were being > added at the same time, they aren't. > > Thanks, > > George > > On Apr 22, 11:53 pm, Fuzzmonkey <[email protected]> wrote: > > Hmm. > > > > I'm currently using unique request codes and i'm still getting this > > problem. I'm trying to add multiple proximity alerts, with each alert > > containing different information. For example, i have 4 gps co- > > ordinates belong to the same group. I want the intent to contain the > > extra information reflecting this. > > > > Intent proxIntent = new Intent > > ("android.intent.action.PROXIMITY_ALERT"); > > proxIntent.putExtra("goal", goalid); > > proxIntent.putExtra("mgoal", mgoalid); > > > > I then add this 'unique' intent to a pending intent. r represents a > > unique request code, generated at random. > > > > PendingIntent pi = PendingIntent.getBroadcast(this, r, proxIntent, > > PendingIntent.FLAG_CANCEL_CURRENT); > > > > And then add this pending intent to the location manager. > > > > lm.addProximityAlert(latitude, longitude, radius, -1, pi); > > > > The problem i'm finding that if a add 4 proximity alerts quite a > > distance appart, say 500m and set the radius to 50 the information i'm > > receiving when a proximity alert is fired is always that of the last > > alert added. I'm assuming this is because the pending intents are not > > being seen as unique, and is being over written every time i add a new > > proximity alert. If i had the line.. > > > > i.setData((Uri.parse("custom://"+SystemClock.elapsedRealtime()))); > > > > The proximity alerts don't seem to fire at all! It's all very > > confusing. Any one shed any light on this? > > > > Thanks, > > > > George > > > > On Apr 22, 9:06 pm, Rob Franz <[email protected]> wrote: > > > > > 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 <[email protected]> > 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 <[email protected]> > > > > > > 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 < > [email protected]>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 <[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. > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
