Crazy easy dialogs for iOS devs: QuickDialog
github.com
github.com
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.
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!
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:.
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/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.
Good on him for writing a maintainable library, instead of one that will need a major refactor in 30 days.
I would love to have people using the library for months or years to come. I'm sure I'll still be using it. :)
(On another note, ARC is a very welcome addition to the language.)
So it seems quite logical for developers to rely on most modern technologies, esp. since supporting older technologies comes with a cost.
Still, its not like I'm doing more work anyway, going with ARC saved time on development. If Apple ends up never releasing 4.2, I would just had to "finish" the job.
Looks like a cool library though! Once they manage to make Xcode 4.x work as well as Xcode 3.2, I will try it.
Have you tried AppCode, from JetBrains? Its still in beta, but its magnificent.