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.
Related
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 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.
I have a windows phone 8.1 app that has several background tasks. They all are called by 15-minute time triggers. So how can I assure that they are executed one after the other?
For example first the background task is called that updates some date, and only after that the background task is called that updates a live tile?
I'm afraid that's currently not possible. Your background tasks will be executed in a certain time frame but there is no guarantee that there's an explicit order.
But if you know that you want to do things in a sequential order why not do everything from one background task? You can always update a live tile manually from a background task (https://msdn.microsoft.com/en-US/library/windows/apps/xaml/jj991805.aspx).
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.
I am looking into ways of updating a live tile frequently - for example every 5 minutes.
I have used Push notifcations before, but I want to avoid them this time.
ShellTileShedule only updates once an hour.
I am thinking about using a background agent that runs every five minutes and updates the tile with the information it has obtained from the server.
Apart from the 14day expiry, can you see any pitfalls with this?
How do people normally get round the 14day expiry?
Will querying a service and downloading a few lines of text every 5 mins really kill the battery?
EDIT: It seems background agents for a task such as this only update every 30mins, is there a way round this, or a better solution?
Thanks.
You are somewhat constrained as to when your background tasks run on the phone. The OS will also move the scheduled time of the tasks if it can execute multiple at the same time - to avoid having to wake up the phone twice. If you're wanting to update the tile every 5 minutes then push notifications are your only option. But you should probably be considering if the user will actually look at information that regularly.
I go for a halfway approach - I use a PeriodicTask to update my shell tiles as the OS allows but then when the application launches I manually refresh the tiles with the latest information. This allows the user to "force" the tile data and additionally provides more realistic data after the user has exited the application.
To get around the 14 day expiry re-register your background task on every launch of your application. That'll keep pushing the 14 days out. It's intended to prevent unused applications from using precious resources - if your user is launching your application they probably still want the background agent to run. And if not, they can disable it through Settings > Applications > Background Tasks (or by uninstalling, obviously). To register your task execute something like the following in initialisation code;
PeriodicTask task = ScheduledActionService.Find("MyTaskName") as PeriodicTask;
if ((task != null) && (task.IsEnabled == true)) {
ScheduledActionService.Remove("MyTaskName");
}
task = new PeriodicTask("MyTaskName") {
Description = "My Periodic Task",
};
ScheduledActionService.Add(task);
#if DEBUG
if (System.Diagnostics.Debugger.IsAttached == true) {
ScheduledActionService.LaunchForTest("MyTaskName", TimeSpan.FromSeconds(10));
}
#endif
The #if DEBUG allows you to schedule the task straight after execution for testing scenarios.
I know this is a very old question, but still it might save someone's time. According to this article, every time you call Update(shellTileData) your tile's expiration time is extended for 2 weeks more. So as far as I understand, this means your app can update its tile forever without having to re-register the task.