Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Detecting if a user has stopped interacting with a web view for a certain time

Parent

Detecting if a user has stopped interacting with a web view for a certain time

+3
−0

I am interested in finding out all the aspects I need to cover in order to correctly assess if a user has stopped interacting with a web page. So far, I found the following:

  • Idle Detection API - this seems to do most of the work for idle detection. However, it requires user permission
  • Detect page/tab/browser close - this is covered by beforeunload event
  • Heartbeat function - this is useful when idle detection is not allowed or supported. Basic example here.

Is there anything else I should check for? I am currently focused on using this in an Angular SPA, but I guess that it is less relevant.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Why? (2 comments)
Post
+4
−0

The weakness of responding to idle state is that the app might be closed before the idle state is reached, and that a closing app might no longer be able to communicate with the outside world. Saving to local storage rather than remote systems may therefore be more robust and cheaper, allowing more frequent saving. For instance, in a small app I made, I save to localstorage on every keystroke. Worked flawlessly. Many PWA frameworks support this out of the box: for instance, redux-persist for react, or ngrx-store-persist for ngrx.

That is, you don't need to detect idle states to prevent information loss when the user exits without saving.

On the other hand, if you want to track user activity for statistics purposes, calculating an idle state makes sense. It's been a while since the last time I did this, but I did something simple like:

<body onclick="userIsHere()" onkeypress="userIsHere()">
	<script>
		let lastUserInteraction = new Date();
		function userIsHere() {
			lastUserInteraction = new Date();
		}
		function isIdle() {
			const millis = new Date().getTime() - lastUserInteraction.getTime();
			return millis > 5 * 60 * 1000;
		}
		setInterval(() => {
			console.log(isIdle())
		}, 1000);
	</script>
</body>

Since DOM events naturally bubble to the top, these handlers should observe all user interactions. Theoretically, it is possible for a UI element to prevent this with stopPropagation() but I found that the UI elements I used didn't do that.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

Using localstorage (2 comments)
Using localstorage
Alexei‭ wrote almost 3 years ago

Using localstorage is a great idea.

Ref. to "the app might be closed before the idle state is reached, and that a closing app might no longer be able to communicate with the outside", I thought about this and that is why I have mentioned the beforeunload event which allows to mark the tab/browser close for the application. I guess I can use localstorage for that.

meriton‭ wrote almost 3 years ago

I guessed that this was the reason you mentioned onbeforeunload :-) Just to be perfectly clear, the problem I see is that network I/O in onbeforeunload can not be relied on to work, because the application will likely unload before the server response arrives, making it impossible to react to a failure to save. And such a failure is quite possible: For instance, suppose a user disconnects the network before shutting down his notebook, which causes network connectivity to be lost before the beforeunload is triggered ...