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