Android has Looper, and iPhone has Run Loops. It seems like Blackberry would have a similar backed in facility to queue and run threads.
Does anyone know if there is?
I'm not too familiar with Android yet, but some quick reading shows that what you're looking for is the invoke series:
Application.invokeLater - this allows you to add a Runnable to the event queue of the main thread, optionally at a scheduled delay /repeat interval
Application.invokeAndWait - add the Runnable to the event queue of the main thread and wait for it to complete execution.
Application.cancelInvokeLater- cancel a scheduled invokeLater request.
Reference: http://www.blackberry.com/developers/docs/4.1api/net/rim/device/api/system/Application.html#invokeLater%28java.lang.Runnable%29
And: http://www.blackberry.com/developers/docs/4.1api/net/rim/device/api/ui/UiApplication.html
Related
I found Apple's document to understand why i should use run loop to implement task in main dispatch queue.
According to Apple docs,
The main dispatch queue is a globally available serial queue that executes tasks on the application’s main thread. This queue works with the application’s run loop (if one is present) to interleave the execution of queued tasks with the execution of other event sources attached to the run loop. Because it runs on your application’s main thread, the main queue is often used as a key synchronization point for an application.
but still, i can't understand 'why' run loop is needed. it sounds like 'it needs run loop because it needs run loop'. I will very appreciate it if someone explain me about this. Thank you.
why i should use run loop to implement task in main dispatch queue
Normally, you don’t, because you are already using one!
In an application project, there is a main queue run loop already. For example, an iOS app project is actually nothing but one gigantic call to UIApplicationMain, which provides a run loop.
That is how it is able to sit there waiting for the user to do something. The run loop is, uh, running. And looping.
But in, say, a Mac command line tool, there is no automatic run loop. It runs its main function and exits immediately. If you needed it not to do that, you would supply a run loop.
DispatchQueue.main.async is when you have code
running on a background queue and you need a specific block of code to
be executed on the main queue.
In your code, viewDidLoad is already running on the main queue so
there is little reason to use DispatchQueue.main.async.
But isn't necessarily wrong to use it. But it does change the order of
execution.
async closure is queued up to run after the current runloop completes.
i can't understand 'why' run loop is needed
Generally, a run loop is not needed for command line apps. You can use run loops if you have a special need for one (e.g. you have some dynamic UI that is performing some tasks while you wait for user input), but the vast majority of command line apps don’t require run loops.
As the docs say:
A run loop is an event processing loop that you use to schedule work and coordinate the receipt of incoming events. The purpose of a run loop is to keep your thread busy when there is work to do and put your thread to sleep when there is none.
So, if you need to have your app wait for some incoming events or you’re dispatching tasks asynchronously between queues, then, fine, employ run loops, but otherwise, don’t bother. Most command line apps don’t need to use run loops at all.
I have a persistent queue which executes tasks on a background thread. This is useful for situations where a user is offline, etc and tasks need to persist until completed. Tasks are queued up and then executed until completed successfully. This queue runs on a background thread. Works great.
My issue is that when I try and make a call to the Windows Azure iOS toolkit from the background thread it never returns. Whether using the delegate pattern or block pattern implementations. So for example:
[storageClient fetchBlobContainerNamed:#"myContainer" withCompletionHandler:^(WABlobContainer *container, NSError *error) {
....
}];
the completion handler will never be called. I have confirmed that Azure toolkit does not like being called on a background thread. The same code executes fine when it is shunted over to the main thread. However this breaks my whole persistent task queue.
Any ideas on how to get Azure toolkit SDK to run from a background thread?
Could you please file a bug here with the simplest possible repro? We will investigate.
Currently i am following thread to check wheather my internet is active or not in my application, but as it is taking time to give the response ,so this will freeze my UI.
So is there any way to implement it without freezing UI(like NSOperation).
If the internet is indeed down, it takes time. It is limitation of Apple's API. We have to live with it or put a timer to cancel the operation after 30 secs or so. But if a genuine response especially via GPRS takes more than 30 secs, you will be canceling that too if you put timer condition.
Alternatively, you could check for internet status asynchronously and display an ActivityIndicator or similar in the main thread. This means that you create a new thread which will run parallel with your main thread (in your case, the GUI that are freezing).
I want to put an Abort Label or button below...the processing message is shown in ZK. or is there any way to load my custom components instead of the default Processing. message in ZK.
Want will happen if do abort while processing is it ideal to do that, I want to do that anyways as few times my application sleeps while loading
ZK is built on Servlets. When the busy button is shown on the ui awaiting the ajax response then the servlet thread is doing long running work on the server. Perhaps it would be possible to send another thread to interrupt the first thread but really that is high risk as all the servlet threads can end up doing long running work and no new ones will be available to cancel them.
The best solution is that long running work should not be on the servlet thread but handed off to a background thread or message queue. See zk-asynchronous-ui-updates-and-background-processing. In that example the work is offloaded to a java.util.concurrent.ExecutorService which has an API to cancel the work.
Note that cancelling of a working thread uses interruption and it is not guaranteed that code which doing the work will respond to the interrupt properly such that it is actually cancellable. The answers on the thread cancel with executor service outline some of the issues and you should test whether the work you are doing can be interrupted using the API.
I find the Post notification and delegate function are very useful in iOS. Once I finish a task I can notify another piece of code to do something. I am sending out notices for others to do the work.
Post Notification is when you sending notice right away, whereas delegate sometime down the line it will send a notice.
In Android I know there's event Listener, but that's only passive listening. What about me actively sending notices? Does Android have that equivalent?
Handler which can be fired right away or with postDelay() you can fire them later
You could either use a Handler to get notified from a running Thread or the AsyncTask which does run some code and after it's finished it notifies the UI Thread.
You are probably looking for a way to thread your application? Where there are other "worker" threads that do long computations (or do buffered IO stuff). The way you would do this is by creating an AsyncTask. Within an AsyncTask, there is a "doInBackground" method that seems to be what "delegate" is in your question. "onPostExecute" will handle whatever's returned in "doInBackground". More in the AsyncTask documentation.
Another option is to simply use a Handler and use postDelay() for later executions: