Should Desktop-Extension: Running in background or Shutting down?
I have an UWP app with a background Desktop extension which performs task, sometimes it will be unused for hours, sometimes it will be needed every few seconds. I need to know if when it is not running, should it be shut down with Application.Current.Shutdown()
or simply left running and wait for the next RequestReceived
? I dont want to waste ressources, but it seems like an inactive Desktop Extension takes up minimal resources, right?
The only issue with shutting it down is performance: The UWP app needs to wait for a response, so is there a performance difference between starting the component and sending the request vs just sending the request?
Either way, what is considered best practice here?
uwp desktop-bridge
add a comment |
I have an UWP app with a background Desktop extension which performs task, sometimes it will be unused for hours, sometimes it will be needed every few seconds. I need to know if when it is not running, should it be shut down with Application.Current.Shutdown()
or simply left running and wait for the next RequestReceived
? I dont want to waste ressources, but it seems like an inactive Desktop Extension takes up minimal resources, right?
The only issue with shutting it down is performance: The UWP app needs to wait for a response, so is there a performance difference between starting the component and sending the request vs just sending the request?
Either way, what is considered best practice here?
uwp desktop-bridge
add a comment |
I have an UWP app with a background Desktop extension which performs task, sometimes it will be unused for hours, sometimes it will be needed every few seconds. I need to know if when it is not running, should it be shut down with Application.Current.Shutdown()
or simply left running and wait for the next RequestReceived
? I dont want to waste ressources, but it seems like an inactive Desktop Extension takes up minimal resources, right?
The only issue with shutting it down is performance: The UWP app needs to wait for a response, so is there a performance difference between starting the component and sending the request vs just sending the request?
Either way, what is considered best practice here?
uwp desktop-bridge
I have an UWP app with a background Desktop extension which performs task, sometimes it will be unused for hours, sometimes it will be needed every few seconds. I need to know if when it is not running, should it be shut down with Application.Current.Shutdown()
or simply left running and wait for the next RequestReceived
? I dont want to waste ressources, but it seems like an inactive Desktop Extension takes up minimal resources, right?
The only issue with shutting it down is performance: The UWP app needs to wait for a response, so is there a performance difference between starting the component and sending the request vs just sending the request?
Either way, what is considered best practice here?
uwp desktop-bridge
uwp desktop-bridge
edited Nov 22 '18 at 21:28
Stefan Wick MSFT
8,91811837
8,91811837
asked Nov 22 '18 at 20:42
GiffordPGGiffordPG
134
134
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
If your desktop extension background process is only used to handle requests from your UWP foreground app, then the best practice would be to link its lifetime to the state of your foreground app. You can control it from UWP by sending a message to your extension to shut itself down when the UWP goes into a state where the extension is no longer needed (e.g. when it gets suspended).
In general it is good practice for the extension to shut itself down when the AppService connection gets closed. You can do this by listening to the ServiceClosed event on the AppServiceConnection instance in your extension. I have an example posted here ("Handle Process Exit - scenario #2) : https://stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3/
I should have mentioned that the UWP app is supposed to run in the background too most of the time. What is the best solution then?
– GiffordPG
Nov 22 '18 at 21:48
What exactly do you mean by "running in the background"? If you are suspended in the taskbar then you won't need the extension to be running and might as well shut it down. Another (maybe simpler) way to do is to listen to the ServiceClosed event on the AppServiceConnection in your extension and then shut yourself down. I have explained this some more here ("Handling Process Exit" - scenario #2): stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3
– Stefan Wick MSFT
Nov 22 '18 at 22:22
I mean something like ShareX or GestureSign are doing, they have a background process that is triggered by a Hotkey or another action. In my case, my UWP component is waiting for selected apps to be in Focus and will trigger in this case.
– GiffordPG
Nov 22 '18 at 22:26
What happens if the UWP is not running when the action triggers? Nothing - or do you launch it from your desktop extension?
– Stefan Wick MSFT
Nov 22 '18 at 22:32
I am using <rescap:Capability Name="extendedBackgroundTaskTime"/> so the UWP part is running in background all the time. When the action triggers, the desktop extension is required to do an action, but none show an user interface.
– GiffordPG
Nov 22 '18 at 22:45
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53437775%2fshould-desktop-extension-running-in-background-or-shutting-down%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If your desktop extension background process is only used to handle requests from your UWP foreground app, then the best practice would be to link its lifetime to the state of your foreground app. You can control it from UWP by sending a message to your extension to shut itself down when the UWP goes into a state where the extension is no longer needed (e.g. when it gets suspended).
In general it is good practice for the extension to shut itself down when the AppService connection gets closed. You can do this by listening to the ServiceClosed event on the AppServiceConnection instance in your extension. I have an example posted here ("Handle Process Exit - scenario #2) : https://stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3/
I should have mentioned that the UWP app is supposed to run in the background too most of the time. What is the best solution then?
– GiffordPG
Nov 22 '18 at 21:48
What exactly do you mean by "running in the background"? If you are suspended in the taskbar then you won't need the extension to be running and might as well shut it down. Another (maybe simpler) way to do is to listen to the ServiceClosed event on the AppServiceConnection in your extension and then shut yourself down. I have explained this some more here ("Handling Process Exit" - scenario #2): stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3
– Stefan Wick MSFT
Nov 22 '18 at 22:22
I mean something like ShareX or GestureSign are doing, they have a background process that is triggered by a Hotkey or another action. In my case, my UWP component is waiting for selected apps to be in Focus and will trigger in this case.
– GiffordPG
Nov 22 '18 at 22:26
What happens if the UWP is not running when the action triggers? Nothing - or do you launch it from your desktop extension?
– Stefan Wick MSFT
Nov 22 '18 at 22:32
I am using <rescap:Capability Name="extendedBackgroundTaskTime"/> so the UWP part is running in background all the time. When the action triggers, the desktop extension is required to do an action, but none show an user interface.
– GiffordPG
Nov 22 '18 at 22:45
|
show 1 more comment
If your desktop extension background process is only used to handle requests from your UWP foreground app, then the best practice would be to link its lifetime to the state of your foreground app. You can control it from UWP by sending a message to your extension to shut itself down when the UWP goes into a state where the extension is no longer needed (e.g. when it gets suspended).
In general it is good practice for the extension to shut itself down when the AppService connection gets closed. You can do this by listening to the ServiceClosed event on the AppServiceConnection instance in your extension. I have an example posted here ("Handle Process Exit - scenario #2) : https://stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3/
I should have mentioned that the UWP app is supposed to run in the background too most of the time. What is the best solution then?
– GiffordPG
Nov 22 '18 at 21:48
What exactly do you mean by "running in the background"? If you are suspended in the taskbar then you won't need the extension to be running and might as well shut it down. Another (maybe simpler) way to do is to listen to the ServiceClosed event on the AppServiceConnection in your extension and then shut yourself down. I have explained this some more here ("Handling Process Exit" - scenario #2): stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3
– Stefan Wick MSFT
Nov 22 '18 at 22:22
I mean something like ShareX or GestureSign are doing, they have a background process that is triggered by a Hotkey or another action. In my case, my UWP component is waiting for selected apps to be in Focus and will trigger in this case.
– GiffordPG
Nov 22 '18 at 22:26
What happens if the UWP is not running when the action triggers? Nothing - or do you launch it from your desktop extension?
– Stefan Wick MSFT
Nov 22 '18 at 22:32
I am using <rescap:Capability Name="extendedBackgroundTaskTime"/> so the UWP part is running in background all the time. When the action triggers, the desktop extension is required to do an action, but none show an user interface.
– GiffordPG
Nov 22 '18 at 22:45
|
show 1 more comment
If your desktop extension background process is only used to handle requests from your UWP foreground app, then the best practice would be to link its lifetime to the state of your foreground app. You can control it from UWP by sending a message to your extension to shut itself down when the UWP goes into a state where the extension is no longer needed (e.g. when it gets suspended).
In general it is good practice for the extension to shut itself down when the AppService connection gets closed. You can do this by listening to the ServiceClosed event on the AppServiceConnection instance in your extension. I have an example posted here ("Handle Process Exit - scenario #2) : https://stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3/
If your desktop extension background process is only used to handle requests from your UWP foreground app, then the best practice would be to link its lifetime to the state of your foreground app. You can control it from UWP by sending a message to your extension to shut itself down when the UWP goes into a state where the extension is no longer needed (e.g. when it gets suspended).
In general it is good practice for the extension to shut itself down when the AppService connection gets closed. You can do this by listening to the ServiceClosed event on the AppServiceConnection instance in your extension. I have an example posted here ("Handle Process Exit - scenario #2) : https://stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3/
edited Nov 23 '18 at 18:19
answered Nov 22 '18 at 21:28
Stefan Wick MSFTStefan Wick MSFT
8,91811837
8,91811837
I should have mentioned that the UWP app is supposed to run in the background too most of the time. What is the best solution then?
– GiffordPG
Nov 22 '18 at 21:48
What exactly do you mean by "running in the background"? If you are suspended in the taskbar then you won't need the extension to be running and might as well shut it down. Another (maybe simpler) way to do is to listen to the ServiceClosed event on the AppServiceConnection in your extension and then shut yourself down. I have explained this some more here ("Handling Process Exit" - scenario #2): stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3
– Stefan Wick MSFT
Nov 22 '18 at 22:22
I mean something like ShareX or GestureSign are doing, they have a background process that is triggered by a Hotkey or another action. In my case, my UWP component is waiting for selected apps to be in Focus and will trigger in this case.
– GiffordPG
Nov 22 '18 at 22:26
What happens if the UWP is not running when the action triggers? Nothing - or do you launch it from your desktop extension?
– Stefan Wick MSFT
Nov 22 '18 at 22:32
I am using <rescap:Capability Name="extendedBackgroundTaskTime"/> so the UWP part is running in background all the time. When the action triggers, the desktop extension is required to do an action, but none show an user interface.
– GiffordPG
Nov 22 '18 at 22:45
|
show 1 more comment
I should have mentioned that the UWP app is supposed to run in the background too most of the time. What is the best solution then?
– GiffordPG
Nov 22 '18 at 21:48
What exactly do you mean by "running in the background"? If you are suspended in the taskbar then you won't need the extension to be running and might as well shut it down. Another (maybe simpler) way to do is to listen to the ServiceClosed event on the AppServiceConnection in your extension and then shut yourself down. I have explained this some more here ("Handling Process Exit" - scenario #2): stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3
– Stefan Wick MSFT
Nov 22 '18 at 22:22
I mean something like ShareX or GestureSign are doing, they have a background process that is triggered by a Hotkey or another action. In my case, my UWP component is waiting for selected apps to be in Focus and will trigger in this case.
– GiffordPG
Nov 22 '18 at 22:26
What happens if the UWP is not running when the action triggers? Nothing - or do you launch it from your desktop extension?
– Stefan Wick MSFT
Nov 22 '18 at 22:32
I am using <rescap:Capability Name="extendedBackgroundTaskTime"/> so the UWP part is running in background all the time. When the action triggers, the desktop extension is required to do an action, but none show an user interface.
– GiffordPG
Nov 22 '18 at 22:45
I should have mentioned that the UWP app is supposed to run in the background too most of the time. What is the best solution then?
– GiffordPG
Nov 22 '18 at 21:48
I should have mentioned that the UWP app is supposed to run in the background too most of the time. What is the best solution then?
– GiffordPG
Nov 22 '18 at 21:48
What exactly do you mean by "running in the background"? If you are suspended in the taskbar then you won't need the extension to be running and might as well shut it down. Another (maybe simpler) way to do is to listen to the ServiceClosed event on the AppServiceConnection in your extension and then shut yourself down. I have explained this some more here ("Handling Process Exit" - scenario #2): stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3
– Stefan Wick MSFT
Nov 22 '18 at 22:22
What exactly do you mean by "running in the background"? If you are suspended in the taskbar then you won't need the extension to be running and might as well shut it down. Another (maybe simpler) way to do is to listen to the ServiceClosed event on the AppServiceConnection in your extension and then shut yourself down. I have explained this some more here ("Handling Process Exit" - scenario #2): stefanwick.com/2018/04/16/uwp-with-desktop-extension-part-3
– Stefan Wick MSFT
Nov 22 '18 at 22:22
I mean something like ShareX or GestureSign are doing, they have a background process that is triggered by a Hotkey or another action. In my case, my UWP component is waiting for selected apps to be in Focus and will trigger in this case.
– GiffordPG
Nov 22 '18 at 22:26
I mean something like ShareX or GestureSign are doing, they have a background process that is triggered by a Hotkey or another action. In my case, my UWP component is waiting for selected apps to be in Focus and will trigger in this case.
– GiffordPG
Nov 22 '18 at 22:26
What happens if the UWP is not running when the action triggers? Nothing - or do you launch it from your desktop extension?
– Stefan Wick MSFT
Nov 22 '18 at 22:32
What happens if the UWP is not running when the action triggers? Nothing - or do you launch it from your desktop extension?
– Stefan Wick MSFT
Nov 22 '18 at 22:32
I am using <rescap:Capability Name="extendedBackgroundTaskTime"/> so the UWP part is running in background all the time. When the action triggers, the desktop extension is required to do an action, but none show an user interface.
– GiffordPG
Nov 22 '18 at 22:45
I am using <rescap:Capability Name="extendedBackgroundTaskTime"/> so the UWP part is running in background all the time. When the action triggers, the desktop extension is required to do an action, but none show an user interface.
– GiffordPG
Nov 22 '18 at 22:45
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53437775%2fshould-desktop-extension-running-in-background-or-shutting-down%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown