Clever Geek Handbook

When are data source and delegate different objects?

Under what conditions do you need to have separate objects for a data source and delegate? Most of the apps I've come across make sense to have self.currentView.delegate = self

. Is this purely for readability and code clipping?

+3


source to share


5 answers


A data source is just a kind of delegate with a different name and a different set of responsibilities. Apple explains it beautifully in the docs:

A data source is similar to a delegate, except that instead of delegating control over the user interface, it is delegated control of the data.

Separating the two roles allows developers to specify different objects for each when it suits them, rather than forcing them to use the same object for two related but different tasks. You should never need to use different objects for two roles, but sometimes it can be convenient.

Consider a view controller that contains a table that can toggle between multiple "modes", where each mode displays the same items with different details. One way to implement such a table is to do everything in the view controller, but then you end up with code like:



- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *theCell = nil;
    switch (self.selectedMode) {
        case kFirstMode: {
            // set up the kind of cell required for mode 1
            break;
        }
        case kSecondMode: {
            // set up the kind of cell required for mode 2
            break;
        }
        //...and so on...
    }
    return theCell;
}

You can smell the negative code already, right?

Another, arguably better approach, is to create separate data source objects for each mode. When the user switches modes, you simply replace the new data source that knows how to display data for the selected mode. This scheme works even better when different modes display completely different items of data, rather than different aspects of the same items.

+4


source


Pointing to yourself (as a "view controller") is definitely popular, and I believe this is because its just "easier" to write all of your code in one place.

If you follow architectural design patterns, most of you will want to create objects with a single responsibility. This means that your class is only responsible for one thing and only one thing.

You can read more about this pattern here: http://en.wikipedia.org/wiki/Single_responsibility_principle



Putting this in practice, you have a view controller that is only responsible for the layout of your view and an additional data source class that is only responsible for loading data.

These design patterns tend to result in cleaner, more user-friendly code with reduced cyclical complexity .

A class that conforms to any type of Data Source (Delegate) protocol can also be reused. This means you can use the same data logic across multiple view controllers without duplicating code.

+2


source


I think you might not understand data sources and delegates.

Your data source is simply the data you want to use, like UIITableView, UICollectionView, UIPicker, etc.

These elements mentioned above have delegates that you can respond to. Most of the time, the code for the data source and delegates lives in your implementation file, usually some sort of UIViewController implementation.

You can create another object that handles the control's delegates, but my opinion in most cases just adds another layer that is not needed.

I hope this helps.

+1


source


Delegation . The responsibilities of an object are delegated to another object. For example, we used delegation with UITableView, UITextField and UITextView so that it talks about changes, updates regarding certain events.

Data source . It is the responsibility of the data source to provide data to another entity upon request. Example: The data source template is used with table views and collection views. Displays the number of rows and cells to display.

0


source


According to the docs:

The coordinating controller provides services such as:

  • Reply to Delegation Messages and Observation Notifications
  • Reply to action messages
  • Lifecycle management of objects they own (for example, freeing them at the right time) ...

However, it is important to understand that given the circumstances, you can break this pattern. But the ends have to justify the means. So when is it needed? Whenever you, as a programmer, consider it cleaner than having all the callbacks in one place.

Sources: Apple Docs , Wiki - MVC

-1


source






More articles:


All Articles