My app creates a window with a local page that requires node integration to be enabled.
After I click a button on this page, I am navigated to a third party page.
Because I want node to be disabled in this third party page, and I can't toggle node integration in a BrowserWindow, I load this third party page in a sandboxed BrowserView that is embedded inside of the window and is stretched to fit the entire screen.
Now doing this navigates the embedded view, but the BrowserWindow is stuck pointing to the old local page that is no longer relevant.
To prevent this extra page from sitting around in the background, I navigate my BrowserWindow to "about:blank" to effectively clear it out and make room for the BrowserView.
I am realizing now that while this "clears" out the old page, it keeps the renderer process that's associated with it alive. From here:
Chromium creates a renderer process for each instance of a site the user visits
And understandably, navigating to "about:blank" doesn't signal to Electron that it should kill the other process.
I want to get rid of this renderer process, so it doesn't sit around unnecessarily and use CPU and memory when I interact with the window.
Two things that have worked:
I removed the extra navigation to "about:blank" since we're now killing the process and:
1) When my button in my renderer sends a message to the main process telling it to create a BrowserView and navigate to the new site, I do a process.exit();. I guess a part of me is nervous about the process exit interfering with the message that gets queued up for main, though it seems to work fine.
2) Instead of killing the process from the renderer, I created and navigated my BrowserView and then ran a little browserWindow.webContents.executeJavascript("process.exit()");. I find this uglier, though it does mitigate by concern above in #1.
There isn't a webcontents.destroy() type of method, and I don't know of a way to signal to Electron that it needs to destroy this unnecessary process.
I suppose I might have a pretty unique case, but is there a nicer way (or more standard way) of handling this than explicitly doing a process.exit()?
There is now a WebContents::forcefullyCrashRenderer() API that accomplishes this (introduced by this PR):
Forcefully terminates the renderer process that is currently hosting this webContents. This will cause the render-process-gone event to be emitted with the reason=killed || reason=crashed. Please note that some webContents share renderer processes and therefore calling this method may also crash the host process for other webContents as well.
As of now (July 2021, Electron v13) - there's also an undocumented webContents.destroy().
https://github.com/electron/electron/issues/10096
As the documentation mentions, some webContents share renderer processes and if you use webContents.forcefullyCrashRenderer() you may terminate them as well.
I'm not sure about how webContents.destroy() handles it, but from the name it seems to be more narrow in scope. I would assume that it kills the renderer if webContents is the only webContents attached to it (I tested this) and spares the renderer if other webContents is using it (needs confirmation).
Related
I'm new to UWP (windows 10), working on an app for windows phone, I wanted to know what is the difference between:
Using multiple frames and navigate from one to other.
Using a single xaml with no frames but with multiple grids (or other patterns), and instead of navigate- just change visibility so only the desired grid will be visible.
which option is better? and why?
The system keeps track of the Page you are currently on. So even when your App exists and even if it's removed from memory the OS can tell the App to reopen on that page.
Similarily when your App provides other Apps with the capability of calling into it to open certain file types of to perform certain actions (e.g. start navigation, etc.) pages will be used.
Lastly if you put everything on a single page and just manipulate visibility this will increase memory consumption of your App (as everything needs to be loaded even if it's not visible) and it also might increase load times.
Of course how much that impacts you is up to the type of App you are building. In general however I'd advice you to start building using separate pages in case your App grows. Also you get a lot of stuff out of the box if you do so (e.g. animated transitions, etc.)
I have successfully implemented a "faceless service" (background-only app with .service extension) and get it to work (see this question), based on Apple's documentation and other tutorials on the web.
Now, I want to advertise a service from an existing, single-window GUI app that I have.
I have setup the Info.plist file of my app to advertise the service, and it gets installed when I build the app.
But when I invoke the service from the context menu in (say) TextEdit.app (my service colours the selected text based on a certain criterion), my app gets launched, main window and everything. To make things worse, I am right-clicking on a TextEdit window that is in a secondary monitor, so my app's main window appears for an instant in the secondary monitor, then quickly repositions into the main monitor (this might have something to do with my window-centering logic, but nevermind...).
I would like to provide the service (i.e., have the class that provides the service in my app
instantiated and execute its method in response to the request), without my app appearing on the Dock or showing its window and main menu.
Is this possible? Safari advertises "Search With Google", so it should be possible...
EDIT: Now that I think about it, "Search With Google" must launch Safari every time in order to work, so this remark does not apply.
Perhaps I can put some logic in -applicationWillFinishLaunching/-applicationDidFinishLaunching to determine if the app is being launched in response to a service, and skip creating the window(notice the lack of withOptions: in OSX)?
But still, that doesn't feel right.
It does have a lame version of withOptions: -- NSApplicationLaunchIsDefaultLaunchKey tells you if your application was launched to either:
open or print a file, to perform a Service action, if the app had saved state that will be restored, or if the app launch was in some other sense not a default launch
So in your applicationDidFinishLaunching you can see if that key is in the notification and set to NO. Unfortunately, the main way to tell that it is one of the possibilities other than the Service, you have to detect and record whether or not you also got an application:openFile:, etc.
I'm building a Windows Phone application that does video capture in a page and has a custom player in another page. I'm using my own custom codec so the player needs a lot of DispatcherTimer to keep track of several behaviors on the UI part and serve the movie at the good framerate in the codec part.
I'm trying to release all DispatcherTimer as I know they are CPU intensive, but even when stopping them my app is still very slow. If I press back-back then follow the flow, the speed divides by two each time. If I don't use my player, eveything is ok. And my player is only made of 3 DispatcherTimer, a FileStream and an Image box.
I feel that DispatcherTimer are still running in memory and are double-instantiated even if they are instantiated as private on the page directly.
Can I force the page to release all this stuff?
Actually I don't understand yet what is the difference between navigating to a page next to current page, or navigating back. I don't know i.e. how the page is shown again without calling InitializeComponents, so I'm mixed up about which resources to release, and which resources to keep intact.
My execution speed problem was really caused by some running DispatcherTimer, so I'll answer it to have it archived.
The solution:
Ensuring that all DispatcherTimer has been instantiated directly on the page so that we can nullify them from anywhere in the code.
In OnNavigatedFrom, I kill the DispatcherTimer and in OnNavigatedTo, I recreate them with myDispatcherX = new DispatcherTimer();
No "temporary" timers, like "DispatcherTimer myTempTimer = new DispatcherTimer; with ((DispatcherTimer)send).Stop() in callback, as chances are that it remains in memory in an application where we navigate.
I have an (old) audio app that is misbehaving on iOS 5.1.1. It records audio and on older iOS versions (don't know precisely where the "break" is) it would stay "in foreground" while recording, without any nudging.
But on 5.1.1 the app is put into background after two minutes, and then things go sour. Currently (will have to change this, I suppose) the app kills recording when it's backgrounded (and it appears to do this successfully), but it still dies with a trap in the above routine.
Unfortunately, the call stack is empty when this occurs, so there's little clue as to why the app's getting killed, but I gather (just from hints here and there on the web) that the trap occurs because a background app cannot use any UI facilities, and the app must somehow be calling something UI-ish. But I haven't a clue what it might be.
I've worked through most of the notifications, to see if a notification might be lurking in a queue somewhere and doing something, but I've not found anything so far that might be triggering a UI opp.
Any ideas on how to track this down?
Aha!! The app uses an Apple freebee widget known as AQLevelMeter. When recording is stopped, the level meter is also stopped, but the stop code inside AQLevelMeter.mm does not invalidate the timer that's driving the UI updates.
When a user first opens my app, I need to download and install some content from a server before they can begin using the app. The problem is that this takes around 5 minutes on wifi, during which time the app goes into the background and the download is suspended.
Is there any way to either:
prevent an iOS app from entering the background whilst I perform my download
or continue peforming the task in the background (i.e. perform the task irrespective of whether the app is in the foreground or background)
Thanks
It really doesn't matter, if the user presses the home button it will go to background. Although you can do two things to mitigate the problem:
Use beginBackgroundTaskWithExpirationHandler, to give you a bit more time to download. Which you can read here.
Don't allow the device to become iddle, with [UIApplication sharedApplication].idleTimerDisabled = YES;. You can read more about that here.
Either way, the best thing you can do is to tell the user, that is an important download and he shouldn't quit the application.
Can't you include some or all of the content in your app bundle instead, and just download changes on first run?
I can't imagine this is a good first user experience, and it may not pass App Store review like this.
The only third party apps that are allowed to download in the background are newsstand apps loading issue content, and Apple are pretty strict about what they allow as newsstand apps.
You can't do what you want, in this situation. One way, and I think the best and only, is to resume your download when you app becomes active (returns to foreground state). Also, don't forget to register for connectivity notifications (Reachability class can be used for this purpose from this Apple sample app http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html). Good Luck!