I went through the following documentation to create a background periodic task:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202941(v=vs.105).aspx
For some reason, I never see it running. (In the sense, the OnInvoke() method in the class SchedulerTaskAgent.cs never got invoked)
With debugger on, I was able to invoke the method using:
if(DEBUG_AGENT)
ScheduledActionService.LaunchForTest(periodicTaskName, TimeSpan.FromSeconds(60));
#endif
It ran fine every 60 seconds. I saw the debug statements I added to OnInvoke() getting printed every minute (60 seconds).
Then I commented out the above lines to test to see if OnInvoke() gets called by the OS at times (say like every 30 minutes or so).
It was never called. I connected the phone to my Windows computer and the phone was fully charged, but was not connected to Wifi, but to the cellular network.
I am not sure as to understand why it was not triggered. I attempted the whole day yesterday (at least 6 to 8 times waiting between 30 minutes and an hour).
How do I test periodic task in the real world scenario where I can't use: ScheduledActionService.LaunchForTest(...)
My phone was simply idling and the phone I use is exclusive for testing (I don't have any apps running in the background,the cellular network signal was really good, with battery up to 100%).
Also the periodic task is just going to print some messages and not going to do any network or resource-intense activity.
Thanks for your time.
Try adding a pound sign in front of the if.
eg.
#if(DEBUG_AGENT)
ScheduledActionService.LaunchForTest(periodicTaskName, TimeSpan.FromSeconds(60));
#endif
Related
Windows Phone platform offers BackgroundTasks infrastructure. I can register my task like that:
builder.TaskEntryPoint = TaskName;
var trigger = new TimeTrigger(15, false);
builder.SetTrigger(trigger);
builder.Register();
The problem is, that TimeTrigger min interval is ~15 minutes, which is pretty large for my application. I need to have task which runs every 1-2 minutes in the background. Is it possible on Windows Phone?
It is not possible to have BackgroundTasks that run on a minute interval basis.
As you said already the minimum interval is 15 minute.
This is an OS limitation to prevent developers to build battery draining applications.
You always have some workarounds, like having a PushNotificationTrigger, and manage to send a push notification to your device every minute. (I guess some people manage to do so with the ScheduledToastNotification), but i wouldn't recomend it.
AFAIK with the official API - it's not possible to run TimeTrigger so often. Note that on WIndows Phone, the interval is even larger (MSDN):
Windows has a built-in timer that runs background tasks in 15-minute intervals. Note that on Windows Phone, the interval is 30 minutes.
I doubt it will be possible, due to battery consuption/restrictions. Maybe you can leave your app in the foreground and disable lockscreen (by using DisplayRequest).
Also you may try to run a timer along with obtaining deferal in your BackgroundTask. I've not tried that, for sure there will be many problems (CPU limit, memory and other restrictions), I'm not sure if that is not against certification requirements and of course it doesn't guarantee that your BackgroundTask wouldn't be terminated by OS.
For my app I need to be able to let the user specify a given time and let my app run a background task at that specific time.
I understand that with wp8.1 a timetrigger background task can only run every 15 minutes. Is there anything I can do to ensure my app will run the task if the time has gone 10 minutes over the user's specified time?
For what I understand tasks are only executed in intervals multiple of 15 minutes in Windows 8.1 and 30 minutes in Windows Phone 8.1. Have a look here: http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh977059.aspx
I can not add a comment, that's why I share my experiences as an answer.
We had a similar problem in an application - we target the Windows Store 8.1 platform but our experiences can be relevant for you as the app cycles in the two platform are converged (http://msdn.microsoft.com/en-us/library/windows/apps/dn632424.aspx).
In our app we have to monitor streams and collect information. This logic has to be executed per minute what is not supported, as mentioned. That's why we use a simple Task with a CancellationTokenSource, and we start/stop the task in the app cycle-related events (Suspending, Resuming). This "solution" is not acceptable if the execution of the background logic is required when the app is suspended, too, but in our case this was not required.
I found a Tutorial on how to get the idle time of PC. how ever when i run the sample the idle time is always 0 no matter how idle i leave my pc!
the system Up-time is working good but the Idle Time is always 0! any idea why this is happening ?
Windows 7 64bit
I'm in danger of telling you what you probably already know, but that code is for user idle time rather than system idle time.
Using Environment.TickCount is a questionable practice as the value starts at 0, goes up to X (after about 25 days) and then wraps round to -X. So you can't always use straight subtraction as the code suggests.
http://msdn.microsoft.com/en-us/library/system.environment.tickcount(v=vs.80).aspx
Given that you're on running it on a PC though, this should be fine (assuming you reboot fairly regularly).
Depending on how you're running it, you may also want to have a look at this:
GetLastInputInfo API doesn't work if windows is set to "Automatic Login"
Is there a sample code available online to get WinRT to determine if its a slow internet connection within the first second of a web-request call so that I can cancel the request and switch to a local file at the start of the program. Metro requirements expect the app to boot up under 5 seconds and I need my web-request (of 300kb) to return well before that. its usually fast on WiFi but 3G speed may vary.
You can see if you are running on a 3G or WiFi connection by using the connectioncost api.
When you are on 3G you could consider using the local file anyway and then attempt to update it on the background. Additionally you might increase your logic further by checking if the user is currently roaming or even if he or she is approaching his or her datalimit, all which might influence your decision on where to load from. All this can be done through the same API.
You are also mixing up things a little as far as the 5 seconds for your app to start go. Your app can actually take 15 seconds give or take to provide something and only 5 seconds to suspend before you are forcibly cut off. If the 15 seconds isn't enough to start with you can also replace the default splash screen .. with your own splash screen and continue loading as long as you like. Keep in mind your user might not like it.
Why not load the local file and then try to update it on the background? I am not sure about your use case.
I have a .NET 3.5 / C# application running on XP which receives data from another application in small batches (3 or 4 lines at a time), collects the data into a single print job, and eventually submits it to the Windows spooler. This data collection phase usually takes 20 - 30 seconds.
When watching the system in operation, I noticed that the printer that's being used (a networked laser printer) takes a long time - a couple of minutes - to warm up, and obviously this warm-up phase starts only after I've sent the complete print command to the spooler.
So, this got me thinking - is there a generic "fire and forget" method I can use to tell the printer to start its warm-up sequence? If so, I could trigger that immediately upon receiving the first chunk of data, and the printer can be warming up while I'm doing my data collection.
It's not the end of the world if this isn't possible, by any means, but it looks like a nice easy speedup!