Designing Cocoa application

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 c开发者_Python百科alls 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.

UI calls need to be done from the main thread, that part is correct. However, you don't need to do them from the app delegate. You can do them everywhere you like, as long as it's done on the main thread.

Now, some UI things can be done on other threads but AFAIK UIKit is not designed to be thread-safe and thus strange things and crashes may occur.

There's nothing wrong with splitting things off into other specialized classes. I do it all the time. You might want to introduce a single object that stores and manages states and maybe gives access to your specialized "controllers".

Have a look at UIViewController and what it offers you, if you can split your app into "pages" this might be the way to go.