OK. I’m a highly experinced iOS developer and one thing i allways stumble into is how to populate the tableview in a nicely mannor.
If your app is one of the thousands-thin apps with just a tableview, you can use the cellForRowAtIndexPath: datasource-method fine with a couple of if() clauses in.
But the app that I’m maintaining is very large and with a lot of dynamic cells that change in order and design you’ll end up with a completely greasy if()-heirachy that nobody – even your self – can maintain in the long run.
So I’ve decided to start a thread on ideas to solve this messy stuff. So any ideas is good input.
One idea could be to create a collection of UITableViewCells and just query into that collection in the cellForRowAtIndexPath:.
Another idea could be to build an entire object graph of the tree you want, query into that and have a factory class to build your UITableViewCell according to the current object.
Please, let me hear how you’ve solved this business in YOUR app – and how the solution works in the long run. Pro’s and Con’s are welcome 🙂
Stackoverflow isn’t a forum (where one may find threads and discussions where this would be appropriate), but a collection of programming-oriented questions.
Take this statement, from the second section of the FAQ:
If you’d like a large number of ideas for your issue, maybe Stackoverflow’s chatrooms would be a better place to look- alternatively, there are several forums on other parts of the internet that would be a perfect place to hold a discussion about this topic.
If, however, you are just looking for a single way to manage your dynamic UITableViewCell’s in a more organized manner, you may want to edit your post to prompt for an answer instead of a discussion. On which subject, I’ve never had to use an excessive amount of dynamic cells, but for small amounts, I feel creating other functions (such as
- (UITableViewCell *)tableView:(UITableView *)tableView cellType1ForRowAtIndexPath:(NSIndexPath *)indexPath)) to handle the creation of such cells to work fine, if I understand you correctly. I’ve used a system where
cellForRowAtIndexPathjust makes several calls to those other functions, and while it may not be the best way to organize the code, it’s certainly a major improvement over trying to contain everything in a single function. 🙂