Yeah the doc for that function should be better, it is a low priority because this is really not something that most apps should use (in fact it was made available pretty late in development).
On Oct 13, 4:07 pm, Tsunami <[EMAIL PROTECTED]> wrote: > Great, and thanks! If I might advise, the documentation for sticky > broadcasts doesn't make it very clear that Intents with the same > action, type, data, and categories will replace each other, and could > be updated. > > On Oct 13, 6:49 pm, hackbod <[EMAIL PROTECTED]> wrote: > > > When you send a sticky broadcast, that broadcast will replace any > > other existing one with the same action, type, data, and categories. > > No need to remove it. Just be sure that all of your changing state is > > in the extras part of the Intent, not in the main fields. > > > On Oct 13, 3:35 pm, Soonil Nagarkar <[EMAIL PROTECTED]> wrote: > > > > I have a component that uses sticky broadcasts to send out state > > > information about itself along the lines of enabled/disabled. By using > > > sticky broadcasts, anybody that needs to check the state of the > > > component (which can be changed at any time by other threads) can stay > > > up to date rather than using a polling mechanism which doesn't > > > guarantee any 'up-to-date-ness'. > > > > However, my understanding of the sticky broadcast documentation is > > > that sticky broadcast intents stay around forever unless removed and > > > never replace each other. Since I don't want some huge list of > > > previous intents gumming up the system, and since other components > > > only need the last sticky broadcast, not the whole list, to determine > > > what the current component state is, I use removeStickyBroadcast() to > > > always remove the last intent. As far as I can see however, this leads > > > to concurrency problems. See the following code... > > > > Ex 1. > > > > if(last_broadcast != null) > > > context.removeStickyBroadcast(last_broadcast); > > > > //it is possible for a thread to interleave its own call to > > > registerReceiver() right here, and not get any > > > //information on the previous component state > > > > last_broadcast = new Intent(...); > > > context.sendStickyBroadcast(last_broadcast); > > > > Ex 2. > > > > Intent new_broadcast = new Intent(...); > > > context.sendStickyBroadcast(last_broadcast); > > > > //it is possible for a thread to interleave its own call to > > > registerReceiver() right here, and receive two sticky > > > //broadcast intents instead of one. a better, but not ideal solution. > > > > if(last_broadcast != null) > > > context.removeStickyBroadcast(last_broadcast); > > > last_broadcast = new_broadcast; > > > > Neither of these two scenarios solves the problem entirely, and I > > > can't imagine any way to make this synchronous with respect to other > > > registerReceiver() calls. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
