Android Question When are timers killed?

[Troberg]

I have a need for several timers to hide stuff on screen after a certain time, such as OSD icons or other temporary info.

Now, I read somewhere that timers live on even if they go out of scope if there is an upcoming timer event, as that queued event keeps a reference to the timer.

Does this mean that it's safe to not only start a timer in, say, the sub that shows the object, but also dim it there, instead of at wider scope? In other words, I create the timer in that sub and starts it just before leaving the sub, and rely on the upcoming events reference to keep it alive long enough for it to fire once (which is all I need).

If this is a safe and sane thing to do, it would save me having unnecessary timers dimmed at a wider scope.

 

[NJDude]

Timers must be declared in Process_Globals, dimming timers in subs will result in creating several timers, you should only enable/disable the timers in subs.

 

[thedesolatesoul]

The timer will keep on firing.
Regardless of where you Dim the timer, it is always associated with the "process" context.

 

[Troberg]

Timers must be declared in Process_Globals, dimming timers in subs will result in creating several timers, you should only enable/disable the timers in subs.

But that's what I want. I want several timers, one for each shown object (or at least some of them). The alternative is to have one timer and then have a list of objects with their "kill times", and, say, every 100 ms, kill all objects that are overdue.

 

[NJDude]

Then create your timers in Process_Globals, different names, different intervals as needed.

 

[Troberg]

The problem with that is that I don't know how many I'll need at compile time.

 

[NJDude]

I don't know what you are really trying to accomplish, but I would suggest you rethink your approach, creating a ton of timers sounds wrong to me.

 

[Troberg]

I don't know what you are really trying to accomplish, but I would suggest you rethink your approach, creating a ton of timers sounds wrong to me.

I agree, and that's where I started the train of thoughts. The thing is, I won't need many at once. At most, I'd say, there'll be two or three such objects shown at once. In that context, it makes sense with a timer that doesn't live very long, instead of dimming all possible timers on a process level.