I have no desire to layout everything in code (I know some people like this, I don't) so it's not very interesting to me. It would seem to require you to write your app in a completely different way. I wonder what debugging would be like with it, given that threaded code is always more painful. It might be more interesting once people release actual apps with it (outside of FB).
Most iOS UI at Google is laid out in code as well.
It makes it much easier to review code, see diffs, and have multiple people working on the same part of the app without causing crazy merge conflicts.
Yeah. I acknowledged that storyboard is easier and faster for simple to moderate UI, but merging using git/vcs is horrible. Plus, it's difficult to build cool animations with those.
The flip side of something like this is that it creates a "floaty" feeling, due to delaying UI update for several runloop passes (jumping from one queue to another). Sometimes this is more acceptable but often it is not. If you played with Paper, and felt it was "floaty", now you know why. If it didn't bother you, I guess you are less sensitive to this. Not to say this library is useless, like most things, when not abused, good can come from it.
Curious to better understand what you mean—in my experience, this is not true at all. All touches / gesture handling are direct manipulation with no delays at all. All the asynchronously-prepared content is rendered in advance with a large offscreen buffer, so in general it should be done rendering before it's onscreen. In the cases where you scroll really fast and get to something that hasn't finished rendering, the alternative in a regular app architecture is to simply stutter (block the UI) until it's done rendering.
This framework can be used in very flexible ways, such as "try to render everything offscreen, but if it's going to come onscreen and hasn't finished yet, block and wait for it to be done". Even that approach will result in a much more responsive feel while ensuring that you have the same guarantees as a synchronous UI about content being finished rendering when it is visible.
You can use autolayout (see my NSLondon talk, which discusses this in the Q&A). However, there's no way to make autolayout run asynchronously, so you won't be able to reduce main thread stalls caused by autolayout-driven calculations.
Seriously, is autolayout actually used by a lot of people? I tried doing something semi-complex a few weeks back and I spent hours fighting with it. Then I spent 10 minutes writing 10 lines of code and it worked.
When you finally grok it, does it become worth it?
Once you "get" doing AutoLayout you will never want to go back. I'm speaking as a guy who swore up and down to frames. All it takes is doing some adaptive stuff for 3.5, 4, 4.7 and 5.5 inch screens to make you want to jump out your window.
By the time you create a good system to get the frames to work with an adaptive layout, you just implemented a poor man's version of AutoLayout.
Just my $0.02. I think it saves me a lot of time. I try to avoid AutoLayout in IB and just use code, either a third party DSL or apple's own visual format language.
It's actually easier depending on the animation you want to do. You can set an NSLayoutConstraint to an IBOutlet and then change it's constant in an animation block.
You just have to store the constraint in your VC or custom view. You still need to use frames sometimes though. I have found that scrollviews and AutoLayout are arch-nemesises.
I recently learned and used Autolayout to design a few different apps. It has its pros and cons. For relatively simple UIs, it's great, especially if you use Interface Builder. It really lets you express what you mean when you lay something out, and it automatically works with all screen sizes. On the other hand, if you're doing anything that requires lots of little views laid out in an orderly way — a keyboard, for instance — it's more trouble than it's worth.
I think for Autolayout to have more general appeal, it needs two things. One, an easier way to use it programmatically. (Creating NSLayoutConstraints all the time is annoying.) And two, a better way to define equal spacing between views. (Creating spacer views is incredibly boilerplate-y.)
Also, the more constraints you have, the harder it gets to conceptualize things like intrinsic contents sizes, priorities, and inequalities.
Have you tried Masonry? It might be right for you if you want easier programatic use than NSLayoutConstraints provide. https://github.com/Masonry/Masonry
Of course it does. I admit it can take a few long to get used to it, but once you do, turns out to be kind of a mechanical process that saves you a lot of time. Above all, when combined with the interface builder. I'm quite sure those 10 min. wouldn't have been more than just 5 using IB + AL.
Well, it's certainly encouraged by Apple, and it's getting to the point where they aren't interested that "supporting all these sizes without using AutoLayout is hard."
You can perform manual layout in the layoutSubviews method of any UIView. Simply calculate your positions with the current view size in mind, looking up the Size Class if necessary. (And don't use exact pixel positions, obviously.)
It's really neat to see facebook's iOS team releasing so much of their work. This framework is probably not going to be that relevant to tons of use-cases, but even if you'll never use it you'll probably get a lot out of looking at it closely and thinking about why it makes the decisions it does.
On Safari, the entire site seems to have no content and just re-directs to itself in a loop over and over: meta http-equiv="refresh" content="0; http://asyncdisplaykit.org"
Very cool! This bears quite a resemblance to the way React.js constructs a virtual DOM so that it can optimize drawing. Do you guys have a way you're benchmarking performance improvements? Are you just looking at time spent on the main thread?
Yes, there is a broad similarity: abstracting away from performance or threading limitations of common UI building blocks. However, React has a declarative, single-directional data flow model. AsyncDisplayKit is imperative.
Declarative code is great for a lot of things, but interactivity and animations are definitely not one of them. Also, ASDisplayNode was designed to be as similar as possible to UIView (also imperative).
We don't have a benchmark suite, largely because it is so easy to use Instruments to do CPU traces and look for any chunks of main thread work that threaten frame drops.
