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.
Related
So I have a background program that starts with Windows, minimized to system tray icon. Once it loads I need it to constantly start checking if a process has started (for example VLC). Once the process has started, It must wait for it to close in order to start doing stuff and then get back to check if it has started. I've been trying to do this for a while now, but I just can't figure out how.
How would I constantly check if a program has started?
One way would be to have the Background Deamon look for aprogramm of a specific name. Unfortunately this not overly reliable (due to name overlaps), would require a lot of polling and runs the risk of race conditions (the process starting when your deamon is still working).
What would be reliable, is if it is the Deamon that actually starts the foreground process. That way it could do work before Process.Start() and after Process.WaitForExit(), with full information when both states happen: https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process?view=netcore-3.1
Steam is a good example. It is a single-instance process, so any further requests can be relayed to the running instance. The desktop links to programms/games are actually weblinks - not programm links. Those links use the :steam protocoll, wich is associated with the steam processes. So it goes like this:
user klicks on a WebLink with :steam procotoll
Windows resolves to hand this into a commandline call to the steam programm
A instance is started with the proper order in via commandline. Single instancing will not allow a 2nd instanc to start, but hand the request over a already running one
the already or now suddenly running instance calls the programm, having full data on when it starts and ends - being the actuall logical caller
In our app users can track and submit journeys they have recorded. I need a simple way of creating a task in iOS. I have already created and tested this on Android. It works via:
The user selects the journeys they would like to submit.
Taps sync and a foreground service is created that syncs the journeys to our API.
This service will continue to sync journeys even if the app is put into the background or even closed.
So in short how can i achieve this on iOS 9-13?
I have already tried creating a background-safe tasks using:
nint taskID = UIApplication.SharedApplication.BeginBackgroundTask( () => {});
However, this only gives the task 2 mins to run which isn't enough. I have looked into the NSURlSessions but they require URls, whereas we are using our own API wrapper.
I would simply like a way of creating a task when the user taps 'sync' and this task also being capable to run in the background. I am not too bothered if the task is cancelled when the app is closed, although if possible would like the task to continue.
Thanks.
This service will continue to sync journeys even if the app is put
into the background or even closed.
First, if your app is closed in iOS, I'm sure do can't run any service in background.
Then if your app is put into background, Apple has strict limit to allow apps running in the background. background-tasks has time limits, you can read the document about more information. There is a section about handling-background-task-time-limits which you can have a try.
Also, Apple allows some specific apps to run in background which have to perform tasks in the background. For example, app that needs to play music in background, update location in background and etc. You can see the Application Registration Categories here. If your app meets the requirement there, you can apply for a background running permission from system.
Refer: Backgrounding in Xamarin.iOS
I would advise you to leverage on Shiny to achieve it.
PerformFetch is the closest thing to what you ask for, it will run in the background and update your app when iOS thinks it is needed (it predicts that according to the previous behavior the user will soon open your app and that the new content is available).
The only alternative is to send the push notification when you want the app to be updated.
That's about it, I understand your wish but it is just that - a wish and not something that can be real.
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 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.