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.
Related
At the moment, I'm getting data for the next view from the server.
While this goes on, I am showing the user a loading indicator.
After the data have been loaded, the main thread gets notified and loads the nib for the new view.
My question is:
Because I already have this loading mechanism, can I safely load the nib's in the working thread and just push them from within the main thread?
UIKit is not thread safe, so I suspect it should be pretty unsafe loading the nib in a secondary thread. Just loading the nib in a UIViewController and displaying it from the main thread could work for you and may break elsewhere.
I suppose you know about performSelectorOnMainThread:withObject:waitUntilDone to dispatch a method from a secondary thread to the main thread. You could try and use this from your secondary thread when you want to load the nib.
EDIT:
what about preloading the nib while the working thread is retrieving the data, so that when the working thread has done, the main thread has only to display the nib views?
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
I have an NSOperation running not in the main thread. It is spawned from a UITableViewController. When the operation is complete, I'd like to reload the tableview since some data has changed. I've set a delegate for the background to notify on completion. When done, I call a wrapper around reloadData specifically on the main thread using performSelectorOnMainThread.
For the most part, this works well, however, there is a non-0 chance that the original (edit)tableViewController (/edit) gets released and I get zombie calls.
So the question is in 2 parts:
Is it possible to have a delegate from the background thread without retaining the object?
Is this just a bad design? Should I be using NSNotifications instead? Would that be the preferred method of notifying in this case?
Thanks in advance.
A delegate should be retained if there is a possibility that it might be released before any operation on the delegate is invoked. You can set up a state in tableViewController to handle the case when the delegate callback is invoked and the tableViewController is not to be used (Basically make the callbacks act as no-op). Once your operation is done, just release the delegate object.
It is not a bad design but you just need to handle these conditions.
In an iPad app, I have a bunch of UIImageViews inside a bigger UIView. Each UIImageView contains a thumbnail that is generated in a separate thread (so as not to freeze the application). After thumbnail has been successfully generated I call setNeedsDisplay on main thread, however, it doesn't update the UIImageViews as the thumbs become available (I can see them in the log), rather it takes about 5 seconds and then displays all of them at once.
here's what I am doing when a thumbnail has been created in a separate thread:
[self performSelectorOnMainThread:#selector(setNeedsDisplay)
withObject:nil
waitUntilDone:NO];
any ideas?
What's your main thread up to? If your application waits until all the thumbnails are available before redrawing, then it sounds like maybe you are inadvertently blocking on your main thread until your thumbnailing queue has emptied. How are you setting up the threads?
The problem is that you can't tell cocoa that it have to redraw "now".
With setNeedsDisplay you can onely order a redraw, because drawing is ra rather expensive procces.
setNeedsDisplay
You can use this method or the
setNeedsDisplayInRect: to notify the
system that your view’s contents need
to be redrawn. This method makes a
note of the request and returns
immediately. The view is not actually
redrawn until the next drawing cycle,
at which point all invalidated views
are updated.
Mybe its a better and more performant solution to wait for all generated thumbnials?!
I would use NSNotification. Send a notification from your thread loading the images when an image is ready. Your view controller can observe these notifications and update the view as they arrive.
Please help, I don't know what I have to do with didReceiveMemoryWarning exactly. My app launched well, but when there is too many running background apps, it receives memory warning, and exit. I just want to show an alert that asks user to exit some background apps.
I have an appDelegate, in its window there is a view of my viewController, it has another view allocated (composite) with two subviews (a XIB over an OpenGL view), and this is set to be a cameraOverlayView in the viewController.
I tried to release the whole stuff in one at warning, but still exited. Do I have to implement didReceiveMemoryWarning in each subview? Can I somehow "forcequit" the initialization process?
If your app is being terminated while it is active, then you probably have a memory leak causing your app to consume a large amount of memory.
When the OS starts running out of memory it will terminate background tasks first starting with the most memory intensive, then eventually the front-most app. The user never needs to manually terminate background apps to save memory. This is all done automatically.
If your app is in the background then it can be terminated at any time. The best you can do is reduce overall memory usage and hope the OS kills some other more memory intensive apps before yours.
didReceiveMemoryWarning is usually where you would release any cached data you have to try and reduce your app's footprint. Any view controllers in your app whose view isn't currently visible will be unloaded and the viewDidUnload method will be called. This is where you should set any IBOutlet properties to nil.
But again if your app is being terminated while it is active, you should use the Leaks tool in Instruments to make sure you don't have any leaks and you aren't consuming an abnormally large amount of memory.