Re: [android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
I get it now. Thanks for the explanation. I also just realized that the implementation of setOrderedHint() in BroadcastReceiver is a no-op in ICS code-base. All it contains is a comment stating that this method was accidentally left over in the SDK. checkSynchronousHint() now checks for the non-nullness of the instance of the inner class PendingResult. And this time, I do see that the constructor of PendingResult and the setPendingResult() method in BroadcastReceiver(the combination of which would allow me to set the ordered-ness of the broadcast) are both clearly marked with @hide annotation. I'll take a call on whether to go ahead with using BroadcastReceiveranyway, or to create a work-alike. Thanks for your inputs. On Monday, 21 May 2012 21:48:06 UTC+5:30, Dianne Hackborn wrote: On Thu, May 17, 2012 at 11:57 PM, Kiran Rao techie.curi...@gmail.comwrote: using BroadcastReceiver as a separated class not known by the rest of the framework 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. LocalBroadcastManager is not part of the framework. It is a separate helper class in the support library. As long as you are not using these classes with the on-device framework (registering in your manifest, Context.registerReceiver(), etc) then I think you will be fine. -- 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
Re: [android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
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 techie.curi...@gmail.comwrote: 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/**traininghttp://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
Re: [android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
On Thu, May 17, 2012 at 11:57 PM, Kiran Rao techie.curi...@gmail.comwrote: using BroadcastReceiver as a separated class not known by the rest of the framework 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. LocalBroadcastManager is not part of the framework. It is a separate helper class in the support library. As long as you are not using these classes with the on-device framework (registering in your manifest, Context.registerReceiver(), etc) then I think you will be fine. -- 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
Re: [android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
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.comwrote: 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/**traininghttp://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
[android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
I am trying to add ordered broadcasting functionality to LocalBroadcastReceiver class. I just noticed this method: http://developer.android.com/reference/android/content/BroadcastReceiver.html#setOrderedHint(boolean) The docs have this to say : For internal use, sets the hint about whether this BroadcastReceiver is running in ordered mode. Now, the For internal use part makes me nervous. Is it safe to use this method in my code? I mean, the method *is* published as part of the API (as opposed to being hidden with the @hide annotation in the source). Secondly, changes to LocalBroadcastReceiver does qualify as internal code! -- 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
Re: [android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
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. :) On Thu, May 17, 2012 at 6:06 AM, Kiran Rao techie.curi...@gmail.com wrote: I am trying to add ordered broadcasting functionality to LocalBroadcastReceiver class. I just noticed this method: http://developer.android.com/reference/android/content/BroadcastReceiver.html#setOrderedHint(boolean) The docs have this to say : For internal use, sets the hint about whether this BroadcastReceiver is running in ordered mode. Now, the For internal use part makes me nervous. Is it safe to use this method in my code? I mean, the method *is* published as part of the API (as opposed to being hidden with the @hide annotation in the source). Secondly, changes to LocalBroadcastReceiver does qualify as internal code! -- 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
Re: [android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
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 -- 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
Re: [android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
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 -- 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
Re: [android-developers] BroadcastReceiver: Is it safe to use setOrderedHint method in my code?
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/**traininghttp://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
