

Crazy easy dialogs for iOS devs: QuickDialog - escoz
https://github.com/escoz/QuickDialog

======
Zev
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
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
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
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/Logi...](https://github.com/escoz/QuickDialog/blob/master/sample/LoginController.m)

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.

------
chubs
Looks fantastic! Great work. Until i read "the library depends on ARC for
memory management" - unfortunately that'll rule out its use for me :( Having
said that, i look forward to one-day-when i get to use this in an ARC app :)

~~~
drewcrawford
The length of time the ARC compiler is in beta is a blink of an eye relative
to how long all the production apps based on QuickDialog are going to be in
production.

Good on him for writing a maintainable library, instead of one that will need
a major refactor in 30 days.

~~~
escoz
Thanks Drew,

I would love to have people using the library for months or years to come. I'm
sure I'll still be using it. :)

------
acidblue
Thanks for the notification. I plan on pulling the code and trying it out!

(On another note, ARC is a very welcome addition to the language.)

~~~
escoz
Just to update, I committed this afternoon the license, everything is Apache
2.0. Thanks for reminding me of it.

------
gmac
Looks handy. Did I miss it, or is no licence specified?

~~~
escoz
You're right, my bad. I'll figure this out soon. Should be free like most
projects out there.

------
marcomonteiro
Looks cool but if possible remove the dependence on ARC.

~~~
vtail
Unless you need to support iOS 3.x, you'll get ARC for free for your iOS 5.x
_and_ iOS 4.x projects in September with Xcode 4.2 (currently in beta). ARC
and non-ARC libraries can also co-exists in the same project.

So it seems quite logical for developers to rely on most modern technologies,
esp. since supporting older technologies comes with a cost.

~~~
marcomonteiro
Understood, but technically we're not supposed to submit to the App Store
using beta versions of Xcode. Whether Apple would notice is a different story
but a rejection would set us back so I'm not willing to risk it.

~~~
Zev
This isn't a technicality. Apple _will_ reject your app if you compile with
Xcode 4.2.

~~~
escoz
Not for long though, 4.2 is just around the corner. I can't see them doing too
many extra betas before releasing it. By the time you develop your app with
this library 4.2 is probably going to be released anyway.

~~~
Zev
We're _assuming_ 4.2 is going to be released soon. No one actually knows. It
might be tomorrow, it might be October.

~~~
escoz
You're right.. but from previous experience, apple doesn't usually do a lot
more than 5 or so beta builds.

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.

