Clearing Timer.Timer() object instance when onHide() is called during app screen navigation?

mmcleod said:

However, I do not understand how to clear an instance of Timer.Timer() from memory so that I may use different timers elsewhere within the app.

In Monkey C, an instance of any class (also known as an object), will be cleared from memory as soon as there are no references to the object. In other words, an object stays in memory as long as there is at least one reference to it. This form of memory management is known as reference counting.

A reference to an object can be stored in a local variable, class member variable or global variable.

Once a local variable goes out of scope (e.g. when the containing function returns), then that variable is destroyed, and it no longer counts as a reference to its value.

In all cases, if a given variable references an object, and the same variable's value is changed to something else (such as null or a different object), then the previous object is no longer referenced.

The most common way to ensure that an object is destroyed is to set all referencing variables to null (or to allow them to go out of scope, if they are local variables).

e.g.

var x;
var y;
//...
x = new Timer.Timer(); // x references the new timer object (for a total of 1 reference)
y = x; // y also references the timer (there are now 2 references)
x = null; // x no longer references the timer (there is now 1 reference)
y = null; // y no longer references the timer (there are now 0 references, and the timer object will be destroyed)

In your case, you could create and destroy your timer in onShow() and onHide().

Another approach could be to keep a single Timer.Timer() instance in the app class, and provide methods in the app class to access the timer. This is probably not the cleanest approach, though.

flowstate

Thank you.  This is exactly the understanding I was looking for.

How is it possible to use "#" in "(timer # null)I"? Please explain!

!=

not

#

how is it possible on the code section above with timers example it look like not equal symbol "≠"? 

Bodya said:

how is it possible on the code section above with timers example it look like not equal symbol "≠"? 

Sorry for the screenshot, the forum has been code blocking us for months now.

The actual text is "timer != null". It's displayed in the screenshot as "timer ≠ null" due to a (somewhat controversial) coding font feature called ligatures.

Personally I can see both sides of the argument. On the pro-ligature side, they look "cool" (or at least they did 5 years ago), and they arguably focus on the meaning of the code as opposed to the individual characters. On the anti-ligature side, they can be confusing and obscure meaning.

https://www.google.com/search?q=ligatures+code

Outside of the context of coding, it's somewhat similar to how phones, Microsoft Word, and macOS will change straight quotes to curly quotes, and double hyphen ("--") to em dash, except ligatures are display only. (With ligatures, the underlying text is unchanged, it's only the display of the text in supported IDEs that is changed.)

In the future I should probably disable ligatures before taking screenshots of code. However, when I take a screenshot of non-trivial code, I usually also include a link to the actual text on pastebin, where ligatures are not an issue.

flowstate said:

The actual text is "timer != null". It's displayed in the screenshot as "timer ≠ null" due to a (somewhat controversial) coding font feature called ligatures.

The forum won't let me edit the original comment, so here's my edited text:

"The actual text is "timer != null". It's displayed in the screenshot as "timer ≠ null" due to a (somewhat controversial) coding font feature called ligatures, which combines multi-character coding symbols such as "!=" and "==" into a single character, when using a supported font (such as FiraCode or Cascadia Code) and app (such as VS Code, neovim, iTerm2 and Windows Terminal)."

I'm sure the tide will eventually turn against ligatures, same as dark mode is already falling out of favour (in some cases).

Playing with this feature in Windows Terminal (Command Prompt), it produces arguably incorrect behavior when you type "=" at the beginning of a command line, when using the (default) prompt that ends with ">": the ">" and "=" are combined into ≥ even though that's clearly not the meaning in that context.