No, I mean setting the explicit component to your broadcast receiver component on the Intent class. I strongly strongly recommend this for this kind of situation where you want someone to deliver some specific thing to a component in your app. Please read the Intent java doc for more info.
On Thu, Apr 23, 2009 at 4:01 AM, Fuzzmonkey <she...@gmail.com> wrote: > > Hello, > > By explicit component do you mean <data android scheme="custom"></ > data> in the intent filter or code in the broadcast receiver? Is that > all i'd need? > > Thanks, > > George > > On Apr 23, 1:29 am, Dianne Hackborn <hack...@android.com> wrote: > > 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 <she...@gmail.com> 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 <she...@gmail.com> 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 <rob.fr...@gmail.com> 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 <m...@tomgibara.com> > > > 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 <rob.fr...@gmail.com> > > > > > > > > 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 < > > > hack...@android.com>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 < > rob.fr...@gmail.com> > > > 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 < > rob.fr...@gmail.com> > > > 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" <bilgiciftl...@gmail.com> > 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." <bbuckle...@yahoo.com> > 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." <bbuckle...@yahoo.com> > 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" < > bilgiciftl...@gmail.com> > > > > > >>>>> wrote: > > > > > > > >>>>> > > > > Are not Google developers looking into this forum > > > anymore? > > > > > > > >>>>> > > > > Then, I will be missing the detailed answers. > > > > > > > >>>>> > > > > Regards, > > > > > >>>>> > > > > info+farm > > > > ... > > > > read more ยป > > > -- Dianne Hackborn Android framework engineer hack...@android.com 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---