Let's say I have a button and onclick it changes components state to timer, so its state goes from 5 to 4,3,2,1 every second but if page is refreshed the value is lost since it is not stored anywhere and is rendering on client side.
How can I make this function value not to be lost when page is refreshed and be broadcasted to all users.
I do not want to use database since this function will be used a lot and would slow the db connection network also there might be a delay on database and timer would not update and server respond in time.
Any other method?
You need a server. You might not need a database, but if you're trying to share a global state, it needs to be stored somewhere that is not just a webpage. I'd suggest websockets. Every user could connect to your server, and when any of them hits the button, they'll all be informed, you can then kick off the timer in each browser, or send out second events from the websocket.
Let's say the timer is the same for all users. Really all you need to be storing server-side is a value for time zero. If you don't need to persist that value over server restarts (which needs a database), it could simply be a value in memory on the server. All the client needs then is to download this timer end value, and it can show the ticking client side by using a timeout.
Related
I believe I can use utilize the following functions to create delayed JavaScript alerts:
setTimeout(), clearTimeout(), setInterval() and clearInterval()
But how can I use them accross postbacks. For example:
A user has a list of reminders stored in the database. When user logs into site I can access those reminders and call something like:
setTimeout(function() { alert("Reminder 1"); }, 10000);
Depending on when the reminder due date/time is.
However as the user switches pages before the alert notification happens I believe the setTimeout call won't persist.
Is the only way to get this to work to look up the users reminders on every single postback and do a setTimeout on every page or in some sort of master page?
This is not really the way to do this. If your trying to build some sort of notification system then ideally it should be driven server side.
In a normal multi-page site every time you render a page the server would check for notifications and then in your template render an alert or some UI feature that tells the user they have notifications.
That set-up won't be active, IE if a new notification is posted on the server the client page won't know about it. Unless you use a notification message api for example pubnub.
Something like pubnub would let you send the message to your page, and in your JS code get a callback, so you can render it in your dom.
Since you have a multi-page app you would need to fetch / request for the notifications on every page render. Running a timeout to trigger for an ahead of time moment is not an ideal solution.
Another way to do it is to poll your server from your js code say every 5 mins and ask for notifications.
That has a price tag on all those repeated calls to your server. The best bet is to use something like pubnub but that comes at an extra laden of code server side to make it work.
I have a web application that needs to refresh some values often because the changes have to be available almost in real time. To do this, I run via ajax a refresh.php routine every 15 seconds, which returns the updated information. Time that increases if there is no user activity.
I thought about the possibility of creating a service-worker in the browser (since I already use it for pwa too), and in it create a web-socket, and then only when there is an update on the server, create a socket for the ip's of the users that are logged in (and saved in a db), just to send to the user's browser that there is an update, then the web-socket triggers the javascript routine that connects to the server and does the update.
I do not know if it would be possible to create the socket just to inform that there is an update, because in this case, I do not want to leave the socket open, creating the connection only when there is an update of the information, which should happen to several users.
Has anyone ever needed or done anything like this, or would you have any other ideas?
I have a requirement where a user presses a start timer button and it begins keeping track of time. As the user moves through the website, I want the time to continue tracking, until they press the stop button.
Obviously, this cannot be achieved through client-side javascript alone, since for each page refresh time will be lost. One solution I thought was to use faye/websockets to just push the time to the browser, but for every second that lapses, that will push data to client - a strain on the server.
The only solution I can come up with is keep track of the time in javascript and then capture the page unload event send, ajax request to server with the amount of time, and let the server continue incrementing time until the next page is fully loaded. This means it will not be using push technology, just regular ajax. Is this the optimal option here or is there a better solution?
What about the case where the user kills the browser? You won't be able to capture the unload event in this case.
If you want a client side solution, try putting the start time in the localStorage where this will persist across page loads. Then when the user hits stop, you can make an ajax call to the server with the elapsed time.
I assume you need to display a timer to the user, which updates every second.
I have built a web application like that. It was a single-page application (AngularJS), so the user could navigate from 'page' to 'page' without a complete web page being loaded and the timer kept running. Would that be an option in your case?
Otherwise, you could put the start time in a cookie and every second display the difference between the current time and the start time.
A few other options, which are less preferred:
Run the web site in an iframe and keep the timer outside the iframe.
Let the timer run on the server and make a small AJAX request to the server every second (yes, I know...).
Hybrid: Let the timer run on the server and on the client and synchronize the client with the server on every page load.
Options 2 and 3 require a stateful server (with all its drawbacks).
I am currently working on an auction script using node.js and socket.io.
The site will have 500-1000 logged in users viewing a single page during the auction. Only one item will be on sale at any one time, similar to a real auction held in an auction house.
I will be broadcasting a countdown timer to all of the signed in users from the server to the client. On the server side I will be using setInterval() of 1 second to countdown to the auction end time. Apart from this the only other message being sent across will be the current bid being passed from a single client to the server then broadcast to all.
Will this be a reliable way to do this? And will it be able to handle the usage on the server?
If not is there a way which would be better?
Thanks Shane
For timer value, keep updating your local timer per second on server side itself. Whenever any user comes in, give him this value and also total value of timer. Then client will start their own timers locally as per comment by dandavis, but keep some interval like 15 or 10 seconds on server side on which server will broadcast the current timer value so that client will sync accordingly.
In short, server will broadcast every after 10(n:you decide) seconds but it will be updating timer variable per second locally. Whenever client comes in, it will get total timer value and current timer value.
Rest functionality of broadcasting the current bid can be done in normal way.
Lets say someone logged in and leave the application as an idle and again using it. In the mean time the session was time-out. So, in this position session should be give null, but still it is displaying the assigned value in the JavaScript where as code behind showing null value.
Now what should I do?
You are describing a scenario where the user does not reload the page after the session expires, and hence the cookie value (assuming your session is cookie-based) is not removed/updated to reflect the new state of the session.
If you would like to update this in real time via your client-side code, you will have to check with the server by making a request on a set interval. The server-side handler should simply respond with the state of the session, and the client-side code should update whatever variables/cookies necessary to maintain state in your app.
This will introduce extra requests for users that are NOT idle, so then you would need some way to detect if a client is actually idle before triggering the request loop. Overall, you will need to evaluate if this "feature" is worth the extra requests and complexity that will be introduced.