12-29-2010 11:50 AM
To clarify, what I am referring to in my original post as "a timer" was an instance of the Timer class. The Timer is being used as a game timer, like a timer for increasing blinds in Texas Hold 'Em Poker. As such, it's unfortunate that there's no apparent way of keeping the timer going when the app is minimized.
The best solution seems to be to catch the current time in miliseconds using Date() when the app is minimized/deactivated and then to catch the current time in miliseconds again when it is reactivated, and then use the difference to update the Timer. Until a better solution is found, this may be what I'll have to do.
David, the flash.utils.Timer class isn't really intended to be used as the mechanism for timing durations like that. At least, in practice, that's generally not the best way to do that job.
What I think is more typical and reliable in certain ways is to record the start time for an interval, probably using flash.utils.getTimer() instead of Date. Then you use either a Timer, or setTimeout() or setInterval(), or ENTER_FRAME events, as appropriate, to cause your app to wake up and check the elapsed time by subtracting the most recent getTimer() value from the recorded start time. Generally you would have that event/timeout wake up your app somewhat more frequently than the actual duration required, and related more to the granularity/precision you want. For example, if the time to increase the blind is 30s, but it's fine to be within 1s either way, you could wake up your app every second to check the elapsed time so far. That way whether your app is deactivated during that period or not, you know that within 1s of reactivating it the app will be synchronized to the real world again by checking getTimer().
I'd say definitely don't use Date for this since, in my experience using the system time (or "wall-clock time") for timing durations, it's quite possible that clock adjustments, either by the user or by network time servers or by daylight savings time, can lead to large jumps forward or backward in rare cases. The getTimer() value should not exhibit that sort of problem. (Although I don't see that explicitly documented, I believe it's intended that it work that way.)
12-29-2010 12:06 PM - edited 12-29-2010 12:10 PM
i recall discussions from the PlayBook seminars about new notification APIs coming soon to the SDK, similar to those individual app badges in iOS, they will be displayed in a common area for applications globally - the flag icon in the top left of the screen.
perhaps these new APIs could be useful in this particular situation, or at least officially support options for dispatching events based on timers current running in background/minimized applications.