I am using:
ELECTRON 19.0.4
NODE 16.14.1
NPM 8.6.0
Vue Framework
We have an APP which is getting data from a server with API rest, every 10 seconds and sending that data to another server. This means, theoretically the app is working 24/7.
PROBLEM: The app (the renderer process) is entering (and i am just guessing) an IDLE mode, even tho the process have an interval of requesting data every 10 seconds, or just a low power mode after a while (3/4 hours aprox) which for us means that the API request is not getting any data..
WE HAVE also tried:
const preventDisplaySleep = powerSaveBlocker.start('prevent-display-sleep');
AND
const preventAppSuspension = powerSaveBlocker.start('prevent-app-suspension');
AND
let idleState = powerMonitor.getSystemIdleState(30);
but without any desirable effect on our app.
WHAT is now WORKING is that every 2/3 hours we make a reload for "mainWindow" every 2 hour(in miliseconds).
setInterval(function () { mainWindow.reload()}, 7200000)
BUT THE ISSUE with this alternative is that when reloading we are getting a part of last interval of time, twice because we are starting a new interval of search at every restart of the app and so last interval before restart is covered 2 times.
QUESTION: is there any HOT Reload for electron without losing any data?? , or even better a WAY to make our app to **stay active ** ALL the TIME??
Thank you so much in advance. Can't wait to see what i am missing here, and how i can solve it..
Related
I wrote myself a server monitoring utility using Vaadin 18.0.2 for the UI. This works very nicely execpt for one major issue:
The monitoring is meant to become part of our "team-screen", i.e. a big screen displaying team news, build results, server status, etc.). As such the application has be able to run for longer periods without any user interaction.
The application once per minute queries a bunch of servers re. livelihood and response times and then updates a corresponding result screen. For some reason it always crashes after pretty reproducibly 80 minutes with a com.vaadin.flow.component.UIDetachedException:
com.vaadin.flow.component.UIDetachedException: null
at com.vaadin.flow.component.UI.handleAccessDetach(UI.java:412)
at com.vaadin.flow.component.UI.access(UI.java:512)
at com.vaadin.flow.component.UI.access(UI.java:499)
...
Once this happens all subsequent UI updates have the same issue, i.e. the display "freezes".
The above code is called by a listener which always first requests a Vaadin UI handle and then updates the screen. While it keeps getting such a UI there obviously something's wrong with it after these 80 minutes and then - while the application's monitoring core continues to run - all UI updates are impossible. Neither reloading the page in the browser or even terminating and restarting the browser helps. The application's web-interface is "dead" after that and only an application restart can revive it. This is of course a complete killer or "no-go" for this kind of application. :-(
I suspect that there is some session timeout or UI object duration limit being reached but I haven't encountered any setting to control that so far. I also found no docs mentioning that some token or handle or similar needs to be regularly refreshed or so.
What I specifically don't understand is, why a browser page reload or even a browser restart doesn't help here. One doesn't get a login-in screen as one might expect if some token or session cookie would have expired or so, but the application's web interface is completely "dead" after that time. One doesnt even get any response anymore from the server but the browser requests just time out...
Any hint or guidance what could be the cause for these exceptions or what mechanism is behind this behavior?
I switched over to the open source parse with mLab on AWS and the project in objective c runs slow. When I try to update delete add or query it takes about five seconds to process it. I was not having this problem with the parse.com. If any one could help me that would be great!
You are likely on a trial version of the server, which means that after 30 minutes of inactivity, your server will go to "sleep". When it is called to by a request, it must "wake up" which usually takes about 5 seconds. However, only the first query or log in after sleeping should actually be slow. The ones following should be very responsive.
Consider the following example:
setInterval(function()
{
console.log(new Date());
});
If I run it with electron example.js under OS X, it opens up an icon in my dockbar and starts printing out the time on the console. If the app is not focused, however, after a while it starts throttling.
I looked around and found that this is due to OS X power saving strategy. Now, what if I needed it to keep working in background? My app will be a daemon doing a little bit of something every now and then, and I can't have my users blankly staring at my app for ages.
I found out here that I can do
electron.powerSaveBlocker.start('prevent-app-suspension');
Which actually fixes my problem. This however, is quite invasive, since as far as my understanding goes it prevents the system from sleeping at all! I don't need this much, I would just need my app to do something when the computer is active and online without forcing it to stay awake forever.
Isn't there anything in the middle, between having my users keeping the app continuously in the foreground, and making their computer sleepless forever?
As per the current docs:
Note: prevent-display-sleep has higher precedence over
prevent-app-suspension. Only the highest precedence type takes effect.
In other words, prevent-display-sleep always takes precedence over
prevent-app-suspension.
For example, an API calling A requests for prevent-app-suspension, and
another calling B requests for prevent-display-sleep.
prevent-display-sleep will be used until B stops its request. After
that, prevent-app-suspension is used.
What this means is that setting prevent-app-suspension to on, will still allow the system to sleep, and simply does what you desire it to. You can however run the function twice, passing both flags, turning both options on. However, as the docs above say, if both are set to on, then the system will not sleep until that flag has been removed.
I have a requirement where I need to know what is the server time at a given point of time in the app. As soon as the app connects to server, the server sends back the time and I am not sure how to update this time.
I thought of using the timers where the method is called every second and and a second is added to server time, so that whenever I ask for server time it is always updated one. But problem with this if we schedule this on main runloop, the run loop may or may not process the timer request if there it is busy.
So how to track the server time?
Thanks
Your server is in a specific time zone correct? Just get the time zone of the server using a request and show the time in that time zone in your app. You can then use a timer to continue updating the time every second.
I suggest getting just the time zone because if you get the server's time, there would be a lag between when the server sends back the response and when you get it - which defeats the whole purpose of getting the time as on the server.
You can't update the iOS system time from your app; there is no API
for that.
iPhone's time is usually very accurate. On iPads, it varies but has improved with iOS 5 to +/- 5 seconds if some form of internet connectivity is available.
If you want to manually connect to a server to synchronize time, you
should do it in a background task.
To compensate for latency, you should make multiple requests and add
the average half of the roundtrip time to the time sent by the server.
However, the question remains: Why do you want to do that anyway?
My App is typically run overnight as a baby monitor, either as foreground app, or with background audio running.
Goals:
Track total app startups ie. active user count.
Track total usage time in foreground vs background and total session time.
Track various page-views if they navigate the settings screens.
As recommended, I start the tracker in didFinishLaunchingWithOptions, and track my first ViewController as my first 'page-view'. My App might stay on this page then for the next 8 hours...
A couple of issues then appear:
When do I call stopTracker and what does it do? I'm hoping that it terminates the tracking session. But since google kindly hid their code in a static lib, I have no idea what's going on under the covers, and the .h doesn't say much. First instinct is to put stopTracker in applicationWillResignActive however, if the user decides to enable background audio my app is still running...
Next I read that a session can timeout after 30mins with no new pageviews, or at midnight. I could set a repeating timer to send the same page-view every 20mins, that should keep my session alive, at least until midnight, but then my page views are going to be much larger? unless it's smart enough to know I'm on the same page with every call. google analytics blog
[Update: each call seems to be counted as a new pageview, and numbers are thus skewed, so still an issue how to handle this]
If my timer above runs past midnight and the session has expired, I'm going to end up with a new session and double the actual active user count?
If I do call stopTracker in applicationWillResignActive, will the next call to track a page-view restart the tracker? or do I need to call startTrackerWithAccountID again?
If instead I start the tracker in applicationDidBecomeActive, I lose the session that might have been running in the background.
[update: this seems to be the best approach so far, but testing is very slow due to time lag on analytics reports, I will report back soon]
PS EasyTracker doesn't seem to handle this any better.
I got this working by using a pageview called 'Backgrounded', and when the user has selected no background functionality, then instead the app is calling stopTracker. I see multiple hits, with an average session of 20mins, but i can multiple pageview by time to see total time for goal 2. I found two solutions for goal one, events (which were not exposed in easy tracker), and also in my applicationDidBecomeActive (if it's not a restore of backgrounded app) then i track a pageview for AppStarted. I ended up wrapping the whole thing in a utility class and rolled it into a couple of my apps, so will be interesting too see the results. If anyone else tries this, you might want to think about using the custom variables too. I added my app version to this, so I can also monitor how many users are migrating to the latest app releases.