6 ms·
Crazy easy dialogs for iOS devs: QuickDialog
- chubs 15y agoLooks 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 15y agoThe 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 15y agoThanks 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. :)
- escoz 15y agoThanks Chubs! Adding retain/releases into the codebase wouldn't be too hard to do, but I created this for some new projects which won't be ready for another couple of months anyway, so by then 4.2 is going to be released already.
- marcomonteiro 15y agoLooks cool but if possible remove the dependence on ARC.
- vtail 15y agoUnless 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 15y agoUnderstood, 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 15y agoThis isn't a technicality. Apple will reject your app if you compile with Xcode 4.2.
- escoz 15y agoNot 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 15y agoWe're assuming 4.2 is going to be released soon. No one actually knows. It might be tomorrow, it might be October.
- escoz 15y agoYou'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.
- to3m 15y agoWhat about if you just don't want to use Xcode 4.x, because it's (still) missing Xcode 3.2 feature(s) that you use on a daily basis? :) 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.
- escoz 15y agoThanks Marco. For now, I'm not really looking into doing manual memory management, as I don't have any need for it, but you're more than welcome to fork out the code and add it if you would like.
- marcomonteiro 15y agoI did fork it and will be taking a look at it. Thanks for open-sourcing this. It really does look like it can be extremely useful.
- acidblue 15y agoThanks 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.)
- gmac 15y agoLooks handy. Did I miss it, or is no licence specified?
- escoz 15y agoYou're right, my bad. I'll figure this out soon. Should be free like most projects out there.
- Zev 15y agoInteresting 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 agoI'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 agoI'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:.