- I tried to make these tests work with OCMock, but that only ever saw 1 call.
- All these do is count `-reloadData` calls. I'm not sure why so many other methods are recorded.
- Why we are doing this is the library targets iOS 5 and is flagged as a warning in builds.
- The issues in #1038 are not explained.
- In `ASCollectionViewTests` do not mock every `collectionViewLayout`, only do it for the test that requires it. In addition, call `-stopMocking` when done. OCMock 3.6 found this code using stuff after it should have been.
- 5c42bb4e2f says the layer tests are not typically run, but they are in the project. That diff refers to ASUIViewTests being skipped, but those tests do not exist. So I've just disabled them in this diff. It is not clear how they ever worked.
* [ASDisplayViewAccessibility] A few accessibility improvements
This diff includes a few improvements for accessibility in Texture.
* When determining a node’s accessibility elements, ignore any elements that are hidden, transparent, or out of the window. This matches UIKit’s behavior.
* When sorting the accessible elements and their origins are equal, give precedence to elements with shorter accessibility frames, followed by elements with narrower widths.
* Allow the ability to customize the comparator block that sorts the accessibility elements
* Create an experiment to stop caching accessibilityElements in `_ASDisplayView`. If we cache elements, we will require users to clear the cache (by calling `setAccessibilityElements` to get the side effect of clearing the cache) when nodes change their hidden state or opacity. This seems like a lot to request of the user. We will put this in an experiment so we can see the perf implication is both when using voice over and when not using voice over.
A few other notes:
* I got rid of the `ASAccessibilityElementPositioning` protocol in favor of passing `NSObjects` to the sort comparator. `NSObject` implements the informal `UIAccessibilityProtocol` and therefore has an `accessibilityFrame` property.
* I removed `static` from the `SortAccessibilityElements()` method definition. This allows me to declare it as `extern` in test it via unit tests.
Right now when an image node enters preload state, we kick off an image request with the default priority. Then when it enters display state, we change the priority to "imminent" which is mapped to the default priority as well. This means that requests from preload and display nodes have the same priority and are put to the same pool. The right behavior would be that preload requests should have a lower priority from the beginning.
Another problem is that, due to the execution order of -didEnter(Preload|Display|Visible)State calls, a node may kick off a low priority request when it enters preload state even though it knows that it's also visible. By the time -didEnterVisibleState is called, the low priority request may have already been consumed and the download/data task won't pick up the new higher priority, or some work needs to be done to move it to another queue. A better behavior would be to always use the current interface state to determine the priority. This means that visible nodes will kick off high priority requests as soon as -didEnterPreloadState is called.
The last (and smaller) issue is that a node marks its request as preload/low priority as soon as it exits visible state. I'd argue that this is too agressive. It may be reasonble for nodes in the trailing direction. Even so, we already handle this case by (almost always) have smaller trailing buffers. So this diff makes sure that nodes that exited visible state will have imminent/default priority if they remain in the display range.
All of these new behaviors are wrapped in an experiment and will be tested carefully before being rolled out.
* Add imports
* Fix build failure
* Encapsulate common logics into methods
* Address comments
ASImageNode and ASHighlightOverlayLayer were both using
[[UIScreen mainScreen] scale] directly. Bad. No cookie. Use
ASDisplayNodeScreenScale() instead.
(Also, regenerate Xcode project with Xcode 6 and current CocoaPods.)