Question

REVISED…

The crux of the app is communicating with a database server. Responses from the server to the app are all in XML. There are several screens. Example, screen 1 lists the user’s information, screen 2 lists the user’s past trades, allows new trades, and so on.

Here is some code from my AppDelegate:

StartViewController *svc = [[StartViewController alloc] init];
TradeViewController *tvc = [[TradeViewController alloc] init];
CashViewController *cvc = [[CashViewController alloc] init];
ComViewController *covc = [[ComViewController alloc] init];
PrefsViewController *pvc = [[PrefsViewController alloc] init];

NSMutableArray *tabBarViewControllers = [[NSMutableArray alloc] initWithCapacity:5];
UITabBarController *tabBarController = [[UITabBarController alloc] init];

UINavigationController *navigationController = [[UINavigationController alloc] initWithRootViewController:svc];
[tabBarViewControllers addObject:navigationController];
navigationController = nil;

navigationController = [[UINavigationController alloc] initWithRootViewController:tvc];
[tabBarViewControllers addObject:navigationController];
navigationController = nil;

navigationController = [[UINavigationController alloc] initWithRootViewController:cvc];
[tabBarViewControllers addObject:navigationController];
navigationController = nil;

navigationController = [[UINavigationController alloc] initWithRootViewController:covc];
[tabBarViewControllers addObject:navigationController];
navigationController = nil;

navigationController = [[UINavigationController alloc] initWithRootViewController:pvc];
[tabBarViewControllers addObject:navigationController];
navigationController = nil;

[tabBarController setViewControllers:tabBarViewControllers];

[[self window] setRootViewController:tabBarController];

self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];

Trying to stick with the MVC style, I have a singleton class which does all of the “processing”.

Now an example on how I run into a wall… the user can change their email address on screen 5. Enter new email address into text field and click the save button. The button then calls a method from the singleton class which sends the new email address to the server and (via the URL) and receives a XML response confirming the change.

Here are my problems:
1. I start the spinner from the view controller before I make the singleton class method call – but not knowing when the app to server send/receive is finished, how do I make the spinner stop at the right time? I can’t of it from the singleton class, I tried that. From what I know, it has to be from within the VC or is there a way to change VC output from my singleton class?

1. The singleton class NSURLConnection is handling ALL of my communication. Everything from a simple, email change all the way to updating transaction tables. This just seems wrong to me and makes it very difficult to keep track on who is calling what. Again, I am going by my interpretation of MVC. I think it would be much easier to have a NSURLConnection for every VC and do some processing in those classes. However that would not be MVC(ish).

2. I have close to a 100 variables, arrays, etc… in my singleton class which I use to assign values to all my VC. This also seems wrong to me but I can’t think of any other way.

Answer 1

how can I distinguish in the NSURLConnection delegate
(connectionDidFinishLoading) which URL call is being made?

Each of the delegate methods (such as -connectionDidFinishLoading:) has a connection parameter that tells you which connection sent the message. A given connection can only load one URL at a time, so there’s a one to one correspondence between URLs and connections.

How can I tell outside of “connectionDidFinishLoading” when the download is completed?

That method tells you when the connection is finished. It’s up to you to store that information somewhere where it’s useful to your app.

Update: Based on what you’ve added, your “processing” class is your app’s model. The rest of the app shouldn’t care that each transaction involves a message to the server — that’s the model’s business alone. Also, there’s no reason that the model has to be a single object (let alone a singleton) — it can be a group of objects that work together.

So, you might have a class (let’s call it Processor) that represents the application’s interface to the model (some might even call this a “model controller”). An instance of Processor might create a local database for storing the current local state of the app.You might also have a Transaction class that represents a single transaction with the server. A transaction could create a request, send it to the server, get the response, update the database, and tell the Processor that the transaction is done. Or, maybe when some other part of the app (like one of your view controllers) asks the Processor to process a new transaction, the Processor passes the requesting object along to the transaction that it creates so that the transaction can update the requestor directly.

It’s hard to say what the best plan for your app is without knowing where you’re planning on taking it, but the usual guidelines hold:

• break your problem into parts that are easier to solve

• limit the scope of each class’s responsibilities

• if something seems to complicated, it probably is

Breaking your model up into several classes will make it easier to test, as well. You can imagine how easy it would be to write a set of unit tests for the Transaction class. The same goes for Processor — if the server transaction stuff is in a different class, it’s easier to test that the Processor is doing the right thing.