Thread safe access of subviews?

[sneaky]

In my app I have some core plot views that changes every now and then. The call to change is initiated by whatever thread just parsed the xml data that just came in. As I have a few of these plots on the screen that are listening to different notifications and sometimes the same notification I think this is where I have the problem.

This code here:

for (UIView *view in [self subviews]) {
		if ([view isKindOfClass:[CPTGraphHostingView class]]) { // <<<<<
			if (view.tag == _hostingTag) {
				[view removeFromSuperview];
			}
		}
	}

*** -[ isKindOfClass:]: message sent to deallocated instance 0x234430

In this kind of scenario, how can I make sure that I'm not accessing a view that has been deallocated already, presumably by some other thread?

[Naughty_Ottsel]

All UIKit objects must be accessed on the main thread so in the case of what you're doing it should be along the lines of:

for (UIView *view in [self subviews]) {
		if ([view isKindOfClass:[CPTGraphHostingView class]]) { // <<<<<
			if (view.tag == _hostingTag) {
				[self performSelectorOnMainThread:@selector(removeFromSupeview) withObject:view waitUntilDone:YES]; 
			}
		}
	}

Don't quote that code exactly as I haven't tested it, but it should work, hopefully

[kasparp]

You should not be doing GUI updates in another thread.

You should defer it to mainthread like Naighty_Ottsel suggest, maybe even a bit more I dont even like the playing with UIView and [self subviews] in another thread.

Imo. fetch the Xml, parse it and get it onto your main thread and do your gui updates there.

[sneaky]

I've changed so I'm passing the notification now on the main thread. this I hope should work around the problem.

[Duncan C]

Originally Posted by Naughty_Ottsel

All UIKit objects must be accessed on the main thread so in the case of what you're doing it should be along the lines of:

for (UIView *view in [self subviews]) {
		if ([view isKindOfClass:[CPTGraphHostingView class]]) { // <<<<<
			if (view.tag == _hostingTag) {
				[self performSelectorOnMainThread:@selector(removeFromSupeview) withObject:view waitUntilDone:YES]; 
			}
		}
	}

Don't quote that code exactly as I haven't tested it, but it should work, hopefully

That's the right idea, but the code isn't quite right.

The code:

[view removeFromSuperview];

is sending the message removeFromSuperView to the object "view."

Thus, to send that message to the main thread, it should be rewritten as:

[view performSelectorOnMainThread: @selector(removeFromSupeview) 
  withObject: nil 
  waitUntilDone: NO]; [/b]

The waitUntilDone parameter would only need to be TRUE if the worker thread goes on to do other things that depend on the view having been removed.

[kasparp]

I still think moving the entire gui update to main thread, as I think he did, is a better option that for loop in another thread is asking for trouble.

What happens to the for loop, when [self subviews] array is modified by main or another thread?

What happens if
if ([view isKindOfClass:[CPTGraphHostingView class]]) {
return YES
and for some reason 2 requests got started or maybe the main thread got some input and decided to remove/deallocate the view on its own, now when our thread gets to removeFromSubview it was already deallocated....

[sneaky]

The problem here was coming from 2 sources I think.
1) I shouldn't be playing with the GUI in a background thread. I'm passing the notification on the main thread now so the entire update is done on the main thread.

2) I was running in to these problems in the first place because of performance issues with the app. They seem to be coming from constant core data queries. I've set up an array to cache the last 10 objects my core data fetches has returned now which seems to have solved all my problems.