09-01-2009 08:43 PM
I am developing a GUI based application for the BlackBerry line which consists of several on-screen bitmap buttons with which the user interacts. The buttons are bitmaps which are drawn in a horizontal field manager with a background bitmap for the field manager -- what would be considered a reasonably simple graphic application.
From initial use and feedback, it has been noted that the application causes the battery to be drained at an accelerated rate. This has been noticed on a Curve 8310 (OS 4.5) and Storm (OS 4.7). I suspect some of this is due to the fact that the user interaction typically occurs on a frequency where the backlight times out (set at 30 seconds), then the user interacts for a few seconds, the backlight times out, the user interacts again -- and the process repeats in this manner over the course of 30 minutes or so.
I've looked at other posts, which typically point to network or GPS use as causes for excessive battery use. This application does not make use of network connections nor GPS, so I believe the only major source of battery use is in the screen display.
I'm looking for thoughts on whether there are implementation specifics within the way the application has created and uses the screen display that I could investigate -- or is it likely the actual use of the application and interaction with the backlight timeout that is the source of the problem.
If the latter is the case, is there a means for an application to programmatically turn off the backlight to conserve battery power.
Thanks for any pointers on this...
09-02-2009 06:01 PM
Sorry, not much help here, but my immediate and probably completely unjustified reaction is that UI interaction does not cause battery drain to a noticeable extent. Do you have some background activity which is causing the screen to be refreshed constantly? In fact is there any background processing or is the UI completely event driven?
My only other suggestion is to use the profiler to see if you can see where significant cycles are being spent.
09-02-2009 09:20 PM
Thanks for the response. To the best of my knowledge, the activity is completely event driven -- there is no background processing driven through separate threads, processes or such. The GUI interaction is primarily tied to the user clicking on a button (bitmap image) which causes the code to paint a "selected" button image and then modify another field also displayed within the GUI. These screen updates based on user action may occur as an invalidate or repaint forcing a a screen update. My sense is that this should not cause an unnecessary drain as it is similar to interacting with any standard GUI based application.
I'll give the profiler a shot as you suggested.
I also found the backlight class that I believe can be used to code up a mechanism to turn off the backlight after a shorter time period when using the application. I may be able to see whether this has an effect on improving battery life.
09-25-2009 03:34 PM
Just wonder if there is any interesting findings using the profiler.
I am investigating a similar issue where our customer says installing and running our application at the background introduces a battery drain.
But my app is not doing any networking nor running any background thread. no clue what is going on.
My customer is using a 8330 ( OS 4.5 ) but a few of my coworkers claim they see certain extent of battery drainage on a BOLD
Is backlight a factor consuming the battery?
09-26-2009 10:28 PM
I tried using the Profiler, but wasn't able to determine anything that I could correlate directly to battery use. The code executed as I expected it to and for those items I could watch with the Profiler, I couldn't see how they impacted battery usage directly.
In the end, I did some informal work -- changing the time for the backlight display and running the app for an extended period of time. This did seem to show some impact as the app was used over that time period -- although it was hard to quantify.
09-28-2009 11:15 AM
Thanks Ed for the info
I run profiler against a simulator , installing and running at the background i dont see any of my code getting executed. I have no idea who that can cause battery drain. Maybe installing and running the app triggers something in the OS? but it is hard to track down.
Also anyone know if it is possible to run profiler again a device ( tethered )? the JDE ( 4.5 ) seeems not supporting it
12-14-2010 05:39 PM
I didn't end up with anything conclusive. I suspect the fact that the popup element causes the screen to become active was part of the issue causing the backlight timeout period to play into it.
12-14-2010 05:51 PM