Objective-C - Passing Model Objects to a Worker Class From a Controller

Question

I am a complete newbie working on my first iPhone project. I have been a .NET developer for 4 years to give you some background on where I am coming from. I am trying to follow the MVC pattern and do things the right way on my first project. I don't want to hack things together just to get them to work.

Here is my situation: I am trying to parse an XML feed which will only contain 1 object. I have a model object which represents the object I will get from parsing the XML feed. I have subclassed NSXMLParser and am able to successfully parse the XML feed and get values back (using NSLog to check the values). Here is where my disconnect occurs. When moving from my controller to the subclass, what is the best way to call the XMLParser, populate the model object, and return it to the controller?

I am looking for some kind of pattern to follow which would be considered a best practice. I don't want to just throw all the logic into a method on the controller, making it unable to be reused in any situation.

Answer 1

you can create a singleton class, that will manage all of your shared actions. You can find a quick tutorial of creating singleton objects here

Answer 2

If you make your view controller implement the NSXMLParserDelegate protocol, and set the NSXMLParser instance's delegate property to your view controller, your view controller will know when the parser parses stuff and finishes its work. In other words, the view controller can consume a populated data model, once the parser subclass tells the delegate it is done.

As an aside, delegation is one of a few design patterns that OS X applications (and, specifically, Apple APIs) make heavy use of. As you do iPhone development, you'll likely find and make use of delegates everywhere.

If you don't want to use delegates, another option is to implement an observer pattern, issuing notifications from the NSNotificationCenter to observers, which call their selectors (methods) when they hear a notification. The advantage of notifications over delegates is that you can have lots of objects listen for notifications, whereas only one object can generally be a delegate at a given time.

Answer 3

I would put the parsing operation in an NSOperation, inside an operation queue. Then it can get performed on a background thread (note that you have to do some extra work to make that happen for asynch operations in an NSOperation).

When the parsing is all done, store the results somewhere other controllers can see, and issue a notification that the object is ready. You may also want to issue a notification for error conditions, so that controllers waiting for a load to complete know they'll never get an object.

You could also use a delegate as noted by Alex, but notifications are generally more flexible as then you can have a few different objects react to the load.