Making an app stop automatically if user is not active

[AlbertAA]

Hello.

Our users are running our apps (educational games) in a browser via a Virtual Machine. We had to move to this solution because (1) in some cases users do not want go through the "trouble" of installing an app on their PCs or Macs (which are often "locked" by their companies anyway). and (2) because we still consider it too difficult/time-consuming to re-develop a LiveCode version which can be published as a standalone running in browser, or simply move directly to a re-implementation to HTML5 (we like LiveCode).

But this means that we need to start caring about connection time (= cost towards our VM/virtualization provider). To address this I was thinking of adding to all our games a simple mechanism which basically:

> Checks users input, and if there is no action (no mouseClick) for 10 minutes it closes the app automatically.

This is not one of the cases where I have difficulties imagining how to do this in LiveCode. Rather the contrary. For instance I could record in some global variable the time of last mouseClick and then then have an idle which fires very 5 minutes and checks if the difference is larger than 10 min, or so. But I wondered if there are ways of doing it avoiding to use idle/wait-based approaches - eg by accessing some more "internal/deeper" parameter like LastTimeMouseClickedWithinApp (which is very likely not to exist ) or others I haven't discovered yet.

Wondering if you have some hints.
-albert

[richmond62]

Why does that make me think of something called 'polling the mouse'?

[dunbarx]

Hi.

Check out the "logMessage" property and the "log" command.

I think you can also exploit the "executionContexts", and possibly the ephemeral "messageMessages" which is undocumented, but can be found here:
http://forums.livecode.com/viewtopic.php?f=9&t=33553

Needs playing with. Good luck.

Craig

[FourthWorld]

If you're comfortable using idle, use it. I don't think you need to use any undocumented features, or make this very complicated at all.

You can lighten the load on the CPU a bit by setting the idleRate to a larger number than its default.

[dunbarx]

Maybe something like this:

Code: Select all

local tTimer

on mouseUp
   put 0 into tTimer
   checkForMouseClick
end mouseUp

on checkForMouseClick
   if tTimer > 600 then -- arbitrary, 10 seconds.
      answer "Time is up"
      exit to top
   end if
   if the mouse is down then put 0 into tTimer
   add 1 to tTimer
   send "checkForMouseClick" to me in 1
end checkForMouseClick

I was scared off from using idle long ago, although MUCH longer ago, in HC, I used it all the time.

Craig

[jacque]

I've had to do something similar. I think using a "send" construct is more efficient and reliable, much like Craig mentioned, but I wouldn't do the check every tick because that would cause a flood of pending messages. Since you're only interested in the time elapsed every 10 minutes, I'd just use that.

For example:

Code: Select all

local sClickTime
local sTimeLimit = 600 -- 10 mins, adjust as needed

on mouseUp
  put the seconds into sClickTime
  checkIdleTime
  --  pass mouseUp -- if necessary
end mouseUp

on checkIdleTime
  if the seconds - sClickTime >= sTimeLimit then
    -- do quit stuff
  else
    repeat for each line l in the pendingMessages -- clear queue
      if l contains "checkIdleTime" then cancel (item 1 of l)
    end repeat
    send "checkIdleTime" to me in sTimeLimit seconds
  end if
end checkIdleTime

[dunbarx]

Jacque is spot on about not interrogating the state of the mouse so often. i wrote it that way so i could test it easily, clicking the mouse within a few seconds to make sure that the flow worked as I wanted. The rapid iteration guaranteed that any click of the mouse would be detected by the state test. It ran far faster than any human interaction with the mouse button.

Definitely a longer interval is better. But if you if you simply "send" in a longer interval, it is unlikely that the mouse will happen to be down at test time.

Jacque's rewrite exploits the pendingMessages, a record of what each send command has been up to. It is compact and clever.

Craig

[jacque]

But if you if you simply "send" in a longer interval, it is unlikely that the mouse will happen to be down at test time.

I didn't really consider that the user might be in the middle of a click at exactly the moment the time limit expired. On one hand, if they're that close to the bell, it's probably okay to say they're too late.

On the other hand, sClickTime could be updated on mouseDown while the check still happens on mouseUp. That should allow a last second click to reset the timer.

[AlbertAA]

Thanks a lot for the suggestions.

I first tried implementing Craig's suggestion, with some adaptations for things like dialogs remaining open/unanswered and things like the user "forgetting" the app and start typing on a different app/window. If finally kind of worked, but was leaving me with a feeling of uncertainty.

Still struggling a bit I decided to review again this issue and was very happy to see Jacqueline's suggestion, which I adopted immediately. It works very smoothly, made me learn about pendingMessages (and checking/canceling from them), and even succeeded in calming down the worries I always have when using recursive functions.

Thank you again to both.