Programmatically switch UITableView in UITableViewController - ios

Question

NOTE: I know this is a re-post; I posted the same question a few days ago sans-code and, understandably, it was closed. I edited the question to add some relevant snippets but the question was not reopened, so I am reposting here. If this isn't the proper way to do this, let me know!
I have an application with two modes, and the settings screen is slightly different for each mode (one additional section in one of them, a few differences in number of rows, different UserDefaults keys, etc.). In the past I implemented this with a crapton of switch and if statements, but in an effort to make things more maintainable I'm investigating ways on splitting the two modes into their own separate classes of something. Initially I considered making two separate UITableViewController subclasses, however I was having trouble thinking of how that would work with storyboards and such. I then thought to use two separate UITableView subclasses, and select which one to show based on the mode in viewDidLoad.
However, I'm having issues with this approach. I have it set up so that the controller's cellForRow method calls the TableView's cellForRow method, but that's where things break. When trying to do a dequeueReusableCell, the app crashes with the ever vague "EXC_BAD_INSTRUCTION" error on that line.
Here's some relevant code:
ViewController.swift
...
override func viewDidLoad()
{
super.viewDidLoad()
...
tableView = SRScaleSettingsTableView()
}
...
override func tableView(_ tableView: UITableView?, cellForRowAt indexPath: IndexPath) -> UITableViewCell
{
return (tableView?.cellForRow(at: indexPath))!
}
SRScaleSettingsTableView.swift
override func cellForRow(at indexPath: IndexPath) -> UITableViewCell?
{
...
switch indexPath.section
{
case 0:
...
let switchCell = dequeueReusableCell(withIdentifier: "SwitchCell") as! SRSwitchCell
^ Debugger breaks on that line with EXC_BAD_INSTRUCTION
...
return switchCell
...
}
}
Any ideas on what would cause this? Is my approach even correct; is there a better way to do this?

Answer 1

You can keep a single UITableView class (you likely don't need to subclass UITableView at all) and a single UIViewController subclass. Create two different classes that implement the UITableViewDataSource protocol (and possibly also UITableViewDelegate). These two classes can implement the various delegate/datasource methods (e.g. cellForRowAtIndexPath, numberOfRowsInSection, didSelectRow) in completely different ways for the different modes your app needs to run in.
protocol SettingsSource: UITableViewDelegate, UITableViewDataSource {
}
class SettingsSourceForModeA: NSObject, SettingsSource {
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int)...
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath)...
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath)...
}
class SettingsSourceForModeB: NSObject, SettingsSource {
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int)...
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath)...
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath)...
}
class SettingsViewController: UIViewController {
#IBOutlet tableView: UITableView!
var source: SettingsSource! {
didSet {
tableView.dataSource = source
tableView.delegate = source
}
}
override func viewDidLoad() {
super.viewDidLoad()
// whatever logic is appropriate to determine the mode
if appIsRunningInModeA() {
source = SettingsSourceForModeA()
} else {
source = SettingsSourceForModeB()
}
}
}
The key detail in the above code is the source variable in SettingsViewController - the value of source is based on which mode the app is running in, and it determines what class will be used as the data source for the table view.
The storyboard setup is simple: one scene SettingsViewController, and a single stock UITableView in that scene.
Note that the SettingsViewController above is a UIViewController subclass, not UITableViewController, since the data source and delegate protocols are being implemented in separate classes and determined at runtime. This will require you to manually wire up the tableView outlet in your storyboard. However, you do not wire up the UITableView's dataSource and delegate outlets in the storyboard. Instead, it's done at runtime as shown in the sample code above.
Note that you may not have any need to implement UITableViewDelegate, in which case you can just ignore the references to UITableViewDelegate and its methods in the sample code above. Or, if you the UITableViewDelegate implementation (such as the didSelectRow method) is identical for the two modes your app can run in, you may be able to implement that in your view controller class, in which case you can wire up the delegate outlet of your table view directly to your view controller, in the storyboard.

Answer 2

You have a misunderstanding of how the UITableView and UITableViewController work together. A UITableView needs a UITableViewDataSource to provide it the details of the underlying data (number of sections, number of rows and actual cells, etc). This is what the UITableViewController does (it conforms to the UITableViewDataSource). So if you call the cellForRow for the tableView then it will call it's data sources cellForRow method to obtain that.
So in your code when you do this:
return (tableView?.cellForRow(at: indexPath))!
Your table view calls its data source which is your UITableViewController and that calls the table view cellForRow and so on. You have just entered a recursive loop which is eventually killed off with the error you see.
As for your overall approach I would go down the two UITableViewControllers route as that separates out the different logics between the two making it easier to both understand and maintain and also allowing for more reuse as well.
As for how that works with storyboards it depends greatly on how you switch between the two modes but in essence you can setup segues to switch between the two controllers.