I am new to windows app development. I am currently working on an Universal App using c# and XAML, which has 4 pages, first page being a welcome page. I have to check on other 3 pages (other than welcome page) that if the page is idle for last 2 minutes then I have to reload the welcome page, forcing used to start from the beginning. I did research on this on google, but couldn't find anything helpful. Hope someone from stack overflow community can direct in right direction.
Thanks,
Kevin
Is the welcome page for a login? If you are requiring the user to login to view the extra pages you will also have to handle when the app is in the background. In app.xaml.cs, subscribe to the corewindowvisibilitychanged event. Save a time stamp and now you can check how long the app has been in the background and navigate to the welcome page in the I launched event.
To implement an idle timer you should look at the I launched event where the root frame is created. Subscribe to the pointer moved event in the maimwindow, or use a base page for the similar three pages in your app. When pointer moves, start a dispatcher timer that will be your ticking time bomb for when the navigation occurs. If the pointer moved event happens again, call dispatcher timer.stop, null it out and start a new one. You may also want to subscribe to keyboard events too.
Don't forget to subscribe to pointer moved from the c#, so you can use the overload to handle all events, even when an originating source has already handled it. :)
Related
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).
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.
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!
I'm writing a very lightweight app for OSX 10.6+ which will respond to a user clicking on a URL, pass that URL to another application via TCP and then exit.
So far it has registered fine to launch when a user clicks the custom url scheme. However the event seems to get lost if the app is not already running. So the users clicks the link, the app loads, but nothing happens. Once the app is running, if the user clicks the link then it grabs the event and processes it as normal.
What do I need to do to catch that initial event that causes the app to open in the first place?
Currently I'm creating the NSAppleEventManager in the applicationDidFinishLaunching method, and this works for all events created AFTER the initial load, just not for the one that actually opened the app itself.
Any advice would be brilliant!
Thanks!
You should be creating your AppleEvent handlers in -applicationWillFinishLaunching: instead.
The idea is to have your handlers ready to go before your application begins processing AppleEvents.
I want to register my app for push notification when my application terminates so i think if i delay my app quitting time it could be possible.Does someone knows how to delay application quitting time? I think this method
[self performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait];
will do my job but i don't know how to use this method if someone knows please tell.I need to send some data to a server along with registering for Push Notification when my app quits.
I can't imagine why you would want to do this. If it were even possible it would be extremely annoying for a user to tap the home button and the app to take x amount of time to shut down. This time 'x' being dependent on the server connection creates even more user headache.
Apple have the home button exit apps immediately for a reason.
If you want to register the Push Notifications like you suggest, do it while the app is running. If your worrying that they won't be properly set if the user exits prematurely... don't.
As users, we all know there are sometimes consequences of exiting a program without giving it time to save your settings.
For push notification it is better to register when the app first starts and then send the push token to your server in the background. However, if you have a good reason why you need to do the registration just as the app terminates, I believe you can do this if you are using iOS 4. iOS 4 has a new feature called "task finishing" that allows an app to stay running for a few minutes after the user closes it so that it may finish up any tasks it was in the middle of (such as saving data).