I use NSOperationQueue to create UIImages in the background,
upon image creation, main thread gets notified and set the image to a view.
While it works and all, main thread is not responding as I hoped while the NSOperationQueue is working.
The point of using thread here is to let UI be responsive to user interactions.
Am I missing something here?
check Invoking thread with a single parameter
Related
I am trying to get my UIActivityIndicator start animating when the process of data consumption start downloading. My concern is: how do you get the activity indicator start animating at the same time? I have gone through some solutions here on Stack Overflow, yet I am trying to find some universal solution, since I am utilizing a subclass of UIActivityIndicator. I am not sure if a separate thread can resolve this issue?
I used:
[self performSelector:#selector(methodname) withObject:nil afterDelay:0];
However, this didn't solve my problem.
Just return from the method starting the activity indicator. The UI (including the activity indicator) updates after an app returns to the main run loop. Handle any long activities (such as your download) asynchronously with delegates or callbacks, so that the activity indicator can continue to run. So return from the method that starts your download as well. Finish later in another method.
Another option is to do the download, or other long process, in another thread. Operation queues and blocks can be used for this purpose. Use a performselector on the main thread to update the UI, as an app can't update the UI directly from within a background thread.
i wrote like:
[self performSelectorInBackground:#selector(backgroundImageLoading) withObject:nil];
to load image background but know i need to stop this when i refresh the view but i don't have any idea how to do
See NSOperation and NSOperationQueue.
Its also to do the process concurrently as like background thread. Here in NSOperation you have cancel method available to stop the operation.
The threads should not be forced to kill. look out the reasons here. It may help you to find the solution.
In my application i am uploading some images to the servelet, which takes some time to complete upload. I have implemented an uiactivityviewer using IB and connected it to an outlet named acticityIndicator. But when i call
[activityIndicator startsAnimating];
nothing is happening!!!
What might be the problem.
i've debugged the code,
the statement is executing, but nothing happens!!!
Are you performing your uploading on the main thread, or kicking off a background thread to do it?
If the former then you are blocking the UI thread so it doesn't have a chance to update the activity indicator.
AFAIK, a thread can not access UI components. But I want to preload images in a background thread and then display these in an UIImageView. Do I have to use special methods to access UIImageView in the main thread then?
If I understood your question correctly, you're half correct. Threads can access UI components, but only the main thread can do it reliably. Your background thread can use performSelectorOnMainThread:withObject:waitUntilDone: to call up selectors in the main thread, and from those selectors interact with the UI.
Example:
[self performSelectorOnMainThread:#selector(updateImage) withObject:nil waitUntilDone:YES];
Is it possible to load a view on a background thread?
I am using buffering to render views into a buffer off screen so they can be scrolled into view later. I want to make the UI more response and it seems to be the off screen buffering that is the culprit, and am wondering if I can load up the buffered view on a background thread as I don't need it available immediately. The problem with doing this seems to be that the thread has its own auto release pool, which then gets cleared when the thread exits. Is it possible for the background thread and the ui thread to share memory or a pool?
Secondary thread should have it's own autorelease pool. Which should be released if the secondary thread exists.
When you pass data between threads the sender should retain it and the receiver thread should release/autorelease it. But in most cases this is done "automatically", if you're using properties or performSelectorOnMainThread for example.