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.
Related
I have a UWP app that needs to check for new data (from network) every x seconds. I do this by starting a new async thread. The app can be minimized or even navigated from in Windows Phone, and this suspends the app.
How do I restore the loop when the user goes back to the app again (it appears to be still open, at the same Page)? This can be done either by re-navigating to the Page in question on relaunch or by restoring the loop. What's the easiest way to do so?
Generally when your app is suspended, if you don't cancel your tasks, the OS will do it. Therefore it's recommended that you will send a suitable signal to your tasks along with saving some progress for resuming operation.
However, in UWP there is something like ExtendedExecution - it should allow your app to run in background up to 10 minutes (as far as I know this is the limit for battery powered devices - not 100% sure about this, and it of course may change on various scenarios).
Nevertheless, I think that checking for changes in few seconds interval may be a bad idea. Maybe you can change the design little and use BackgroundTasks which are designed for background processing.
Most of information about app states you will find at MSDN.
i am working on an asp.net web application, where tasks are assigned to users, we set standard time to every task, in that standard time period the user has to finish the task, there are two buttons on the page, proceed and save, when a user clicks on proceed button, the time is saved in database as starttime, and when the user clicks on save button, the time is saved in database as endtime. this way we are capturing the time period within which the user is completing the task.
the standard time is set on an average time study basis, not every time the task takes the same amount of time.
often users can complete the task in very less time than the standard time, in this case the users are proceeding the task and even after completing the task, instead of saving it, they lock the system and go for tea breaks and after coming from break, they save the task.
i want to save some information on the web page when they lock the pc even when the browser is minimized.
i tried implementing applet using jintellitype library but its not capturing the key combinations that are used by windows os.
i also tried using Silverlight but there is no such support as in winforms application in Silverlight, i have to create a com component or something that interacts with system32 or some native api. it doesn't seem easy for me, i would like to know if there is such library for Silverlight.
it should be browser independent, i haven't tried ActiveX, but i think it can be done using ActiveX, but i don't want to use ActiveX as it runs only on IE.
i want to know all the possible solutions to achieve this.
thanks in advance.
Why don´t you set a kind of timer-check to know if the last time is too far from the correspondent (and previewed) time to perform the job? If a task may expend, for instance, from 1 to 5 minutes, have 21 minutes is too far.
Why din´t you create a timer to TIMEOUT user? If users know they will be timed-out after some time, probably, they won´t leave to coffre-break during the test (a kind of penalty must be aggregated on this, like start from the initial point if timeout).
Why don´t you automatically save the record after the job finish, instead obly the user to press a button?
Until I know, you can perform SUSPEND mode, but not detect them if started from other apps.
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 have this problem when using the Background File Transfer in WP7. It works perfectly when my application is running, but as soon as I click the Windows button, it stops(and resumes when I activate the application again.) Isn´t the purpose of Background File Transfer to run in the background, even when your application is deactivated? Does it have to be in a separate class(some sort of background agent class, separate from the main project?) Really frustrating, when I am doing all that the tutorial here says: http://msdn.microsoft.com/en-us/library/hh202959(v=vs.92).aspx.
Are there some "special" things I need to do to make sure it runs in the background, or some methods, maybe the ones I created by myself(to get the url etc.), that can not be accessed while deactivated? Can I not add to the queue while deactivated, maybe?
Thanks a lot for your time:)
EDIT: A little debugging tells me that the file in the queue is actually downloading. It gets finished, but it doesn´t fetch the next one until I reactivate the app. Can I not use my own methods, variables etc when doing this? Maybe I have an internal queue for, say, 20 items. How can I then populate the download queue(max 5) when this gets to zero?
EDIT2: In the sample from Microsoft, they say that you can add to the queue at a later time:
// Check to see if the maximum number of requests per app has been exceeded.
if (BackgroundTransferService.Requests.Count() >= 5)
{
// Note: Instead of showing a message to the user, you could store the
// requested file URI in isolated storage and add it to the queue later.
MessageBox.Show("The maximum number of background file transfer requests for this application has been exceeded. ");
return;
}
But it does not say if we can do this while in background or not. Since it is about background file transferring, they should have mentioned it, otherwise we should assume it can be done in the background, which seems not to be the case. But we can´t know that. Anyone who can confirm this 100%?
I have looked into this as well and it isn't possible (based on my research) to populate the queue after the max. 5 queued downloads have finished. I thought about using a background agent but BackgroundTransferRequest.Add is unavailable from background agents meaning the only way to queue more downloads is when your app is running (see Unsupported APIs for Background Agents for Windows Phone).
The only thing I can think of is using a background agent to send a toast notification letting the user know that the downloads have finished and that they should start the app to queue the next five downloads. This is less than ideal.
I’ve got a process which will take a little under 5 seconds to complete. The user will most likely notice the program flicker for a few seconds after pushing the “go” button.
My question is:
Is this something that would normally be dumped onto a background worker, or is there another .NET method for handling small tasks, or is this something that shouldn’t be a concern?
FYI:
The process opens a user specified excel file, processes an unknown number of lines (max 1.5 million due to excel I believe), and queries a database (very quick query). So at the worst case scenario the user uploads a 1.5 million row excel file and is running on a very slow internet connection.
If you don't want the user to be able to do anything while the file is being uploaded, then you don't need to put it on a different thread.
If you want the user to be able to go on to other tasks while the file is uploading, put it on a different thread.
As a general rule of thumb, if I have a situation where I absolutely don't want the user to do anything while a long-running process is going, I disable the controls on the form until the task is complete, and usually use a status indicator to show that progress is happening.
My personal guideline for whether or not to allow user interaction is if the results of a process could be altered by a user action in mid-stream.
For example, one program that we have parses a bunch of queries on a highly normalized database (normalized to the point where reporting is sloooow) into "reportable" tables, and I don't want the user altering data in one of the source tables while the query is running, because it will give goofy results.
If there is no harm in allowing user interaction while the process is occuring, then put it in another thread.
Edit
Actually, on reading #UrbanEsc and #archer's comments, I agree with them. Still put it on a different thread and freeze the controls (and include a progress indicator where possible).
I would push this to a background worker. Doing so will keep the UI responsive. If the process ever does lag for more than a few seconds, users start getting nervous ...especially when the lagging process causes the UI to be 'frozen'.
From a user experience point of view it might be best to hand the job over to a different thread or an asynchronous worker and tell the user that his request is being processed in the background. Once the worker finishes, a success/failure message can be handled and shown to the user as required.
The cheapest way to handle the problem is to turn the cursor into an hourglass during the processing. That tells user please wait, I'm busy.
According to the budget (time and/or effort) you're willing to throw in it, using a backgroundworker and some reporting GUI is certainly a plus. But it's up to you according to your app.
For example, I'm currently modifying an in-house app that has 3 users. In that case, the hourglass is OK: All 3 of them will quickly learn they just have to wait. Don't get me wrong: this app is damn important. Without it, the small company that uses it would just die. But if I ask them for 2 hours of extra budget for a nice and tested little GUI, background thread, blah vs an hourglass, what do you think they'll say?
On the other hand, if it's an important operation in your flagship product, of course be nice to your users! Don't hesitate: background thread. Especially if the operation may actually take much longer than those 5 seconds.
Conclusion: Be pragmatic!
I would put it into a background worker or fire of a task if you are in .NET 4.0, for example:
void OnButtonClick(...)
{
new TaskFactory().StartNew(() => { /* your excel and query code */ });
}
I'll vote for the background worker process, since a frozen UI is like a frozen application, and most of users will think your application isn't doing anything at all.
UI thread for a progress bar or some animation, info text noticing what's going on + background worker thread = win
I think every process not related with the UI itself should be started as a separate thred or, in this case, as a bg worker. This will help to maintain the app healthy and easy to improve/fix in the future.
Also, as a user or tester, I really hate flicking and freezing windows...
Regards.
A general rule of thumb is any operation that takes a second or longer to complete requires some form of feedback to the user. This can be a progress bar, message, etc. Anything longer then that then the user becomes frustrated (not sure if they did something wrong, hate waiting, etc).
For operations like this that can take longer based on the environment (number of apps, available memory, data size, hard drive speed, etc) they should ALWAYS be put on a background thread and pipe messages back to the UI. I love the BackGroundWorker for this.