06-14-2011 10:53 AM
As a Webworks developer of a Playbook timer based app (PomTracker) I wanted to ask if I'm right in concluding that at the current time there is no way that timer based apps will work beyond a 5 minute countdown?
The issue - that has been discussed a lot recently - is that the Playbook has a maximum standby timeout of 5 minutes. When it goes into standby, *most* apps are frozen until the device is woken up. Now this is a huge issue for timer apps - like mine - as they need to be able to run, or at least monitor the timer for the full duration and then trigger some action (e.g ringing an alarm bell).
Am I right in thinking that there is no current way in the Webworks API to tell the Playbook to stay out of standby or - more usefully - allowing the app to run while in standby but then wake up upon the timer event firing?
I can't see any option to allow this so I'm left in the situation of having an app that is essentially useless as the user will need to keep waking up the device to be able to complete a timer cycle of 25 minutes (the default on my app).
The weird thing is, on the last version of the O/S (the one before the recent Flash player security fix one), my app did run when in standby and would ring the alarm at the end - though this wasn't that consistent - but with the latest o/s when it enters standby, while upon waking up the timer is at the right time it won't ring the alarm until woken up.
Ultimately I'm hoping that RIM are working on a solution to this - perhaps an extension to the Webworks API to allow us to keep the backlight on, or allow it to go off (to conserve battery) but allowing the app to continue running.
Ideally I'd like to give the user the option of leaving the screen on (especially if on mains power).
At the moment this is a *huge* hole in the Webworks system and stops us developing a lot of apps that rely on timer events or streaming audio etc..
06-14-2011 03:38 PM
There are actually two issues here, largely unrelated.
One is the ability of an app to get CPU time while the system is on standby. In an AIR app this can be done by manipulating the QNXSystemPowerMode settings. In a WebWorks app you'd have to hack this into the AS3 code, or use something like the <inactivePowerMode>throttled</inactivePowerMode> setting in your blackberry-tablet.xml file. Note that this is not something you should do merely to have your app wake up to check a timer, and that leads to the other, unrelated issue.
The second issue is poor design and programming of timer features. Many people implement things like this by starting a "countdown", and requesting a periodic event (e.g. setInterval) at, say, one second intervals. When the event is received, they decrement the countdown and, if the countdown gets to zero or a negative value they act on it.
The problem with this approach is that it relies on the app getting every one of those events, merely to decrement a counter. If the app stops getting events (e.g. when the system is on standby, or just when the app is inactive), the timing is thrown off.
The correct way to implement something like that (and most time-related features) is to record a start time, calculate a stop time by adding a delta for the desired period, and then whenever you do manage to get an event, you compare the current time against the stop time to see if you're now past it.
For an application which wants to show the elapsed time, you would not just increment a counter with every event, but rather would subtract the current time from the start time whenever you do get an event, and that's the elapsed time.
There are other use cases, most of them handled the same way. The advantage is that you can miss any number of events, and the elapsed time, or countdown, is always correct, even if because your app was inactive you exceed the desired period, countdown goes negative, or whatever. Another key advantage on a mobile device is that you may not have to wake up nearly so often, so you'll save power.
There are corner cases involving daylight savings time changes, large clock changes, and so forth, which most apps can ignore without much risk of it being a problem. Daylight savings time changes during the night, so the risk of that interfering is low. User can generally have the time set automatically, and generally the OS will do that in small increments that won't affect most apps. If an app is "mission-critical" enough that these issues are a real concern, then the crude "require receipt of every periodic event" is even more of a problem: it should still not be used.
06-14-2011 05:08 PM
Thanks for your comprehensive answer, although I'm not sure it really helps in my case.
I had already tried the inactivePowerMode change, although I had it set to 'normal'. I just tried with it set to throttled but my app still has problems. Weirdly, if I start the timer and then hit the power icon and choose 'stand by' the app does play the alarm. However, if I let the app go to stand by after 5 mins - e.g if timing for 10 mintues it doesn't play the alarm and has to be woken up to show it's hit 00:00.
It therefore appears that it is just not possible to get around this limitation at the current time.
Also countdown wise, my countdown timer is meant to show each second passing as it counts down. I actually use a jquery plugin to handle this but assume it does use the setInterval method.
Even with your method I would still have a fundamental problem here. Namely that once the app goes into stand by it stops receiving events so has no way to sound the alarm. The thing is though, once I wake the app up it does show the correct timing - i.e the timer does not stop. Not sure if this infers the jquery plugin is using the method you describe.
The bottom line is, I need a way to ensure my app runs while in stand by and can sound the alarm as required.
It would seem that at the current time it is not possible to do this or to ensure that the Playbook does not go into stand by.
06-14-2011 05:19 PM
06-14-2011 05:30 PM
Ah that is some great work to try and find a way to solve this issue. Also I do appreciate the advice on how to approach timing. If I wasn't using the JQuery plugin timer system I would look at playing with the idea of comparing against the start time.
So it looks like when compiling a Webworks app, that not all the options set up in blackberry-tablet.xml are being passed through to the Air compiler. It would be really useful if this was fixed to give us more control over the behaviour of our apps.
I really want to have the control over the backlight (stand by mode) as well as being able to allow my app to go into stand by (to conserve battery) but still run the app so it can track the timing and play the alarms as required.
It's frustrating at the moment as it means my app is pretty useless.
Fingers crossed it get's added soon.. Oh and keep up the experiementing as you never know what you might stumble upon.
06-14-2011 05:39 PM
06-14-2011 06:13 PM
I just edit: C:\Development\Blackberry Playbook\WebSDK 1.0\bbwp\AirAppTemplates\src\blackberry-tablet.xm
Yeah I certainly think that at the current time, Webworks applications are fundamentally flawed in terms of timing and anything that needs to run past 5 minutes...