3 ms·

Interesting idea. But, I don't necessarily like it. You're moving the display logic for a view controller to be outside of the view controller. You now have to

by Zev 15y ago

Interesting idea. But, I don't necessarily like it. You're moving the display logic for a view controller to be outside of the view controller. You now have to know where a view was created and presented from in order to change any of the view's content around at a later date. With tableView:cellForRowAtIndexPath:, you don't have to worry about where it came from, because the view controller is responsible for managing its own content. Also: as an aside, you should be caching all of your NS*Formatter objects at a per-thread level, rather than recreating every time you need them -- formatters are very expensive to create and set up.

escoz 15y ago
I'm not really moving out of the tableview delegate. There's still a QuickDialogTableViewDelegate class that does the cellForRowAtIndexPath work you mentioned, and you can still override that if you would like. In my view, having the view controller being responsible for creating the cells, like most people implement it, is a pretty bad behavior per se. It works great for little problems, but at a point it simply doesn't scale: you end up with a viewcontroller with dozens of methods and thousands of lines of code about displaying views inside your viewcontroller, which is just not a good place for it: different responsabilities should go to different objects. Besides, if you have to display cells of 5-10 different types, your viewcontroller will become ridiculously large pretty quickly. QuickDialog solves that responsability problem by delegating the creation of cells to separate classes, that know exactly what they're supposed to do. In my view, this is just good OO design, honestly. THanks a lot of the NSFormatter bit, I'll keep that in mind!
- Zev 15y ago
  I'm not objecting to UITableViewCell subclasses to manage each type of view -- thats a nice, reusable design. getCellForTableView:controller: to return an instance of a given cell is essentially what I do (although I keep it as a class method on UITableViewCell instead). My objection is to RootElement and QuickDialogController. What happens if you have to present a screen from multiple places? Or if you need to modify it at a later date, to, say, add another field? For example: Say you have a login screen. And now you want to add a field to ask the user for another bit of information. With your design, you have to know everywhere that you can possibly log in from. Or, you have to add a method somewhere to set up the login view and then push it. And at that point, you might as well just make a separate controller to control everything. Which brings us back to tableView:cellForRowAtIndexPath:.
  - escoz 15y ago
    Right now, all you have to do is modify your root element as you wish, and then call the reloadData on the tableView. That will show the new table automatically, although it won't show a nice animation that somebody would expect. Adding this functionality is in my todo list, and should be fairly simple to do. What you're saying though is not really related to adding/removing cells. I'm not saying you shouldn't create UIViewControllers for specific things, actually its quite the oposite, I think you should have as many controllers as possible, so that they're really small. Funny your example is a login screen, bcse that's the example in my samples on the project. Take a look at the code: it's very simple, and it mostly has to do with the actions that will happen as a result of the form, instead of cell creation: https://github.com/escoz/QuickDialog/blob/master/sample/LoginController.m https://github.com/escoz/QuickDialog/blob/master/sample/Logi... I see this as a much cleaner approach to do exactly the same thing, with the benefit that a lot of the code can be reusable. As a developer, you can spend a lot less time implementing plumbing code to get the cells and fields displayed, and instead focus on how they're used.

by Zev 15y ago

escoz 15y ago

I'm not really moving out of the tableview delegate. There's still a QuickDialogTableViewDelegate class that does the cellForRowAtIndexPath work you mentioned, and you can still override that if you would like. In my view, having the view controller being responsible for creating the cells, like most people implement it, is a pretty bad behavior per se. It works great for little problems, but at a point it simply doesn't scale: you end up with a viewcontroller with dozens of methods and thousands of lines of code about displaying views inside your viewcontroller, which is just not a good place for it: different responsabilities should go to different objects. Besides, if you have to display cells of 5-10 different types, your viewcontroller will become ridiculously large pretty quickly. QuickDialog solves that responsability problem by delegating the creation of cells to separate classes, that know exactly what they're supposed to do. In my view, this is just good OO design, honestly. THanks a lot of the NSFormatter bit, I'll keep that in mind!

Zev 15y ago
I'm not objecting to UITableViewCell subclasses to manage each type of view -- thats a nice, reusable design. getCellForTableView:controller: to return an instance of a given cell is essentially what I do (although I keep it as a class method on UITableViewCell instead). My objection is to RootElement and QuickDialogController. What happens if you have to present a screen from multiple places? Or if you need to modify it at a later date, to, say, add another field? For example: Say you have a login screen. And now you want to add a field to ask the user for another bit of information. With your design, you have to know everywhere that you can possibly log in from. Or, you have to add a method somewhere to set up the login view and then push it. And at that point, you might as well just make a separate controller to control everything. Which brings us back to tableView:cellForRowAtIndexPath:.
- escoz 15y ago
  Right now, all you have to do is modify your root element as you wish, and then call the reloadData on the tableView. That will show the new table automatically, although it won't show a nice animation that somebody would expect. Adding this functionality is in my todo list, and should be fairly simple to do. What you're saying though is not really related to adding/removing cells. I'm not saying you shouldn't create UIViewControllers for specific things, actually its quite the oposite, I think you should have as many controllers as possible, so that they're really small. Funny your example is a login screen, bcse that's the example in my samples on the project. Take a look at the code: it's very simple, and it mostly has to do with the actions that will happen as a result of the form, instead of cell creation: https://github.com/escoz/QuickDialog/blob/master/sample/LoginController.m https://github.com/escoz/QuickDialog/blob/master/sample/Logi... I see this as a much cleaner approach to do exactly the same thing, with the benefit that a lot of the code can be reusable. As a developer, you can spend a lot less time implementing plumbing code to get the cells and fields displayed, and instead focus on how they're used.