Timer and Webtimer in Web App?

Targets Web
1

Hello all,

Am migrating a rather large web project from 2019 R1.1 to 2022 R1.1

There are MANY errors but right now am focused on the Timer errors. I understand, I think, that there are 2 different timer types. One for server side and one for browser side. Am I right about this?
Are there any docs or other helpful info that I can digest that explains when and how to use these?

Obviously I am a bit confused so want to get some clarity before diving too deep into this aspect.

Thank you.
Tim

2

You have WebTimer with two modes (Browser and Server) and then separate from that Timer, which always runs on server.

Be aware that normal timer doesn’t have context setup, so you need WebSessionContext object there.

3

Hi Christian,

Another question - in Web 1, where did the timer work? Server or client??
Also, the doc says
" Location As Locations
Indicates where the timer will run.
You should only set this property in the Inspector for the WebTimer. Changing it in code has no effect."

So if the timer is created in code, as 99S% of mine were, what is the default - server or client??

Thank you
Tim

4

Try it.
Browser side timers run in JavaScript and trigger action event on server in your code.

5

I use a WebTimer when I have a Session available (preferring ‘Browser’ over ‘Server’ when not time-critical) and a Timer when I need something to run in the App side of my Web App (eg check for emails to be sent) when there is no Session to call the Timer.

Using WebTimer when there is no Session available causes an Exception.

6

It looks like the Locations enum notes are missing from the new docs, I’ll prepare a case to bring them back.

Here is what the old docs say:

"The difference in location is where the timer actually exists at run-time. Both are Session-aware.

Server timers should call the Run event with very little latency, but there is a limit to how many timers you can have active at once because they require resources. Browser-based timers do have some latency, and they increase the traffic between the server and the browser, but the impact on the server is smaller."

It really depends on how you design your app. I’d start using the “server” type, as it will also save lot of bandwidth.

If in the future you need to optimize the app, one of the things you already know now you can try is switching them to “browser”. The difference shouldn’t be too big anyway (the server will still need to process the request coming from the browser)

If you create a Timer (instead of a WebTimer), they will always be server side. Please check the WebSessionContext documentation, and also the example (Examples > Web > WebSessionContext)

3 Likes
7

One thing to consider with Browser side timers: a lot of browsers now pause inactive tabs, which can prevent the browser-side timers from firing.

This was an issue for us in Xojo Web 1, about 4 years ago. At that point, we shifted some client-side timers to server-side, and that resolved the issue.

1 Like
8

It is client side.

1 Like