search

spazproject / Spaz-Enyo

A version of Spaz targeted for tablet devices
http://getspaz.com
Other
45 stars 10 forks source link

setInterval does not fire if card is in background #149

Closed funkatron closed 12 years ago

funkatron commented 12 years ago

This is a thing in webOS 3.0.2, apparently intentional, where they disable setInterval from firing. Will try swapping in a setTimeout that re-sets itself.

willhoney7 commented 12 years ago

I thought that setTimeout was what was disabled in the background, not setInterval?

Is it both?

funkatron commented 12 years ago

Seems to be both.

Ed Finkler Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, August 24, 2011 at 3:48 PM, Tibfib wrote:

I thought that setTimeout was what was disabled in the background, not setInterval?

Is it both?

Reply to this email directly or view it on GitHub: https://github.com/funkatron/Spaz-Enyo/issues/149#issuecomment-1893605

willhoney7 commented 12 years ago

ERGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHH

funkatron commented 12 years ago

exactly.

Ed Finkler Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, August 24, 2011 at 3:50 PM, Tibfib wrote:

ERGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHH

Reply to this email directly or view it on GitHub: https://github.com/funkatron/Spaz-Enyo/issues/149#issuecomment-1893625

joshthecoder commented 12 years ago

Here's my first take at implementing Alarm based refreshes. Appears to work good so far. Only issue I have noticed that's a biggy is each refresh marks all statuses as "read". This shouldn't happen, the unread count should just go up until the user reads through them or marks all as read.

Please review and let me know areas of improvement. I left in the setInterval code, it's commented out. I imagine we need a way to configure between alarms and setInterval to support non-webOS (ex: chrome).

joshthecoder commented 12 years ago

Oh also the interval frequency is hard coded at the moment. Alarms are set to fire in HH:MM:SS formatted string. We can probably just store the interval in minutes instead of seconds to make it simple.

funkatron commented 12 years ago

Let's stick with the current storage format. converting old users to the new stuff means we have to keep one-time conversion code around forever, and it's a real pain.

I don't think we should push it up past 5m anyway; gets battery drainy. 8)

I think we may need to switch to a headless startup, because if an alarm fires while the app is closed, it will re-open the app's card otherwise. You could get around this as long as you cancel the existing alarm on shutdown, but I worry that might not be easy – under Mojo it was basically not possible to do this reliably, for example.

joshthecoder commented 12 years ago

The alarm is cancelled when the app unloads (unload method). Seems to work fine and doesn't reboot the app. Eventually I am planning to try implementing the polling into a service (Node). Might help improve UI performance and also avoid this alarm/setinterval trouble.

funkatron commented 12 years ago

cool, if you're seeing decent handling with unload, let's at least go with this for now and push it out to the folks who were asking about it for testing.

funkatron commented 12 years ago

also, yes, a Node.js approach for grabbing and processing data makes the most sense, imho.