Why should this be something most apps shouldn't use? Within an application the only alternatives are listeners with memory, which also have to take care of concurrency constraints. I found it much easier to use the sticky intent system than writing it all out myself. And of course, if you want out of application notifications, you have no other option.
On Oct 13, 7:20 pm, hackbod <[EMAIL PROTECTED]> wrote: > 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 [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 -~----------~----~----~----~------~----~------~--~---
