performSelectorOnMainThread “works” just like any other message call. It is a message that is passed to an object. In this example it is passed to the static reference to the AppDelegate. However it could easily have been passed to any other NSObject. When the receiver gets the message, it then makes a subsequent call to itself on the main thread using the selector that was passed in.

Does it multi-cast the call to any object that implements the pageLoaded method (thats running in the main thread)?

Or does it have magic knowledge to send it to the AppDelegate?

Thanks Marcus

However, unlike NSString, NSURL does not have a mutable subclass so there is no concern. Therefore if you wanted to be crazy you could check to see if your incoming NSString is mutable and decide on a copy vs retain. But, I seriously down that the difference between a string copy vs. retain is going to save you a whole lot of memory.

I noticed that your targetURL property is retained instead of copied. If you’re going to be using this retained value in a new thread then why not copy it? Can the url change from under your feet, or does the NSOperation(Queue) system watch for that?

I ask this as I have a routine that matches regexes in a large string, retaining the string would save memory, but the user can potentially edit the string in an NSTextView while the matching is taken place.

Thanks,

Jon

Thanks for the quick response. Glad to know my coding style isn’t completely off.

Jon

Great tutorial, saved me some time learning one of the many ways to do threading in OS X.

Some of your java terminology is a little off. Interfaces in Java are like protocols in Objective-C so the metaphor is a bit of a stretch. Nothing in the compiler is forcing you to implement -(void)main when you extend NSOperation.

NSOperation is closer to an abstract adapter in Java (java.awt.event.MouseAdapter for example) where the required methods have been created and stubbed out. You extend the class and override the methods you need.

Oh yeah, and you don’t override interface methods, you implement them ;)

M@

I did that purely out of convenience as this is a contrived example. However, there is nothing wrong with declaring a static if you expect it to stick around for the life of the application.

I could have made it an ivar with the same effect.

Marcus

Can you explain why you’ve set the urlArray as static in the AppDelegate? Does this help with threading? It seems to violate memory management conventions as it doesn’t get released. Any advantage over making it an ivar? Or is it necessary as the AppDelegate is static, too?

Jon

Personally, I save the dot accessor calls for when I am dealing with C structs and use message calls when dealing with Objective-C objects and messages. Keeps the code cleaner and easier to maintain.

As for the garbage collection — I am not using it any of my current projects so I do not, out of habit, use it in example projects. I am sure that will change when I am finally able to use it in a production application — or when I write a tutorial on it :)

Intentional? Also you’re not using the garbage collector. Together, these examples become rather verbose.