I created app for universal windows platform(for Windows 10 desktop). I use DispatcherTimer in app. Timer run async method. When app in foreground it is work.
But app is background(I minimize a window) async method not work. How can I solve this problem?
When your app is not running in the foreground and tasks need to be executed, it is well known that we need to implement the background tasks for the app.
But, background tasks in UWP are lightweight. Due to memory constraints, battery life issue, I'm not sure what you need can be done in background task of UWP.
That doesn't mean you can't use DispatcherTimer in the background task, but background tasks are limited to 30 seconds of wall-clock usage, and it can be terminated by system for example when it throw the out-of-memory exception. So, if you want to execute your task every one minute, then it will not work.
The TimerTrigger which is mentioned by #ibebbs has a minimal time intervals which is 15 minutes, so I'm also not sure this can be used in your scenario.
Problem is what you need to do in the background task and how often, you can leave a comment to tell that, so can we continue to discuss on this issue.
You should Create and register a background task that runs in a separate process and use a TimerTrigger to invoke it at the desired interval.
Related
I make a library with several background tasks for UWP 8.1/10 (desktop/mobile).
I have 3 background tasks but I talk about one of them. When the app starts, I see permission request dialog:
await BackgroundExecutionManager.RequestAccessAsync();
I click to allow and continue registration of background task, this part works excellent. Every 15 minutes I see my task in Output. It works perfectly.
So, in near future, I want to change execution time while background task is working it creates the same task with another TimerTrigger(depends on some conditions, but it can happen), for example:
register again with the same time in TimerTrigger
register new TimeTrigger with one per two days timer.
I know about:
Note Universal Windows apps must call RequestAccessAsync before registering any of the background trigger types.
So, I need use await BackgroundExecutionManager.RequestAccessAsync() every time when I try to register any of background task, does I understand it right?
In other words, I do it every time when I change/re-register TimerTrigger for the first time, then when I need to do it when:
register again with the same time in TimerTrigger
or
register new TimeTrigger with one per two days timer.
Can someone help me to understand? :)
P.S I saw somewhere that re-registration in UWP 10 is not necessary, is it?
So, I need use await BackgroundExecutionManager.RequestAccessAsync() every time when I try to register any of background task, does I understand it right?
Yes. Check the remarks of BackgroundExecutionManager.RequestAccessAsync method, this must be called before registering any background tasks.
I saw somewhere that re-registration in UWP 10 is not necessary, is it?
If you mean this method is not necessary, actually re-registration you mentioned here should be a process that first un-register and register again. It should have nothing special with register. Only starting with Windows 10, it is no longer necessary to call this method from the UI thread.
I'm new to the UWP, and I'm facing right now an issue where I want to continue an operation that the app was doing before getting into suspended or terminated state.
I've read about Extended execution and background task, but as far as I have understood for extended execution you have only 30 seconds before it gets terminated or it could be revoked before getting into it.
for Background task I should make another project for it ( Windows Runtime Component) and I have to add an entry in the Declarations in the appxmanifest. It sounds that Background task is the only possible way to achieve it, but how to move an operation (Action, Func, or task or whatever) to background task if the app get into those states and what should happen after resume?!
Any ideas from experienced people?
Windows 10 universal Windows platform (UWP) app lifecycle
Before Windows 8, apps had a simple lifecycle. Win32 and .NET apps are either running or not running. Now, there are three app model in UWP app Running in foreground,Running in background and suspended state. You could know more detail through this official document.
Extended execution
There are cases where an app may need to keep running, rather than be suspended, while it is minimized. If an app needs to keep running, either the OS can keep it running, or it can request to keep running.
For this scenario, you need use ExtendedExecution to realize. ExtendedExecution support to start a long running operation in order to defer the Suspending state. And there are some document and code sample introducing this feature.
Background Task
For Background Task, it provide functionality when your app is suspended or not running. You can also use background tasks for real-time communication apps like VOIP, mail, and IM. However, it will trigger under specific conditions. For more please refer this.
You have mentioned out-process Background Task in your case and another Background Task(in process) could also be used in UWP app. It is simpler to implement than out-of-process background tasks.
I got a background task that downloads a few JSON data files that works perfectly when I call it using Visual Studio. When the background task is called using the UserPresent trigger at startup it gets cancelled (ExecutionTimeExceeded.)
Is there anything I can do to run the background task without any limit?
Probably not, the time limit is dependent on trigger type, and as MSDN says it can vary from 30 seconds to 10 minutes:
CPU quotas: Background tasks are limited by the amount of wall-clock usage time they get based on trigger type. Most triggers are limited to 30 seconds of wall-clock usage, while some have the ability to run up to 10 minutes in order to complete intensive tasks. Background tasks should be lightweight to save battery life and provide a better user experience for foreground apps. See Support your app with background tasks for the resource constraints applied to background tasks.
The backgroundtask should be a lightweight code - maybe you can redirect file download procedure to background transfer service and do some of heavy job in main app. You may also try with MaintenanceTrigger, there is a chance that constraints are lower for this one, but it fires once phone is connected to AC.
I've posted previously about synchronisation issues with my background scheduled task having to access a SQLite DB and IsolatedStorge that the foreground app uses.
To simplify the process I thought about just preventing my background task from running altogther, it isn't imperative that it runs, especially when the foreground app is active.
Is there a way to do this?
I thought about using IsolatedStorage to set a flag when the app launches then remove it when it exits, then have the background task check the setting, protected by mutex.
I think the idea is fine in principle, but I guess there will be times when the flag isn't unset, for example if the battery dies... Which means potentially, after turning the phone on, if the user never uses the app and exits properly, the background task will never run. This might not be too much of an issue.
Is using some kind of flag like this the only way to achieve such functionality?
Thanks
There is an inter process communication mechanism to achieve this functionality.
As both the foreground app and scheduletask run as different processes, IPC could be used for it.
Please refer to Named Events.
In your OnInvoke Method subscribe for a named event which will be fired by your foreground app as soon as it is launched/resumed.
As soon as you get a signal via this event in background agent, just call NotifyComplete and you are done.
I have a requirement where I have to call a service in background after every let say 1 hour to get some informations from server. I am working on JavaScript Metro Application. I have tried the background task and used Time Trigger and I have scheduled it to get triggered in every 15 minutes. It get called first time and then it is never called. I didn't close the background task because I want it to run all the time and call the service at scheduled time.
I have used the Microsoft Background task sample for reference.
Please tell me what should be the best approach to call a service in background.
How to use Time Trigger and Why Time Trigger doesn't get called after first time?
Please share code sample or walkthrough if any.
Thanks
First thing you should do is to close the background task properly as instructed in the documentation - if your tasks don't behave nicely, platform might suspend and refuse to run them for some time. You should let the platform handle triggering of the events based on the triggers and conditions you define instead of trying to bend the system. Also, remember that there's CPU and data usage quotas for background tasks present, one can't do massive amount of processing in background tasks - if the quotas are exceeded, tasks will get suspended. Be also sure that the background task works and doesn't throw errors.
In general, my recommendation is that one shouldn't rely solely on background tasks to fetch the information since it's not guaranteed that they manage to do it on time, so better to prepare for downloading the needed data in the foreground app as well. This obviously depends on the use case: if the data fetched in background tasks is not critical but more like nice-to-have, there's much less to worry about.
The TimeTrigger requires the app being added to the lock screen (see docs), but I guess you already meet this requirement since you've managed to get the task running once.
For debugging the background tasks, please take a look at Event Viewer, see detailed instructions. That page also contains some tips about common problems. The Event Viewer entry mentioned in that document is often a valuable resource for figuring out problems with the bg task execution. My guess is that you'll see errors there related to not closing the task properly.