I am creating an application that allows users to set multiple alarms.
The two ways I can think of doing is:
Store alarms as rows in a table and have a cron job check them every
minute. However, this means that the alarms will only be checked
every minute while some users may want it to be checked at a finer
resolution.
Create a new timer object for each new alarm that will call itself
with a setTimeout function. But if the app crashes then the alarms
are lost.
You can give a try to node-scheduer.
Very much similar to the cronjob. But the application must be kept on running.
It executes an event on a given interval. Make sure the job is executed after the desired interval every time and Put the alarm functionality there.
Related
In short we have a massive database and need to provide results as the user types them in the search box. It is impossible for us to preload queries and attempt to match that way.
Currently we send a request to the server with the new query string every 2 chars or 5 seconds. This is a bit of a mess however, so I'm looking to see if there is a faster/better way of doing this.
Previous solutions I've seen would require pre-feteching which in our case is not possible and considering the size of the return too costly.
I would recommend using debounce for this. It will make the function wait a certain amount of time after being called before running. Additional calls to the function will reset the timer. That way, the function will not run until users have finished (or paused) typing.
This which will prevent unnecessary load on your database, while still providing a good user experience (as long as you have a reasonable debounce time). Examples of how to do debounce in React can be found here
I am building a progressive web app using React, the concept of which revolves around keeping a timer running.
For context, the app is for home-brewers to keep track of when hops and other additions need to be added to their boil during their brew. Additions are added with a certain amount of time remaining in the boil, i.e. 1 oz Citra hops at 20 minutes remaining.
I'm using JavaScript's setInterval to "tick" the timer, which is an elapsedSeconds state property that drives the rest of the application.
The problem I'm running into is when the timer stops ticking. If I let the app run, the screen will eventually lock, or I'll switch apps, etc. The service worker will continue running, and the timer will continue to tick, for a short time (about 10 minutes from what I can tell in testing?)
My thought is that I will store an epoch time in state, that represents the time when the timer started. That way, when a user "returns" to the PWA, I can compare the current epoch time against the stored startingEpochTime to get the elapsedSeconds back. But I don't want to do this comparison at every "tick" if I don't have to. Ideally, this comparison would only run when the user is returning to the application from some other context, after the service worker has already stopped processing.
What I'm looking for is the correct way to do this. Would window.onload work in this instance? If I switch apps to another app for 20 minutes then switch back to my timer app, is that method run again? Looking for the best practice for this sort of scenario, or any idea that might help me out.
As of 2022 there is no way of scheduling tasks or keeping a timer running when a PWA is moved into the background.
To everyone who wants this functionality, please star and comment on the Google issue requesting it to motivate them to act: https://bugs.chromium.org/p/chromium/issues/detail?id=889077
Here's a couple of pointers that can help:
The general solution to what you describe is the Wake Lock API, which is the process of being design and specified, but is not available anywhere by default (yet).
In terms of what's currently implemented, there are pretty reliable ways of at least detecting when your web app goes into the background and goes back into the foreground using the Page Lifecycle API events. Once you're reliably detecting when you've come back to the foreground, a technique like what's mentioned in the comments about comparing the start time to the current time sounds about right.
I have run into a bit of an issue in my apex controller. I am looping through events between a start and end date (max amount of days to pull events from is a month), but this leads to potentially thousands of events. So I do a soql loop of events so it chunks them into 200 events, then I loop through each event in the 200 chunk to create custom event objects to return to my visual force page.
However, inside this second for loop, I need MORE for loops to do work in finding people invited and what not, so my runtime for this is unfortunately O(3n^3) however, the first two for loops generally act as one (get one chunk of 200, loop through them all, get next one, etc) so it is more O(3n^2), but when in a test org with 2777 events in one month, I ran into CPU governor limit.
I am wanting to throw this into a batch job, as I think that is the only way to handle these large amounts of events (I cannot reduce my for loops anymore).
I am wanting to have the lightning loading spinner run until batch job finishes. However... I am not sure how to communicate between the batch job finish() method and my javascript in my visualforce page. I will be calling a method in my controller with a remote action call and unhiding the spinner, then that method will initiate the batch job, then when batch job ends, spinner stops and page refreshes with data.
But yeah, I don't quite know how I can connect the finish() to my javascript to detect when the batch job has finished.
So you have a VF page that you want to react to a batch job that could take an nth number of time.. If you want that page to to be updated I would recommend looking into Streaming API, which I'm not even sure would solve your situation... Batch jobs are asynchronous obviously, so I don't think your requirements are realistic. I guess the bigger question is what are you trying to solve for, and if your requirements is to build a dynamic page off a async job that isn't realistic
You can check a salesforce batch status by providing job ID.
Below is a REST example:
curl https://instance.salesforce.com/services/async/39.0/job/jobId/batch/batchId -H "X-SFDC-Session: sessionId"
My situation is the following: People connect to my server and my server does store some information about the users which connected. For each connected user I have to handle 3 events on different times. So I thought about how to handle this is a good way. I had 2 different approaches in mind.
Creating a timer for each users event and that's it. Then my callback will be fired when it's time
Storing the timestamps on which the events should get fired and going through these timestamps every second and check if something need to get called
Which way would be the better to do this? Is there a general approach how to deal with scenarios like this?
Is there any reason to think that node won't handle the timers well? Definitely your first approach should be #1 -- use a timer for each event.
If for some reason that won't work then use a heap of timers. The root of the heap is always the closest timer to expire, and when that expires you go thru the heap, handling all the timers that expired (there may be more than 1), and then set a single timer to the next expiry time.
I am creating a web app that allows users to manage a calendar (CRUD events, tasks, reminders etc...)
And I am trying to implement a feature where they will receive a popup reminder x-minutes before the event/task. From my understanding there is really only one way to do this with javascript:
On login, check for any upcoming events in the database (say in the next 12 hours) and create a setTimeout for the next event, when that setTimeout executes, check again for next event and so on...
My question is, will having multiple setTimeouts (10+) running in the background during user interaction slow down the performance of my app?
Is there a better way to handle popup notifications on the client side? Push Notifications? Any suggestions would be greatly appreciated!
My question is, will having multiple setTimeouts (10+) running in the background during user interaction slow down the performance of my app?
In those numbers, no. (Depending on how + the + in 10+ is. I mean, I expect a million probably would be an issue.)
The other approach would be to have a single timer that you use (say, per minute) to check for notifications that should occur as of that minute. E.g.:
function notifyForThisMinute() {
// Notify user of things we should notify them of as of this minute
// ...
// Schedule next check for beginning of next minute; always wait
// until we're a second into the minute to make the checks easier
setTimeout(notifyForThisMinute, (61 - new Date().getSeconds()) * 1000);
}
notifyForThisMinute(); // First call starts process
This depends on the browser (or more specifically, it's javascript engine) and apparently even OS.
Neil Thomas (while working on GMAIL mobile) and John Resig have analyzed timers.
One of the more noticeable things to look out for is how often the timer runs per given time-interval (say every 200ms or once every 10 minutes..).
Thomas:
With low-frequency timers - timers with a delay of one second or more - we could create many timers without significantly degrading performance on either [an Android G1 or iPhone 3G]. Even with 100 timers scheduled, our app was not noticeably less responsive. With high-frequency timers, however, the story was exactly the opposite. A few timers firing every 100-200 ms was sufficient to make our UI feel sluggish.
Thomas:
Keep in mind that this code is going to execute many times every second. Looping over an array of registered callbacks might be slightly "cleaner" code, but it's critical that this function execute as quickly as possible. Hardcoding the function calls also makes it really easy to keep track of all the work that is being done within the timer.
Resig:
Once you start moving into the range of 64-128 simultaneous timers, you’re pretty much out of luck in most browsers.
One might also have a look at Chronos