-1

I have been developing Cocoa Apps for a while and I have a conceptual question regarding the Singleton "pattern" and the use of the NSNotificationCenter for communication.

Suppose I have a class that is responsible for storing the credentials of the user in the app. Lets call it UserAccountController. Such class exposes public methods to perform login/logout operations and notify any interested object that such operations were performed (e.g.: in a tab bar application, I'd like to update all UIViiewControllers when the user logged out).

In my opinion, it wouldn't make sense to have more than one UserAccountController object in the application, also, a second UserAccountController object could also post notifications to the NSNotificationCenter, which may cause troubles to objects registered to receive such notifications.

Given this situation I have two questions:

  1. What pattern to use in classes like UserAccountController.
  2. Any class that uses NSNotifications for information flow in the application should, necessarily, implement the Singleton "pattern"?

By analyzing the Apple's classes I have found that the question 2) makes sense, but I would like to avoid the Singleton "pattern".

Any clues?

Eduardo Coelho
  • 1,953
  • 8
  • 34
  • 60
  • Could you elaborate on item 2, especially what in Apple’s classes hints at this notification => singleton implication? For instance, `NSWindow` and `NSView` post notifications that can be observed by their corresponding controllers and they aren’t singletons. –  Apr 11 '11 at 23:43
  • @Bavarious, I'm not saying that *every* Apple class that posts notifications is necessarily a Singleton. `UIApplication` for instance is a Singleton, while `NSWindow` and `NSView` aren't. My question is: "Should I know that I can't instantiate more than one `UserAccountController` to avoid "problems" (although I could always test the `object` argument of the `NSNotification`) or should I restrict, by design, that no more than one `UserAccountController` can be instantiated (i.e. turning it into a Singleton)?" – Eduardo Coelho Apr 12 '11 at 16:43

1 Answers1

1

I would store the user credentials in UserAccountModel object. That object would hold among other things my current state, i.e. login status. Whenever that status changes, it would post notification to that fact. My UIApplicationDelegate would hold a reference to that model. Now, let's say I have a view where the user enters login credentials, LoginView. My MVC would be UserAccountModel -> LoginViewController -> LoginView.

Black Frog
  • 11,595
  • 1
  • 35
  • 66
  • Ok, that's what I'm doing. My AppDelegate holds a `UserAccountController` object and passes it as argument to the other UIViewControllers' constructor. Each UIViewController register itself as an observer of the NSNotifications and access their `UserAccountController` attribute whenever needed. However, the implementation doesn't guarantee that another `UserAccountController` isn't instantiated and, therefore, have the ability to post notifications that may possibly conflict with the ones generated by the UIViewController's attribute. – Eduardo Coelho Apr 11 '11 at 19:55
  • @Eduardo, calling it UserAccountController doesn't help it's your model object. And if your AppDelegate holds a references and expose that thru a property, who else in your code going to create another one? – Black Frog Apr 11 '11 at 20:04
  • I used the 'Controller' sufix because this object *performs* operations such as asynchronous login, logout, etc. I agree that the user credentials could be wrapped in a Model object. Each UIViewController will hold a reference to the `UserAccountController` created by the AppDelegate. As I said, it would not make sense to create another `UserAccountController`, my question is: "If this object post notifications (which are global by nature), should it be, necessarily, a Singleton"? – Eduardo Coelho Apr 11 '11 at 20:16
  • 1
    No, it doesn't have to be a singleton to post notifications. – Black Frog Apr 11 '11 at 20:28