0

I'm currently working on the settings section of my iPhone app, and I just came to realization that if each page in the settings had it's own view and .h + .m, that would be A LOT of unnecessary code and views. So I came up with the conclusion that I would simply have only one type of detail view that would change depending on the row in a table view that the user selected. However... I'm kind of struggling.

The Setup:

  • For the main settings view, I want it to be a grouped table view with multiple groups and rows.
  • For the settings detail view, I also want it to be a grouped table view with multiple groups and rows (that is where it gets confusing).

I have seen simple things such as images and labels depend on the previous view, but not grouped table view structures. Is it possible to complete what I want without tons of views or 'if' statements? Any sort of help is apreciated.

Andy B
  • 515
  • 2
  • 5
  • 15

2 Answers2

1

You'll have to do two things (considering you have a setting view controller and a detail view controller)...

First, when a user selects a row in the setting view controller, you have to set the setting you'll be editing in the detail view controller. That is....

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
   [self.detailViewCtrl setSetting:[self.settings objectAtIndex:indexPath.row]];
   [self.navigationController pushViewController:self.detailViewCtrl];
}

In your detail view, you'll have to modify the following method to render your table:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
  // ... do something with the self.setting
}

And you can't forget to reload the table:

- (void)setSetting:(id)newSetting {
  if (setting != newSetting) {
    [setting release];
    setting = [newSetting retain];
    [self.tableView reloadData];
  }
}

This is assuming the following:

  • Your first view has the 'detailViewCtrl' property instantiated
  • Your first view has an NSArray of settings property called 'settings'
  • Your detail view has a 'setting' property
  • Your detail view controller know what to do with its 'setting' property
Dimitry
  • 6,545
  • 2
  • 20
  • 21
  • Z Thanks for the response, but there are some areas of iPhone dev I'm still a little un-clear on. By a property for settings, do you mean a string? Would I also have to define setting and newSetting as strings? – Andy B Mar 05 '11 at 12:39
  • @Andy, the 'setting' should be a custom object (or a settings bundle object?). I'm not sure what properties it would have but it may be something like this: Setting(name, type, value, options). You should consider how you will be loading/storing your settings and how you're going to be manipulating them. – Dimitry Mar 05 '11 at 21:27
1

Yes, it's certainly possible. Apple essentially does this with the Settings bundle and its configuration through a plist file.

What you want to write is a generic table view controller that loads its configuration and contents from an external source (one or more plist files are a very good choice for this). It's not very hard to do, at least as long as the actions your table view executes (e.g. when the user taps a cell) are well-defined and easy to encode in a config file. For example: actions like "open a new page with this config" or "save this value under this key to the user defaults" are simple to set up while something like "have the user take a picture with the camera, then let them crop it to their liking and upload it to Twitter" is harder.

Ole Begemann
  • 135,006
  • 31
  • 278
  • 256
  • Thanks for the response, though I would not want to use the Settings Bundle because it would defeat the point of the app. – Andy B Mar 04 '11 at 23:14
  • I understand that. But the way the Settings bundle uses its plist config file could show you a possible way to implement this functionality yourself. – Ole Begemann Mar 05 '11 at 00:06