<commit_before># LRTableModel, because implementing UITableViewDataSource sucks!

UITableViews are the ubiquitous building blocks of many iPhone and iPad applications. They are easy to add to your application - throw them in a XIB file, hook up your delegate and datasource outlets, and you're set...well, almost. You will be once you've gone through the tedious process of implementing those data source methods.

How many times have you written out something like this?

    - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
    {
      static NSString *identifier = @"Cell";
  
      // yawn...
      UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];
      if (cell == nil) {
        // don't forget that reuse identifier!
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleValue1 reuseIdentifier:identifier] autorelease];
      }
  
      // at least extracting this keeps the method tidy...
      [self configureCell:cell atIndexPath:indexPath];
  
      return cell;
    }
    
OK, you may not have written it; it may have been generated for you (with some convenient placeholders for you to fill in) but the reality is that as your application develops, this method will grow and then you have to duplicate it for every table view controller in your application.

And then you have to decide where your table view should get it's data from. Should you store it in an NSArray instance variable in your view controller? Or an NSDictionary? How about pulling it straight out of a collection on one of your domain objects? There has to be a better way.

### A note on building the project

If you want to check the project out and build it, you'll need to make sure you initialise the project's git submodules first; it has two, Kiwi and Mocky.

* Kiwi: http://www.kiwi-lib.info/
* Mocky: http://github.com/lukeredpath/LRMocky

## A missing abstraction?

Having implemented far too many UITableViewControllers in the same repetitive fashion, I started to wonder if there was a missing abstraction that should sit between your domain model and the UITableView's data source. Something that responds to events in your domain's language (e.g. receive a new tweet, delete a contact), which may or may not be the result of user input (perhaps the Tweet may have arrived from the Twitter streaming API), and publishes events in response to these that speak the language of UITableView: row has been inserted, rows have been deleted etc.

## Implementing the concept of a table model
<commit_msg>Late night grammar sucks<commit_after># LRTableModel, because implementing UITableViewDataSource sucks!

UITableViews are the ubiquitous building blocks of many iPhone and iPad applications. They are easy to add to your application - throw them in a XIB file, hook up your delegate and datasource outlets, and you're set...well, almost. You will be once you've gone through the tedious process of implementing those data source methods.

How many times have you written out something like this?

    - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
    {
      static NSString *identifier = @"Cell";
  
      // yawn...
      UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];
      if (cell == nil) {
        // don't forget that reuse identifier!
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleValue1 reuseIdentifier:identifier] autorelease];
      }
  
      // at least extracting this keeps the method tidy...
      [self configureCell:cell atIndexPath:indexPath];
  
      return cell;
    }
    
OK, you may not have written it; it may have been generated for you (with some convenient placeholders for you to fill in) but the reality is that as your application develops, this method will grow and then you have to duplicate it for every table view controller in your application.

And then you have to decide where your table view should get it's data from. Should you store it in an NSArray instance variable in your view controller? Or an NSDictionary? How about pulling it straight out of a collection on one of your domain objects? There has to be a better way.

### A note on building the project

If you want to check the project out and build it, you'll need to make sure you initialise the project's git submodules first; it has two, Kiwi and Mocky.

* Kiwi: http://www.kiwi-lib.info/
* Mocky: http://github.com/lukeredpath/LRMocky

## A missing abstraction?

Having implemented far too many UITableViewControllers in the same repetitive fashion, I started to wonder if there was a missing abstraction that should sit between your domain model and the UITableView's data source. Something that responds to events in your domain's language (e.g. receive a new tweet, delete a contact), which may or may not be the result of user input (perhaps the Tweet arrived from the Twitter streaming API), and publishes events in response to these that speak the language of UITableView: row has been inserted, rows have been deleted etc.

## Implementing the concept of a table model

{'fraction_non_alphanumeric': 0.053804765564950036, 'fraction_numerical': 0.0003843197540353574, 'mean_word_length': 4.053398058252427, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '603234', 'n_tokens_mistral': 1344, 'n_tokens_neox': 1223, 'n_words': 715}