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

Reply via email to