Open thejoshwolfe opened 8 years ago
Hmmm. Seems a nice idea, and since the timer uses timestamps of when the timer started, this could be recovered quite easily. But for that I would need to rethink a bit how the timers are saved (I think they're saved quite badly right now). I'll think about that, thanks !
Another way this could be done is to prevent refreshes (i.e. bind to the keys or create a popup if the user tries to navigate away)
Well, this could be done too, but what happens if the user closes the page plain and simple ? Being able to resume from the last load is a great efficiency tool too, this way you don't have to find and load your timer every time you launch the page.
There's 2 issues with this:
So you either have to sacrifice correctness or being able to refresh the page (or do some hybrid approach). Splitty seems to use the Date API at the moment.
Indeed it uses the Date API. I haven't thought about resynchronizations... That may cause a problem if there's a resync in the middle of a run even without reloading the page though ?
I don't have any idea to address this problem, do you have some ?
One of the scariest things about using a webapp as a timer is losing data when you unload the page (refresh, navigate away, etc.). It should be possible to record timestamps in localStorage so that reloading the page resumes right where it left off.