Bruno-Isa LAMOUR-ARNOULD that highly depends on your device, especially if you’re asking for a percentage value. I guess, as Pierre Hébert knows how to code efficient, that they don’t consume battery while not active (e.g. screen off).
Very low. Unless you use animate and keep your screen on, watching the animation.
Handling of variables is reasonably cheap. To tell the truth there is a big optimization that I even skipped in favor of code simplicity because it was fast enough. I wouldn’t say this is “lightning fast” because of the possible use of interpreted JavaScript, but for the purpose it is good enough.
Animation is another issue: animating the clock hand every second with an animation duration of 400ms means that the app is kept busy computing and drawing stuff 40% of the time. At least when the app is active (foreground, screen on), otherwise it is suspended and everything is on hold.
< ![CDATA[
What do you want exactly?
]]>
< ![CDATA[
TrianguloY I want to know the battery consumption with bindings
Seems not so much
]]>
< ![CDATA[
What I don’t understand is ‘battery consumption’
A percentage? A graph? A velocity?
]]>
< ![CDATA[
TrianguloY is it using 10% every hour or 1 or nothing ?
Or 50% lol
]]>
< ![CDATA[
Bruno-Isa LAMOUR-ARNOULD that highly depends on your device, especially if you’re asking for a percentage value. I guess, as Pierre Hébert knows how to code efficient, that they don’t consume battery while not active (e.g. screen off).
]]>
< ![CDATA[
Lukas Morawietz yes. Just curious if I set a bindings using the seconds ! For now using dynamic text for my clock with seconds
]]>
< ![CDATA[
Oh wait, you asked the battery that consumes the binding feature.
For unknown reasons I understood that you wanted you have a binding variable that shown the battery consumption, that’s why I asked those questions.
Sorry!
]]>
< ![CDATA[
TrianguloY no prob ☺
]]>
< ![CDATA[
Very low. Unless you use animate and keep your screen on, watching the animation.
Handling of variables is reasonably cheap. To tell the truth there is a big optimization that I even skipped in favor of code simplicity because it was fast enough. I wouldn’t say this is “lightning fast” because of the possible use of interpreted JavaScript, but for the purpose it is good enough.
Animation is another issue: animating the clock hand every second with an animation duration of 400ms means that the app is kept busy computing and drawing stuff 40% of the time. At least when the app is active (foreground, screen on), otherwise it is suspended and everything is on hold.
]]>
< ![CDATA[
Pierre Hébert great. Thank you for explanation
]]>