I am writing a Cocoa application that I keep adding buttons, views, and layers to. However, because of all these additions my appdelegate class has become rather big and difficult to read. I therefore decided to move some of the UI related calls to other classes from the appdelegate. However, it seems UI calls have to be done only on the main thread, and (correct me if I am wrong) from the appdelegate. My experiment to move calls into other classes also made me run into difficulties on making sure everything was performed correctly on the main thread. So, all of my UI calls are still called from the appdelegate class.
My questions is how can I improve the design of my application? Can I call the UI from other classes than the appdelegate in a way that avoids problems with threading? Can I split the appdelegate class into severeal files, one for buttons, one for views etc., or is there a better way to design the application? Any suggestions on links to examples or tutorials/books are greatly appreciated.
Thanks everyone. Cheers, Trond
Cocoa is based heavily on the Model-View-Controller architecture. There is some really great reading on how to use this pattern in Cocoa in the Cocoa Design Patterns reference. Basically, you want to have as little UI code in the app delegate as possible. The app delegate should be responsible only for app-level control, if possible. It’s much better to put UI controller code in separate controller classes. The MVC architecture leads you down the right path; Cocoa provides the views, you write your model classes—the “business” logic of your app—and then use a view controller to coordinate the two.