11–20 of 82 posts
Seems very cool, but as far as I can tell there's no trial version? $80 seems a bit much to lay out before you even find out if the thing works.
One thing I would like to see is being able to export these vector graphics to other formats.
I love the execution of this app, but I disagree with the underlying idea for most cases. Drawing your UI is never ever going to be as cheap as loading a converted PNG (which Apple's modified pngcrush converts for you). I think a lot of devs have the draw/vector vs. precomposed bitmap tradeoff the wrong way round. Drawing all of your gradated UIButtons with CoreGraphics methods is a false economy compared to just loa…
This isn't about performance: it is about resolution independence.
The underlying idea of generating your images "programmatically" is not a bad one to start but performance wise, if the image (View) is going to be static, rendering into a bitmap and using that subsequently is the more performant solution.
Maybe the tool we are looking for is not one that generates UIViews but let's us just get the images correctly name and at the right resolutions with a click? Like automatic slicing and exporting at predefined resolutions with predefined naming schemes. I just think this would better be done off the device.
For interactive views (drag, move, ...), where redrawing is necessary, this could be a valuable tool -- if it can do that.
Seems very cool, but as far as I can tell there's no trial version? $80 seems a bit much to lay out before you even find out if the thing works.
True. A trial version would be very nice. One thing I would like to see is being able to export these vector graphics to other formats.
Seems very cool, but as far as I can tell there's no trial version? $80 seems a bit much to lay out before you even find out if the thing works.
True. A trial version would be very nice. One thing I would like to see is being able to export these vector graphics to other formats.
So basically we stop using graphics and start using code (UIViews) to draw the images. Does it do caching? A quick search for cache didn't turn up anything. If we have learned anything from using UITableViews with custom UITableViewCells then it is that drawing is expensive. The underlying idea of generating your images "programmatically" is not a bad one to start but performance wise, if the image (View) is going to…
Earlier quoted context omitted.
This isn't about performance: it is about resolution independence.
Yeah and this is becoming increasingly important. image.png, image@2x, image~ipad.png, image@2x~ipad.png...
"While some of the apps have received additional features, it seems likely that the increase in size is mainly down to the huge graphics needed to fill the new iPad's 2048 x 1536 Retina Display. It's worth remembering that these are only download sizes, and once installed the apps may be even larger. Regular apps will likely receive a similar bump in size once developers update them with hi-def graphics"
"iPad apps up to five times larger..."
One thing that I'm not totally sold on it that fact that it generates code though. It is not going to be the running application which you interactively tweak. Because that is what Bret was showing in his talk. And that is also what you would be doing in Smalltalk. I'm not sure this is as 'immediately connective' (to use a variant of Bret's language) as it seems.
Another approach to go about this would be to store the 'drawing' in a data structure and have a special view that takes it and puts it into an image (or on screen immediately). That would also open possibilities for caching, something that likely would be make sense, as other commenters have mentioned as well. Such an approach would come dangerously close to implementing/reinventing SVG, though. Another benefit of such a data structure would be that it could have some simple, textual representation. JSON maybe? Even XML would do. And that would greatly help with version control and diffing.
I don't see why such a feature could not be added to this app.
Amazing application.