I have a Windows Phone 8.0 app that I'm porting to 8.1. In 8.0 I depended a lot on BackgroundWorker to execute tasks that I didn't want consuming the UI thread.
I would create the BackgroundWorker, define the DoWork() delegate and then immediately execute RunWorkerAsync()
Now in 8.1 I can't use BackgroundWorker anymore. Instead, I need to create Tasks implementing IBackgroundTask and use IBackgroundTrigger objects run them.
It seems like I need to jump through a lot of hoops just to run code on a different thread. If I want to run a background task immediately to I create a time triggered background task with a new oneShot TimeTrigger() with 0 freshness minutes? That seems like a bit of a hack..
Is there an alternative to BackgroundTask? Should I be approaching my requirements differently?
To run anything on a different thread, all you need to do is call:
Task.Run(delegate() {
// The work to be executed on the background thread
});
You can also await this in a non-blocking way, in case you want to do something after the work in the different thread has finished.
IBackgroundTask is something completely different. It's used when you want to have some code executed on some event when the app is not running. For example, if you want to update the Live Tile every 30 minutes, you would do this using a background task, implementing that interface.
Related
I have a timer that talks to java objects through LS2J. It has only to call some getters of the java objects and to update the GUI with new values. This causes the GUI in iNotes Client to show the "Busy" cursor very shortly when the timer ticks. I is really annoying because it occurs even when another window is open and even in the designer.
I actually have to expect that the functionality in the timer event will get more complicated in the future, so I don't want to solve the problem by making my handler lighter.
Is there a way to tell iNotes client not to show this cursor or even an alternative way to make this regular check without timers?
The NotesTimer class in Notes client (not iNotes) does take over the foreground when it triggers, so there will be a bit of a delay if you do something that takes time to execute. It's possible to set up the Notes client to execute background scheduled agents in local database replicas, so that might be an option. You can to the heavy lifting in background and deposit the results somewhere -- say, in a profile document -- that can be accessed quickly by the UI code.
Alternately, you could try a XPages in the client application. I believe it can do partial refreshes while other stuff is going on.
For the record, I simplified the functionality of the Java call by preparing the data so that the timer only has to read the results. I also made the timer run every 3 seconds instead of 1.
Now I don't see any flicker!
The GUI of my program freezes while the program is doing its work. I created a mass import which can send X-thousand datarows via a called webservice into a database. The code is already very big and I cannot rewrite it for multithreading purpose.
I don't know how to do it. Any suggestions? If needed I will show some code, but at the moment I don't know what to show.
Firstly, you should rewrite it to use avoid synchronously doing this on the UI thread. If you do a lot of work on the UI thread, it simply will freeze the UI thread. There are a few options here:
If your web service proxy supports asynchronous calls, and if you're using VB 11, you can use Async / Await to call the web service asynchronously from the UI thread in an asynchronous method, and control will return back to the UI thread at the same point in the asynchronous method when the call has completed. It takes a little while to get your head round asynchrony, but this is probably the best option if it's possible.
You can use the Task Parallel Library to make calls on a different thread, but then you'll need to think carefully about how that thread is going to interact with your UI thread.
You can use BackgroundWorker to run some code on another thread, but report progress and completion back on the UI thread
You could potentially call Application.DoEvents between each web service call, to let the UI handle events. This is dangerous - it can lead to re-entrant code, so locks won't behave as you expect them to, and similar hard-to-diagnose errors. This should be your last option, if all else fails.
Is there any way to run some activity after a Windows Store app has been installed?
I'd like to get some data from a webservice (data is rarely changes), but I would not like to make the query on the first start, because it might take some time, and I don't want to ruin the user experience.
Thanks!
You can have it run on a separate background thread while concurrently running the main thread. You can allocate limited resources to this separate background thread, then have it subside on it's own.
You can do an async operation as well from your app, see link from MSDN:
http://msdn.microsoft.com/en-us/library/windows/apps/br230301.aspx#AsyncOps
My codeSHOW app loads data asynchronously when it first starts, and stores the async promise as an app level variable so anything else in the app can await it. It's not exactly what you're looking for, but if it helps, it's available at http://codeshow.codeplex.com.
I need to implement a background process in an iOS app, that performs a job every 60 seconds. I know this can only be done while the app is in focus, but I do want this job to finish running in the background after the app is closed. I will use GCD to dispatch a timer that calls my job asynchronously every 60 seconds using either dispatch_async or beginBackgroundTaskWithExpirationHandler.
I am wondering which method is the best, or if they are essentially the same. Is it okay to use beginBackgroundTaskWithExpirationHandler to execute a job even while the app is in the foreground? Or am I better off trying to cancel the job when the app state changes, and then restart the job as a background task?
-beginBackgroundTaskWithExpirationHandler: doesn't run code on a background thread/queue. It tells the OS that you are going to continue doing work when your app is not active.
The two serve completely different purposes.
I want to use NSWorkspace to check if application is launched or closed.
But the process is Launch Daemon and Apple documentation says its not thread safe.
However, the part of code that makes use of Workspace will not be executed at start up or login time. It will be executed after some commands received from other application via BSD communication and process is background process without UI?
Is it safe to use Appkit framework in this situation? Only NSWorkspace API and no other? Alternate solution is Polling? What is your suggestion?
Generally you can use any code that isn't thread safe, as long as you are only doing one operation of whatever the unthreadafe operation is at any given time. I would go ahead and try it, and just be aware that whatever you are doing you can't do concurrently, if you absolutely need to do something concurrently you can try throwing a couple of #synchronized blocks around the code, either in callbacks of a long running background process, or delegate calls.