I'm trying to understand how things work in regards to concurrent programming and calling setNeedsDisplay. I basically have Three objects.
Main View - container with different UIView objects, the main one being a UIScrollView
Small Map View - a small UIView that draws a miniature version of one of the other UIView items on screem
Processor - a delegate of the Main View that calculates what's on screen and calls the Main View back with what's in view.
So a simple use case of what's going on is the user touches the ScrollView and then the processor updates what's in view of the scrollView (like calculating coordinates, center point, etc) It does this using blocks and does it asynchronously. This then posts a notification to the MainView object.
When the MainView receives the notification, it just calls
[smallMap setNeedsDisplay]; // example 1
I put some logs around this call, and I do see it gets called right away. However, the drawRect: of this function does not get called right away. It gets called after 2 seconds or so.
I remember reading that setNeedsDisplay just marks the view for redraw to happen on the next event of the run loop.
But if I add this code instead:
// example 2
dispatch_async(dispatch_get_main_queue(), ^{
[smallMap setNeedsDisplay];
});
My view gets redrawn right away.
I guess I'm confused as to why I have to ask for the main event loop to call setNeedsDisplay to immediately redraw something. Like in example 1, by me calling setNeedsDisplay, is that done in the background or something and that's why it doesn't get redrawn right away? I'm trying to understand the difference in what's going on behind the scenes so I know what to look for the in future. Like should I have all my calls that need to be immediately redrawn in something similar to the example 2 block? Or is it because I'm processing my data asynchronously that I need to then ask for the main queue? Thanks!
My guess is 1 of 2 things:
Your code that is running on a separate thread is calling your MainView methods from the separate thread instead of using performSelectorOnMainThread or a GCD call that invokes the code on the main thread. Thus your call to setNeedsDisplay is actually taking place on a background thread, which is a no-no, as the other poster said.
The second possibility is that your MainView code is running on the main thread, but it gets busy doing time-consuming processing, or waiting for a synchronous call to another thread to finish, and doesn't service the event loop.
You can rule out the first possibility by setting a breakpoint on your call to setNeedsDisplay and looking at the call trace in the debugger to see what thread it's running from.
Figuring out the second possibility will take a little more work. You might need to delve into instruments.
setNeedsDisplay is a UIKIT API call and has to be called from the main thread of the application, also known as the UI thread. That's why calling it in a background thread doesn't have any immediate effect and scheduling it on the main queue has immediate effects.
See this related question https://stackoverflow.com/a/6988115/172690 for a more detailed answer.
Related
I've been trying to implement this for a long time and I have gotten no favorable results.
Say I have a method in the which an HTTP request is performed (specifically, a twitter update), and say I want to display a UIActivityIndicatorView while the HTTP request is in progress (I know when it is done because there are delegate methods that are called when the request is done, either with positive results or negative ones).
I've seen many answers that say that threading is necessary for the implementation of this class. At first I tried calling the startAnimating method in a different thread and the stopAnimating method directly (without starting a new thread). After that I saw how this guy does it and I thought this was safer as I was starting and stopping the indicator in two different methods (the delegate methods for the twitter update).
However, none of this two ways of doing this have given me the results I want (the activity indicator does not show up at all). Is there anything I'm missing?
Thank you in advance and I apologize if my question is too long.
Your help is very much appreciated.
Threading is absolutely forbidden when working with UIKit subclasses. You may have seen reports that UIActivityIndicatorView uses threading internally, but in no way does that mean you can access the object from multiple threads. All UIView subclasses (including UIActivityIndicatorView) must only be accessed from the main thread. This includes calling -startAnimating and -stopAnimating.
If you rewrite your code such that you're only ever accessing the activity view on the main thread, and it still isn't working, then I would guess that the view was either not added to a visible view, is covered up by another view, or has a frame that puts itself outside of the visible area of its superview.
You cannot perform UI stuff in a secondary thread.
You should perform your HTTP request in a secondary thread, while calling the activity view from the main thread.
I recommend using DSActivityView which is so much easier to use. Just 1 line to show an activity view, 1 line to hide.
MBProgressHUD it's also easy and shows and hides itself when the secondary thread has started/finished. Something like this:
[HUD showhileexecuting:"yourstuff" animated:YES]
"Yourstuff" will run on a separate thread.
You should not perform UI activities in a secondary thread.
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.
I wrote some sample code in a separate application, that basically queues up items in an NSMutableArray. I then have a method which loops through that array and creates an NSInvocationOperation, puts it in the NSOperationQueue, releases the operation and so forth. The method then gets called (simply prints out the string that was stored in the array and passed into the operation), does it's job, and sends an NSNotification back to the ViewController. The observer method gets hit, but the operations have a lag on them. For instance, the observer method simply updates a UILabel with how many messages are left in the queue. It eventually does this, but there seems to be a five second lag in between all of the NSOperations completing and the UI updating. To me it seems like the NSOperationQueue is blocking the main thread. Is there anyway to get the UI to respond immediately to the notifications?
One important note is that I have not tested this on the phone yet, just the simulator. I'm not sure if this makes a difference.
Sorry in advance. I'm away from my computer and I don't have the code in front of me. Hopefully I explained it well enough. Also I have read the documentation, just haven't found anything that's really answering this specific question for me.
The delay is typical of UI updates that are performed on threads other than main.
To see your update instantly on the UILabel, be sure to invoke whatever method is updating the label's text as follows:
[self performSelectorOnMainThread:#(myMethodToUpdateLabelWithText:) withObject:text waitUntilDone:NO];
where myMethodToUpdateLabelWithText is a method within your class that sets the label's text value.
I have an iphone3g with this function running in my ViewController
- (void)viewDidAppear:(BOOL)animated {
[super viewDidLoad];
}
I use a TabBar iphone app. But when I click from tab 1 to tab 2 and debug the secondView Controller it is stopped before the view is actually in the users view.
So there for when you click tab 2 until every function inside - (void)viewDidAppear:(BOOL)animated is complete the user gets to see the view.
Where is the function ViewDidShowToUser? Now I have a few functions running so it's sometimes slow and you're thinking the button is not working really..
First of all, you're calling [super viewDidLoad] instead of [super viewDidAppear:animated] inside your implementation of -viewDidAppear:
Secondly, using the debugger and breakpoints gives an artificial view of how your app behaves. In real world usage, users aren't going to notice that the -viewDidAppear: method returns before actually showing the view.
The real problem is your work that takes too long to complete and makes the app appear sluggish. You should consider performing the work asynchronously, and you have a couple of options to do that.
In your viewDidAppear: implementation you could use performSelector:withObject:afterDelay: to queue up the work. This method will return immediately and schedule your selector to be called in whatever time period you specify. If you pass 0 as the delay, it'll be queued up to run on the next iteration of the run loop, effectively giving you a way to return from the method and keep the user interface responsive.
You could use blocks, if you're not targeting anything below iOS4, and harness the power of Grand Central Dispatch to thread out your work nice and safely.
you are calling super on viewDidLoad: inside of viewDidAppear: ....change the line [super viewDidLoad]; to [super viewDidAppear:animated];
There's no easy way to tell.
UIKit makes UIViews. UIViews draw to CALayers. CALayers are handled by CoreAnimation.
CoreAnimation decides when to ask UIView to draw the layers. It draws all the layers on screen and then composites them on the GPU. Only after they're composited does the screen display the updated UI. This decoupling happens in order to allow CoreAnimation to do the majority of the work independently of the UI thread, but it means that you can't easily tell what's "actually on screen".
There is no easy way to tell when the screen has actually displayed something (apart from the now-private UIGetScreenImage()). viewDidAppear: gets called after UIKit finishes constructing (and animating) the views/layers. At that point, they will be "seen" by CoreAnimation after the next run loop, and displayed shortly thereafter. If you do lots of processing in viewDidAppear:, then CoreAnimation will never see the updated "model tree".
When the return button on the keyboard for a textfield is tapped I want to add a UIView, then connect to a website with NSURlConnection sendsynchronousrequest and I have the code in that order
But when I run in the simulator (I can't run on device) the connection is run first then the subview is added (ie the opposite of the order of the code)
Why is this and how can stop it, because I want the view to added, then the connection done and then the view removed.
The subview is being added, but views are drawn by the runloop. By making a synchronous request on the main thread, you are blocking the runloop, so the view won't be drawn until after the request completes. Do the request asynchronously, either by using the async API or by doing a synchronous request in a background thread.
Many actions happen on the run loop, rather than in the order you code. If you really want to code the way you have, then performSelector:withObject:afterDelay: with a delay of 0 might work to trigger your NSURlConnection (you will need to move that code to a method).
As JK suggests, an asynchronous request might solve it anyway, and improve the UI. I'm a great fan of ASIHPPTRequest library, which makes async trivial.