You shouldn't really use just clearInterval/clearTimeout...
@Gordon, I guess you wanted to say ...without arguments.
And even on initialization it could interfere with something that should survive an onInit(), such as permanently saved code, for - for example - support of update over the air.
Therefore, best practices are:
'do not' set intervals or timeouts on upload time
'always' have an onInit() {... (or E.on("init", function(){...) that intentionally starts your code... including all timeouts and intervals
when saving code, save it 'always before running it' (before invoking init())
Even if the intervals or timeouts are embedded a function but that function is - directly or indirectly - called in level 0 (after its definition), those intervals and timeouts get set on upload. Unpredictable behavior and weird side effects are usually the result when saving code that has already began running.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Gordon, I guess you wanted to say ...without arguments.
And even on initialization it could interfere with something that should survive an
onInit()
, such as permanently saved code, for - for example - support of update over the air.Therefore, best practices are:
onInit() {...
(orE.on("init", function(){...
) that intentionally starts your code... including all timeouts and intervalsCode in level 0 (or root level) is executed by Espruino at upload time (see Simple explanation how to save code that Espruino runs on start?).
Even if the intervals or timeouts are embedded a function but that function is - directly or indirectly - called in level 0 (after its definition), those intervals and timeouts get set on upload. Unpredictable behavior and weird side effects are usually the result when saving code that has already began running.