Debounce explained in-depth
Here we will explain the purpose, functioning-of and how-to use the Advanced Triggers Debounce functionality.
Purpose
Debounce let’s you put limits on how many times a certain event, in this case a trigger, gets executed.
Debounce is used a lott for limiting the retrieving of results from input, for example, a textbox that shows a list based on the value typed.
Usually, a textbox like that, or a filter textbox, don’t refresh the results (selectlist for example) on every key pressed on the keyboard.
Mostly the have a simple debounce of f.i. 300 milliseconds.
Meaning that, when you start to type, it will only ask the results every 300ms with the, then, last value.
So, let’s say you enter a word of 10 characters (lets use characters as example). If you type that word in 400ms, it will request the results/list twice: once after 300ms, with f.i. “charact” and again after 400ms now with the full word “characters”.
This helps to save a lott of resources and not bottle-neck your whole system by requesting useless results that are no longer needed.
The results for “c”, “ch”, “cha”, “char”, etc, are not needed.
Functioning-of
Advanced Triggers’ Debounce has three options:
-
Execute last one waiting after each [number of] ms.
This one is used in the example in the Purpose section.
After each [number of] ms, the flow will get executed with the last requested trigger and tokens. -
Execute at start, then allow execution after each [number of] ms.
As soon as a trigger gets requested to execute, it will.
But all next requests to the trigger are not executed, if the are requested within the [number of] ms.
Only after that amount of time can the trigger be requested and will it executed again, once, to then block again for that amount of time. -
Execute at start, then allow execution after each [number of] ms, finish with last one waiting.
The same as above, but after the [number of] ms, if (a) trigger(s) was requested within that amount of time, it will, after that amount of time, execute the last one waiting.
This means that, you can’t/shouldn’t use the Start [event] flowcards sequential for these kind of debounce triggers.
All trigger requests within in the blocked time, will be put on hold.
Only after another trigger is requested, will another on-hold be returned as not-executed.
Or, after the [number of] ms has elapsed, will the last one (the only one waiting, because the rest before it get’s dropped) be executed.
How-to use
In the Share Your Device! templates, i have placed an example on how-to use the debounce with an AVD.
In the The Flow Exchange(r) templates, i have also placed a Debounce Example.
Here is the basic idea:
When you execute this in the FlowEditor(!), you will see: Test 1, Test 2, Test 5 and Test 6.
----- to be continued ----
