views:

199

answers:

2

Hi all,

considering good design, is it better for each view controller to manager their own connection / networking / loading, or to centralize it in the app delegate, or a separate object?

Context:

I have a multi-tab app, each with a navigation controller, and a number of view controller below. Each view controller is doing networking loading XML and images. Currently, i have it setup that it calls to the app delegate to get the xml asynchronously, processing it, and then calling back the top view controller to display the info, and then launching a separate process of loading the images into an array, and sending callbacks for when each is loaded.

From an architectural view-point, is it better to have more networking code in each of the view controllers or calling back to the app delegate?

Ideas / opinions?

TIA.

A: 

When I have a situation like this I tend to create an object that handles all the networking stuff for me. That way I end up being able to write code like:

[netObj getXML:somePlace];

The main reason I like this approach is because it keeps my code base tidy and minimizes duplicated code.

Dean Pucsek
A: 

It's going to make much more sense to have this in each View Controller, I think. The way you've got it set up now sounds a bit weird - you must either be using delegation so that the App Delegate can speak to each view controller, or you have a ton of references to your View Controllers in your app delegate which you probably don't need. I'd imagine your app delegate is cluttered, and I'm curious as to how you're handling things like if the user decides to stop looking at a particular view before the XML related to that view has been sent back to your app and parsed.

If you're worried about having code duplication in your View Controllers, you can probably mitigate that by using Categories.

In the end though I think it's probably best for domain objects to handle this, and not the View Controllers. For example, in viewWillAppear you get or create an instance of a domain object and kick off a getData method which has the view controller as a delegate. All of the requesting/parsing is done in your domain object and when it's completed, it sends your view controller a getDataDidFinish message or something like that.

bpapa
What I have been doing is placing most of the networking calls in the app delegate, and when the xml parser returns, it checks which view is the top view controller, and then calls reload table on that. But the problem with this approach is that there is far too much code in the app delegate. I have opted to refactor out all the networking into a new singleton. It simplifies the app delegate a bit, but not as much as I'd like.