Question

I’m working on a largely navigation-based iPhone app that communicates with a REST API using OAuth, and I’d like to know how my classes should best communicate with each other. I’ve got multiple UITableViews, multiple UITableViewDataSources, an API class, and a view controller that handles authentication in a web view.

Here’s how I have things structured now:

• My UIApplicationDelegate owns an instance of the class that knows how to communicate with the REST API
• I can ask the API class to call a REST method, and it returns with the data (it wraps ASIHTTPRequests to handle OAuth transparently, so it doesn’t currently know which object asked for the data)
• If the user isn’t authenticated, I can ask the API class to initiate the OAuth process
• The OAuth dialog can be presented, and the application granted access to the API on the user’s behalf

The trouble I’m running into is that my UITableViewDataSources need to communicate with the API class to fetch their data, but authentication might need to happen first, which involves a modal authentication view presented by a view controller.

1. Would it be better to have each UITableViewDataSource model own its own instance of the API class, or should the API class be a singleton?

2. If each model owns an instance of the API class, how should it communicate to the view controller that authentication needs to happen?

3. If the API class is a singleton, how should it interact with multiple models and view controllers to present the authentication dialog? Delegates for each? Post NSNotifications?

4. Some other way I haven’t thought of?

Really, I think the core of the problem is that I have one class that’s primarily used for data fetching purposes, but it might need user interaction to do so successfully.

Answer 1

I typically use a singleton exactly in the way you describe and it works well. Here is how I would answer your questions.

1. Singleton

2. N/A. Use a singleton.

3. Notifications work well, but I tend to prefer to pass a delegate with each request and then keep a hold of it inside the singleton until the request has finished at which point I just call back to the delegate with a success or failure message. Notifications can get pretty messy if you have multiple view controllers that are live in your navigation stack all potentially listening and responding depending. I’ve seen that introduce some really weird bugs. If you’re careful, notifications work just fine, but passing a delegate allows you to associate a specific delegate, typically the current view controller, with a specific request which is often ideal.

4. I think you’re on the right track.