[Calendar update fixed] Reuse and dependency-inject Calendar

[Doctoror]

This fixes #3

This is an amended commit that fixes time update issue.
Calendar will recompute time around every 40 seconds (every 800 frames assuming 20 fps).
Why 40 and not 60 seconds were chosen is to reduce possibility of being late by one minute for events like New Year.

[SCratORS]

Does it even make sense to cache the calendar? Using it with every "update" does not entail any load.
I won't merge yet. I will leave this "pull request" open for the future.

[Doctoror]

New calendar instance was created for every frame, which is quite expensive, see
https://stackoverflow.com/questions/28704832/calendar-instances-are-particularly-expensive-to-create

Also, for every frame, Calendar instance was created twice, once for renderer, once for scene, meaning duplicate work for each frame and slightly different time between scene and renderer.

[SCratORS]

Convinced

[SCratORS]

if the phone is with the screen off, then all application activity stops. this means that the counter also stops working. when the background or animation changes when the screen is turned off, then after turning on the screen, those animations and backgrounds that were before the screen was turned off are played, in order for them to update, you must look at the screen for 800 "update" cycles, that is, 40 seconds, after which everything will change. But the user will not look to wait for the animation to change, he will say after 5 seconds that there is no animation change and will give a bad rating.

[Doctoror]

Yes, good point, I haven't noticed your comment earlier. Noticed it just now.