Dianne,
I'm not sure I fully understand this phrase in your comment:
using BroadcastReceiver as a separated class not known by the rest of the
> framework
To clarify, my current solution is a fork of the support package's
LocalBroadcastManager. It does *not* use setOrderedHint(). Because of this,
I am forced to create a class which is a BroadcastReceiver look-alike; and
introduce methods like consumeBroadcast(), which mimic the functionality of
abortBroadcast(). If I go ahead with this approach, components which
express their interest in my broadcasts will not be able to register
regular BroadcastReceiver objects; they will have to register instances of
my custom BroadcastReceiver.
My intention is to alleviate this problem by using setOrderedHint() in my
fork of LocalBroadcastManager. If I do this, I will be able to use the
regular android.content.BroadcastReceiver. and do away with the custom
BroadcastReceiver class. The intention, thus, is to *not* use
BroadcastRecaiver as a separate class; but rather use the one known to the
framework.
On Friday, 18 May 2012 10:52:49 UTC+5:30, Dianne Hackborn wrote:
>
> Hm, okay, for that, where basically you are just using BroadcastReceiver
> as a separated class not known by the rest of the framework, it seems okay.
>
> On Thu, May 17, 2012 at 7:22 PM, Kiran Rao <techie.curi...@gmail.com>wrote:
>
>> Oops .. apologies for the typo, and the ensuing confusion. I did mean
>> LocalBroadcastManager in my original post, wherever I referred to
>> LocalBroadcastReceiver.
>>
>> Mark has summed it all up in his response. My current implementation is
>> this:
>>
>>
>> try to fork BroadcastReceiver and use a forked edition with
>>> LocalBroadcastManager and ordered-broadcast support
>>
>>
>> But I have added my own flag (mConsumed) and added my own methods (
>> consumeBroadcast(), clearConsumeBroadcast() and isBroadcastConsumed()).
>>
>> Secondly, my solution still doesn't allow using any of the setResult*methods
>> of
>> BroadcastReceiver (since all of these first do a checkSynchronousHint()).
>> The way around this is to add another bunch of methods that basically do
>> the exact same thing as getResult* and setResult* ; but which do not go
>> through the checkSynchronousHint() path.
>>
>> Using setOrderedHint() which would allow me to avoid all of this
>> pain.All my changes would be isolated to LocalBroadcastManager, and I
>> would not need to fork BroadcastReceiver (not to mention that code which
>> registers for such local ordered broadcasts wouldn't need to deal with yet
>> another forked class; and confusing methods like consumeBroadcast() in
>> place of abortBroadcast())
>>
>> On Friday, 18 May 2012 02:18:21 UTC+5:30, Mark Murphy (a Commons Guy)
>> wrote:
>>>
>>> On Thu, May 17, 2012 at 4:27 PM, Dianne Hackborn <hack...@android.com>
>>> wrote:
>>> > No, you should not be using it. Why would you even *want* to use it?
>>> I can
>>> > only imagine using this to do things that are broken. :)
>>>
>>> To clarify (and fix a typo in Kiran's post), he is working on adding
>>> ordered broadcasts to LocalBroadcastManager from the Android Support
>>> package, while maintaining maximum fidelity with the protocol used by
>>> regular ordered broadcasts.
>>>
>>> Most of this can go into (a fork of) LocalBroadcastManager without
>>> issue. However, calling abortBroadcast() on a BroadcastReceiver throws
>>> a RuntimeException ("BroadcastReceiver trying to return result during
>>> a non-ordered broadcast") if you try to use abortBroadcast() without
>>> having the Intent go through the standard sendOrderedBroadcast().
>>>
>>> I have not seen Kiran's code -- I have merely been advising him so far
>>> via email, as this is an itch I had been meaning to scratch myself.
>>> Off the cuff, the options appear to be:
>>>
>>> - use setOrderedHint(), despite it being labeled as "internal", or
>>>
>>> - attempt to override the internal checkSynchronousHint() to not raise
>>> the RuntimeException, or
>>>
>>> - try to fork BroadcastReceiver and use a forked edition with
>>> LocalBroadcastManager and ordered-broadcast support, or
>>>
>>> - abandon LocalBroadcastManager entirely and create a workalike that
>>> supports ordered "pseudocasts" or some such
>>>
>>> Certainly, I am up for other suggestions.
>>>
>>> Thanks!
>>>
>>> --
>>> Mark Murphy (a Commons Guy)
>>> http://commonsware.com | http://github.com/commonsguy
>>> http://commonsware.com/blog | http://twitter.com/commonsguy
>>>
>>> Android Training...At Your Office:
>>> http://commonsware.com/**training<http://commonsware.com/training>
>>>
>> --
>> 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
>>
>
>
>
> --
> 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
