Cool, will look into that then. Thanks all. On Thu, Apr 23, 2009 at 1:52 PM, Dianne Hackborn <[email protected]>wrote:
> Different request codes is a perfectly fine way to do it. > > > On Thu, Apr 23, 2009 at 9:48 AM, Rob Franz <[email protected]> wrote: > >> So with all the input from this thread, what's the proper way to send x >> number of pending intents that are unique? >> I guess I'm doing it not 100% correctly (even though it seems to work for >> me and the intents are spaced out enough not to interfere with each other). >> I was doing it >> as setData((Uri.parse("custom://"+SystemClock.elapsedRealtime())). >> >> -rob >> >> On Thu, Apr 23, 2009 at 12:40 PM, Dianne Hackborn <[email protected]>wrote: >> >>> 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 <[email protected]> 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 <[email protected]> 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 <[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 >>>> > >>>> > ... >>>> > >>>> > read more ยป >>>> >>>> >>> >>> >>> -- >>> 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 -~----------~----~----~----~------~----~------~--~---
