cocoa-design-patterns | 易学教程

Confused in getting the ManagedObjectContext from AppDelegate

阅读更多关于 Confused in getting the ManagedObjectContext from AppDelegate

问题 I've been looking at the documentation on Core Data and trying to figure out how to arrange the Core Data Stack so it's accessible to all of my UITableViewControllers. All the examples provided by Apple show this to be implemented on the AppDelegate yet the documentation doesn't recommend this approach because it's too ridged! See link. (Why this isn't mention on the iPhone SDK documentation is another mystery) My problem is that I've repeated the design pattern as per the Core Data example

Bad-practice to retain 'self'?

阅读更多关于 Bad-practice to retain 'self'?

问题 I have a simple query that I'd like cleared up by someone... Is it bad-practice to retain self? I have a server request object that I'd like to make. I'd like to be able to use it in the following fashion: ARequest *request = [ARequest request: someParam]; request.delegate = self; [request begin]; In order for the object not to self destruct as soon as the autorelease pool is drained, I imagine I need to call a retain in it's init method and then a release once the server response has been

MVC in a Cocoa document-based application

阅读更多关于 MVC in a Cocoa document-based application

I'm going through a refactoring and reorganization of my application at the moment. I've realized that some of the separation between models and views, and their controllers has diminished and I wish to do some cleaning up. I have several key classes used in my app: NSPersistentDocument, NSWindowController, and a model class. The NSPersistentDocument class acts as a "model-controller"; it owns an instance of the model class, and manages all interactions with the model. The NSWindowController class acts as a "view-controller"; it owns the main window, and manages interactions of the views

Confused in getting the ManagedObjectContext from AppDelegate

阅读更多关于 Confused in getting the ManagedObjectContext from AppDelegate

I've been looking at the documentation on Core Data and trying to figure out how to arrange the Core Data Stack so it's accessible to all of my UITableViewControllers. All the examples provided by Apple show this to be implemented on the AppDelegate yet the documentation doesn't recommend this approach because it's too ridged! See link . (Why this isn't mention on the iPhone SDK documentation is another mystery) My problem is that I've repeated the design pattern as per the Core Data example shown in TopSongs to retrieve a ManagedObjectContext Entity for a child Table View and the following

What is the correct system design when dealing with third party API?

阅读更多关于 What is the correct system design when dealing with third party API?

问题 This blog post by Joubert just opened my eyes. I have dealt with a lot of design patterns in Java and other languages. But Objective-C is a rather unique language. Let's say that in a project we talk with a third party API, like Dropbox or Facebook. What I've been doing so far is to combine everything that has to do with the third party API into a singleton class. So I can access the class from anywhere in my view controllers. I can just go for example: [[DropboxModel sharedInstance]

Bad-practice to retain 'self'?

阅读更多关于 Bad-practice to retain 'self'?

I have a simple query that I'd like cleared up by someone... Is it bad-practice to retain self? I have a server request object that I'd like to make. I'd like to be able to use it in the following fashion: ARequest *request = [ARequest request: someParam]; request.delegate = self; [request begin]; In order for the object not to self destruct as soon as the autorelease pool is drained, I imagine I need to call a retain in it's init method and then a release once the server response has been received, processed and delivered to it's delegate. However, something is raising a warning bell in my

How should I handle a failure in an init: method in Objective-C?

阅读更多关于 How should I handle a failure in an init: method in Objective-C?

问题 Let's say I'm building a new class for the iPhone in Objective-C. In one of my init methods I want to manually allocate some memory. So, I might have something like this: - (id)initWithSomeObject:(SomeObject *)someObject { self = [super init]; if (self != nil) { myObject = someObject; [myObject retain]; if ( (memory = calloc(1, sizeof(SomeStruct)) == NULL) { // What should I do here to clean up [self release]; self = nil; } } return self; } Now, assuming that the calloc() could fail, and that

Objective C terminology: outlets & delegates

阅读更多关于 Objective C terminology: outlets & delegates

问题 I'm having issues understanding the concept of outlets how the iPhone deals with events. Help! Delegates confuse me too. Would someone care to explain, please? 回答1: Outlets (in Interface Builder) are member variables in a class where objects in the designer are assigned when they are loaded at runtime. The IBOutlet macro (which is an empty #define ) signals Interface Builder to recognise it as an outlet to show in the designer. For example, if I drag out a button, then connect it to the

Difference between NSWindowController Vs NSViewController

阅读更多关于 Difference between NSWindowController Vs NSViewController

问题 I am coming from iOS background and starting to learn Cocoa. On iOS unless we have multiple targets for iPad and iPhone we usually have one Window and manage the screen using UIViewControllers . Where every new screen will most of the time will map to a UIViewController . However on cocoa this seems to be the otherway around where a new screen/window is manage by NSWindow and it's subcomponents are managed by NSViewController . So if I have multiple window app I should have separate

One UITableView - Multiple DataSource, best design pattern?

阅读更多关于 One UITableView - Multiple DataSource, best design pattern?

This seems like a typical problem, but I have a UITableView that has identical behavior for two separate data sources. What is the best way of going about designing the class hierarchy to have as little duplication and if/else conditions? The view controller is going to do the same exact thing to both data sources, they're just unique in their data set. Should I have the parent controller just set its data source/respective title? The same issue is relevant as well when using a UISegmentControl for displaying two views with the same interfaces, but different data sources. Be careful with your