Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Trusted Contributor
sucroid
Posts: 195
Registered: ‎03-12-2012
My Device: PlayBook
Accepted Solution

The proper way to deal with camera and device standby?

How does one bring the camera back up to life after device comes back from standby?  What's the proper way to handle device sleeping and waking up?  All help appreciated.

Sucroid.com
Sweet Apps for the Fans
BlackBerry Development Advisor
smcveigh
Posts: 668
Registered: ‎11-29-2011
My Device: developer

Re: The proper way to deal with camera and device standby?

Hi Sucroid,

I plan on producing a sample which demonstrates this hopefully over the holidays.

Here is some information that can hopefully get you started...

 

When the screen goes to sleep, the camera hardware is powered down.  There is nothing you can do about this today, aside from applying a keep-awake  to your application's window. (set SCREEN_PROPERTY_IDLE_MODE to SCREEN_IDLE_MODE_KEEP_AWAKE).  Note that this will not save you from a user who hits the power button to force the device into standby.  Nor will it protect you from a situation where your app goes to the background and another app requires video resources which are in use by the camera.  In both of these situations, your app will lose its viewfinder.

 

But all is not lost!  There are some status events you can listen for which will let you know that the camera is shutting down.  You can listen for these events either using an attached status_callback (applied when starting the viewfinder for example), or by explicitly enabling status events using camera_enable_status_event() and waiting for status pulses.  All of these things are detailed in the Camera API docs here: http://developer.blackberry.com/native/reference/bb10/com.qnx.doc.camera.lib_ref/topic/overview.html

 

The relevant status events are:

CAMERA_STATUS_RESOURCENOTAVAIL - This event is reported whenever the camera is about to shut down.  If you have previously called camera_register_resource(), this is the event you would listen for to know that all of your camera buffers are about to be unmapped -- so you should shut down any logic that is looking at them, and then camm camera_deregister_resource().  If you are not physically processing viewfinder buffers, then you don't necessarily need to use this register/deregister mechanism.  It is just there to provide you with a warning, and to enable the camera drivers to wait for you to acknowledge that it is safe to unamp the memory.  Whenever the screen goes to sleep, or the user hits the power button, or some other app needs the camera's resources, you will get this signal.  If you're curious as to the reason, you can check the "extra" uint16_t argument in the status callback for one of the camera_powerdownreason_t values.  Any currently active video recordings or encodings will auto-terminate when this signal is received.

 

CAMERA_STATUS_POWERDOWN - this status event is reported immediately after the camera hardware is powered down.  You cannot interact further with the camera until this status is cleared.  Note that in order to catch this event, you will need to user the event-mode status interface (camera_enable_status_event()), since any status callbacks you may have attached when the viewfinder was started will be cleaned up when the viewfinder shuts down.

 

CAMERA_STATUS_POWERUP - this status event is reported immediately after the camera hardware is powered back up after previously being powered down.  The same not about using event-mode status interface (camera_enable_status_event()) applies in this case as well.

 

 

So, what can you do with this information?

Well, listening for CAMERA_STATUS_RESOURCENOTAVAIL will tell you when your viewfinder is going to shut down.  At that point, your app should enter a state where it is waiting for an event that will wake it back up again...

In most cases, this is navigator's event that tells your app that is is active or foreground again (NAVIGATOR_WINDOW_ACTIVE or equivalent). 

So when your app is told by navigator that it is back in the foreground, you may then restart the viewfinder using camera_start_photo_viewfinder() or camera_start_video_viewfinder() as per your app's requirements.  You will still need to follow the same recipe to start the viewfinder as if this were a cold boot of your app (eg. waiting for your viewfinder window to become available), but you will not need to reconfigure any settings.

 

Okay.. that covers 99% of the use cases you will encounter.  For the remaining 1% use case, you will need to monitor for that CAMERA_STATUS_POWERUP event.  Why?  Well, there is a race condition when shutting things down, whereby if the user wakes the device up while the camera is in the process of shutting down (eg. they hit the power button twice in rapid succession), then the camera will enter it's power-down state, but navigator may not actually signal your app that it should become inactive.  This is because the power-management infrastructure is actually waiting for the camera hardware to power off before the system enters standby.  If the user wakes the device back up, then this action is cancelled, and the device never actually enters standby.  In this corner case, navigator does not tell your app to become active again, because it never told your app to become inactive.  So what are you to do?  Well, I have 2 suggestions:

  1. you can monitor for CAMERA_STATUS_POWERUP using the event-mode interface to the camera hardware.  this is actually the more correct method, and is what we do internally with the BB10 Camera App.
  2. you can use a timer to attempt to re-awaken the camera in the event that this corner case has occurred.  eg. wait for 5 seconds after receiving the CAMERA_STATUS_RESOURCENOTAVAIL signal.  If your app has not been made inactive by navigator, then you can attempt to re-start the camera.

I hope this helps get you pointed in the right direction, and again... I do plan on putting a proper best-practises sample together which will illustrate exactly how to do this when time permits!

 

Cheers,

Sean

Trusted Contributor
sucroid
Posts: 195
Registered: ‎03-12-2012
My Device: PlayBook

Re: The proper way to deal with camera and device standby?

Thanks for the detailed info.  It's very helpful.

Sucroid.com
Sweet Apps for the Fans
Developer
javoid
Posts: 194
Registered: ‎11-24-2012
My Device: Dev Alpha B, Bold 9700

Re: The proper way to deal with camera and device standby?

Please post here when you have uploaded the new sample app. :smileyhappy: