Bump! I'm still looking for clarification on this comment:
using BroadcastReceiver as a separated class not known by the rest of the > framework On Friday, 18 May 2012 12:27:38 UTC+5:30, Kiran Rao wrote: > > 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 BroadcastReceiverlook-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 BroadcastReceiverobjects; > 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 <[email protected]>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 <[email protected]> >>>> 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 [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 >>> >> >> >> >> -- >> 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
