stickybroadcast receiver

[RupaSunita n]

Hi,

I'm using broadcast receiver to get notifications for HW status (attach/detach).
During application suspend/resume, the intent state and hence the HW state is lost from the app, hence the feature is not working once it resumes.
the application is not caching the last value before going to suspend state.

Is there any interface in BroadcastReceiver to read the latest sticky state??

I'm exactly looking for, how to use this below statement

"stickyBroadcasts are broadcasts whose data is held by the system after being finished, so that clients can quickly retrieve that data without having to wait for the next broadcast. "

current options i have in hand are:
(1) unregistering and re-registering on suspend/resume
(2) using local variables to remember the state (this may not be a complete fix)

Thanks & Regards,
Sunita.

[RupaSunita n]

Hi,

There seem to be another way of getting the last broadcasted event:

You can call registerReceiver() with your IntentFilter and a null BroadcastReceiver to get the last-broadcast Intent

This approach is working for me.
But i would like to check on:
(1) whether this is an acceptable approach?
(2) whether this needs any un-registration?
(3) does it have any memory leak??


Thanks & Regards,
Sunita.

[Dianne Hackborn]

For a receiver there is NO DIFFERENCE between a sticky and a non-sticky broadcast.  It is all a question of whether you send the broadcast as sticky.  If you do, it will be remembered, so if someone registers they will immediately get the last broadcast state as if it was just sent.

On Tue, Jan 18, 2011 at 12:16 PM, RupaSunita n <rupasu...@gmail.com> wrote:

Hi,

There seem to be another way of getting the last broadcasted event:

You can call registerReceiver() with your IntentFilter and a null BroadcastReceiver to get the last-broadcast Intent

This approach is working for me.
But i would like to check on:
(1) whether this is an acceptable approach?
(2) whether this needs any un-registration?
(3) does it have any memory leak??


Thanks & Regards,
Sunita.

On Tue, Jan 18, 2011 at 1:34 PM, RupaSunita n <rupasu...@gmail.com> wrote:

Hi,

I'm using broadcast receiver to get notifications for HW status (attach/detach).
During application suspend/resume, the intent state and hence the HW state is lost from the app, hence the feature is not working once it resumes.
the application is not caching the last value before going to suspend state.

Is there any interface in BroadcastReceiver to read the latest sticky state??

I'm exactly looking for, how to use this below statement

"stickyBroadcasts are broadcasts whose data is held by the system after being finished, so that clients can quickly retrieve that data without having to wait for the next broadcast. "

current options i have in hand are:
(1) unregistering and re-registering on suspend/resume
(2) using local variables to remember the state (this may not be a complete fix)

Thanks & Regards,
Sunita.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@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.

[RupaSunita n]

Hi Dianne Hackborn,

Thanks for the comment.
Yes, i understand that, but my question is from the receiver side.
I have a sticky broadcast, but how to use this sticky feature from Receiver side?
My requirement is that, to get the event state without waiting for next broadcast.
and i had already registered, hence can't register again.
The situation arised when my app is suspended hence lost some of the event broadcasts in between.
On resume i want to read the sticky event last broadcasted.

currently i have implemented the below approach:

Calling registerReceiver() with the IntentFilter and a null BroadcastReceiver to get the last-broadcast Intent

This approach is working for me.
But i would like to check on:
(1) whether this is an acceptable approach?
(2) whether this needs any un-registration?
(3) does it have any memory leak??

Thanks & Regards,

sunita.

[Dianne Hackborn]

You don't need to register again.  Once you register, you will receive the first state.  After that you will receive the state each time it changes.  You don't need to do anything special.  If you think you need to do something special, you have some other problem.

[FrankG]

On 18 Jan., 20:34, RupaSunita n <rupasunit...@gmail.com> wrote:
> Hi,
>
> I'm using broadcast receiver to get notifications for HW status
> (attach/detach).
> During application suspend/resume, the intent state and hence the HW state
> is lost from the app, hence the feature is not working once it resumes.
> the application is not caching the last value before going to suspend state.

Just a question .. who sends the intent you are interessted in ?

Maybe you don't need the intent and instead poll for a sysfs entry
change or something like this ?

Good luck ! Frank

[RupaSunita n]

Thanks Dianne and Frank.

Hi Dianne,
 yes I'm getting the onReceive notification everytime the state is changed.
But my requirement is to get the status in between two broadcasts.
you can ask why do i need in between two broadcasts?
This is required because my app was suspended for some time during which i dont know what happend to hw state.
Thats why, on resume call i would like to know the last braodcasted state, i cant wait for next broadcast. Hope i'm clear now.

Hi Frank,
I get an event from the system observer for which i'm one of the receivers.
i think reading via sys_fs may not be a good solution, thats why i'm not opting for this.

Thanks & regards,
Sunita.

[RupaSunita n]

Hi Dianne,

Could you please comment on my requirement and possible solution with observer/receiver apis.
As i already mentioned in the same mail thread, what about the below approach for getting status in between braodcasts?

currently i have implemented the below approach:

Calling registerReceiver() with the IntentFilter and a null BroadcastReceiver to get the last-broadcast Intent

This approach is working for me.
But i would like to check on:
(1) whether this is an acceptable approach?
(2) whether this needs any un-registration?
(3) does it have any memory leak??


Thanks & Regards,

Sunita.

[Christopher Tate]

On Wed, Jan 19, 2011 at 7:04 AM, RupaSunita n <rupasu...@gmail.com> wrote:
> Thanks Dianne and Frank.
>
> Hi Dianne,
>  yes I'm getting the onReceive notification everytime the state is changed.
> But my requirement is to get the status in between two broadcasts.
> you can ask why do i need in between two broadcasts?

I think you are misunderstanding what sticky broadcasts are. I
suggest you re-read the BroadcastReceiver documentation, paying
particular attention to the commentary on sticky broadcasts. When you
register, you are told what the most recently broadcast status is.
Just remember that data -- it correctly describes the status until you
actually receive a new broadcast.

> This is required because my app was suspended for some time during which i
> dont know what happend to hw state.
> Thats why, on resume call i would like to know the last braodcasted state, i
> cant wait for next broadcast. Hope i'm clear now.

When you say your app "was suspended," does that mean that it has
unregistered its broadcast receiver? Or are you just talking about
the normal pause/resume Activity lifecycle?

If you have actually unregistered your broadcast receiver, then it's
true that you will not see a notification of the hardware state
change. When your application registers its broadcast receiver again,
however, you will get a copy of whatever state change intent was most
recently broadcast, even if that happened while your application was
shut down. That is what sticky broadcasts are *for*.

--
christopher tate
android framework engineer

[RupaSunita n]

Thanks a lot Christopher.

On Thu, Jan 20, 2011 at 9:11 AM, Christopher Tate <ct...@google.com> wrote:

On Wed, Jan 19, 2011 at 7:04 AM, RupaSunita n <rupasu...@gmail.com> wrote:

> Thanks Dianne and Frank.
>
> Hi Dianne,
>  yes I'm getting the onReceive notification everytime the state is changed.
> But my requirement is to get the status in between two broadcasts.
> you can ask why do i need in between two broadcasts?

I think you are misunderstanding what sticky broadcasts are.  I
suggest you re-read the BroadcastReceiver documentation, paying
particular attention to the commentary on sticky broadcasts.  When you
register, you are told what the most recently broadcast status is.
Just remember that data -- it correctly describes the status until you
actually receive a new broadcast.

 

Sunita --> Yes, because of sticky broadcast only, when i register for the first time,
I get the latest (the current) state immediately (even though the state was changed sometime in the past).
This feature is working fine.

> This is required because my app was suspended for some time during which i
> dont know what happend to hw state.
> Thats why, on resume call i would like to know the last braodcasted state, i
> cant wait for next broadcast. Hope i'm clear now.

When you say your app "was suspended," does that mean that it has
unregistered its broadcast receiver?  Or are you just talking about
the normal pause/resume Activity lifecycle?

 Sunita --> No, the app didn't unregister for broadcasts. It is just going to suspend state, in which state
it can't service any onReceive calls (it means all the broadcast events are missed).
Hence when it resumes, it has to know the latest broadcasted value which it has missed.
And it cant wait for next broadcast.
Since anyway it is not processing onReceive calls, do you recommend me to unregister while suspending??
and re-register on resume??
Is there anyway to handle this without un-registering while suspending? This is what my original question.

[RupaSunita n]

Thanks Christopher.
My answers/queries are below.

Thanks & Regards,
sunita.

[Dianne Hackborn]

On Thu, Jan 20, 2011 at 8:13 AM, RupaSunita n <rupasu...@gmail.com> wrote:

 Sunita --> No, the app didn't unregister for broadcasts. It is just going to suspend state, in which state
it can't service any onReceive calls (it means all the broadcast events are missed).

I don't know what you mean by "suspend state."  As long as you have registered to receive a broadcast, you will receive it when sent.  If you aren't remembering those when in your "suspend state," that is just an issue in your code that you should fix.

 

Since anyway it is not processing onReceive calls, do you recommend me to unregister while suspending??
and re-register on resume??
Is there anyway to handle this without un-registering while suspending? This is what my original question.

If you don't unregister, you will continue to receive the broadcasts.  Because...  well, your receiver is still registered for them.

[RupaSunita n]

Hi Dianne,

Thanks for the clarification.
As  i had mentioned in the very first mail, I was considering remember the state inside app when it is suspended as one of the options.
I just wanted to confirm that this is the only approach.
I was thinking that there would have been a mechanism for receiver to read the state as and when it needs (without waiting for next broadcast), so wanted to explore that option before going with local variable mechanism.

Thanks & Regards,
Sunita.

--

[Dianne Hackborn]

Tell me what you think "suspended" means, because that is not a concept Android has.

[RupaSunita n]

Hi Dianne,

Thanks a lot for taking this forward.
this is related to videoview listening to HDMI events from HDMI observer.
I'm actually playing a clip on HDTV from Gallery app and press homebutton. This is when Video view gets suspend call.
Then i play music or something else, then resume the gallery from active applications list.
This is when VideoView gets resume call.
Now, VideoView renders playback on LCD because it creates a new surface and this surface is set for LCD.
Unless i get another HDMI attach/detach event, VideoView in not aware of the HDMI status.
As video view is not registering on resume (because it is not unregistered while suspend call), i'm looking for any api
that my receiver can call to get the current state of the HDMI event in the system which was last broadcasted.
The obvious solution is remembering the state while going to suspend.

Thanks & Regards,
Sunita.

[Dianne Hackborn]

First, there is no "HDMI" state in Android, so that is something you or someone else has added to the base platform, so you can make it behave however you want.

Second, there is no need to go through contortions for this with broadcasts.  As I have said, until you explicitly unregister you will continue to receive broadcasts.  Period.  End of story.  Nothing to discuss here.  If you want to continue receiving broadcasts, just don't unregister.  You will receive them.  You will not miss any.  If you are having problems here, it is something in your code that you can fix.

Third, if you do ever unregister (or your process gets killed), upon next registering for a sticky broadcast you will immediately receive a broadcast of the last sent state.  So again you don't need to do anything special here, you will always have the most recent state.

I suggest directing further questions to android-developers, since broadcasts is just a standard part of the SDK and there are many people there who can help with how they work.

[RupaSunita n]

Thanks Dianne.

Regards,
Sunita.