How does [self.tableView reloadData] know what data to reload?

Question

It bugs me to death that my viewcontroller, which happens to be a tableViewController, knows without being told that its property that is an NSArray or an NSDictionary holds the

Answer 1

Okay, I understand your frustrations because the vast majority of iPhone instructional material do not pay sufficient attention to overall app design. They make a beeline for the eye candy interface and pay only lip service to way that the app should handle the data even though handling data is the entire purpose of the app in the first place!

The instructional materials do not spend enough time explaining the Model-View-Controller design pattern on which the entire iPhone/Cocoa API is based. You're having a hard time understanding anything because you keep trying to cram functionality into the wrong objects under the mistaken belief that the UI view is the core of the program as the instructional materials have led you to believe. Under this misapprehension, nothing makes sense, not even the Apple Documentation.

You need to step back and rethink. It is not the function of a view to decide what data to display and when to display it. It is not the function of the table view controller to hold, manage or store the app's data. Those functions properly belong to the data model object (which you've possibly never heard of.) You're having trouble because you are trying to split the data model task across the view and the view controller were they do not belong.

Apparently, your app doesn't even have a data model because you are holding the table's data as properties of the tableview controller. Although you often see this in simplistic tutorial examples, it is bad design which will collapse under the complexity of any but the most trivial apps.

Instead, your data should be stored in and managed in its own custom object. This is the data model. In your case, it sounds like you have data spread across two arrays so you would create a data model object something like this:

@interface MyDataModel : NSObject {
@protected
    NSArray *arrayOne;
    NSArray *arrayTwo;
@public
    NSArray *currentlyUsedArray;

}
@property(nonatomic, retain)  NSArray *currentlyUsedArray;

-(void) switchToArrayOne;
-(void) switchToArrayTwo;
-(void) toggleUsedArray;

@end

#import "MyDataModel.h"

@interface MyDataModel ()
@property(nonatomic, retain)  NSArray *arrayOne;
@property(nonatomic, retain)  NSArray *arrayTwo;

@end


@implementation MyDataModel

- (id) init{
    if (self=[super init]) {
        self.arrayOne=//... initialize array from some source
        self.arrayTwo=//... initialize array from some source
        self.currentlyUsedArray=self.arrayOne; //whatever default you want
    }
    return self;
}

-(void) switchToArrayOne{
    self.currentlyUsedArray=self.arrayOne;
}

-(void) switchToArrayTwo{
    self.currentlyUsedArray=self.arrayTwo;
}

- (void) toggleUsedArray{
    if (self.currentlyUsedArray==self.arrayOne) {
        self.currentlyUsedArray=self.arrayTwo;
    }else {
        self.currentlyUsedArray=self.arrayOne;
    }
}

(Notice that the actual data is encapsulated and that other objects can only access the currentlyUsedArray. The data model decides which data to provide based on the internal state of the data.)

This data model object should be in a universally accessible location. The best method is to make it a singleton but the quick and dirty method is to park it as an attribute of the app delegate.

So in you tableview controller you would have a property:

MyDataModel *theDataModel;
@property (nonatomic, retain) MyDataModel *theDataModel;

then in the implementation

@synthesize theDataModel;

-(MyDataModel *) theDataModel; {
    if (theDataModel; !=nil) {
        return theDataModel; ;
    }
    id appDelegate=[[UIApplication sharedApplication] delegate];
    self.theDataModel=appDelegate.theDataModelProperty;
    return theDataModel;
}

Then in your tableview datasource method:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
    ...
    cell.textLabel.text=[self.theDataModel.currentlyUsedArray objectAtIndex:indexPath.row];
    return cell;
}

If some event anywhere in the app requires you to switch arrays, you just call up the data model object from the app delegate and send it the appropriate switch array message.

id appDelegate=[[UIApplication sharedApplication] delegate];
[appDelegate.theDataModelProperty toggleUsedArray];

Now all subsequent data operations, whether in that particular table view or some other completely unrelated view, will use the data form the proper array.

Why go through all this trouble? It makes the application modular. You can easily add on different views each of which display the data in a different manner without having to rewrite your data management every single time. You can use the data model to manage data that will be displayed in a table, in a webview or on the command line. You can even easily move the data model to an entirely different app.

This modularity makes the management of large complex apps so much easier. You have only one object that manipulates and controls the data. You don't have to worry that some minor error in some rarely used code segment will trash the entire app. You can plugin views easily or remove them easily without breaking the app.

This is of course a trivial example but it shows good practice.

However, you may ask, how does this solve the problem of the tableview knowing what data to load and when to load it? Simple, it doesn't. It is not the job of the tableview to know what data to load or when to load. The data model handles the what-data and tableview controller handles the when. (You can even have the data model issue notifications when it is updated e.g. for a url. then the view controller can register for the notification and call reloadData whenever the data model changes.)

By ruthlessly compartmentalizing and encapsulating functionality in MVC, you create complex apps from simple, reusable components that are easy to maintain and debug.

It's really to bad most instructional materials only pay lip service to this utterly critical concept.