7215548d77
updated description of image. @lappp9 - do you know how to embed a video? I have a demo of the range controller visualizations in action.
3.3 KiB
Executable File
title, layout, permalink, next
| title | layout | permalink | next |
|---|---|---|---|
| Intelligent Preloading | docs | /docs/intelligent-preloading.html | subclassing.html |
While a node's ability to be rendered and measured asynchronously makes it quite powerful, another crucially important layer to ASDK is the idea of intelligent preloading.
As was pointed out in getting started, it is rarely advantageous to use a node outside of the context of one of the node containers. This is due to the fact that all nodes have a notion of their current interface state.
This interfaceState property is constantly updated by an ASRangeController which all containers create and maintain internally.
A node used outside of a container won't have its state updated by any range controller. This sometimes results in a flash as nodes are rendered after realizing they're already onscreen without any warning.
Interface State Ranges
When nodes are added to a scrolling or paging interface they are typically in one of the following ranges. This means that as the scrolling view is scrolled, their interface states will be updated as they move through them.
A node will be in one of following ranges:
- Fetch Data Range: The furthest range out from being visible. This is where content is gathered from an external source, whether that’s some API or a local disk.
- Display Range: Here, display tasks such as text rasterization and image decoding take place.
- Visible Range: The node is onscreen by at least one pixel.
ASRangeTuningParameters
The size of each of these ranges is measured in "screenfuls". While the default sizes will work well for many use cases, they can be tweaked quite easily by setting the tuning parameters for range type on your scrolling node.
As you can see from the above visualization of the Pinterest home feed scrolling through the ranges, the leading and trailing sizes of each range will dynamically change direction based on the direction the user is scrolling. This allows you to worry about leading and trailing sizes alone without having to worry about reacting to changing scroll directions of your user.
In this example, the user is scrolling down, so the leading (towards bottom of image direction) Fetch Data Range (yellow) and Display Range (orange) are larger than the trailing (towards top of image direction) ranges. In this example, you can also see how intelligent preloading works in multiple dimensions. In the middle of the Pinterest Home Feed, you can see a horizontal scrolling element with drum pictures. These feed isn't yet visible on the device screen (red), but it has it's own range controller that has nodes in the Fetch Data (yellow) and Display (orange) ranges.
Interface State Callbacks
As a user scrolls, nodes move through the ranges and react appropriately by loading data, rendering, etc. Your own node subclasses can easily tap into this mechanism by implementing the corresponding callback methods.
Visible Range
- (void)visibilityDidChange:(BOOL)isVisible;
Display Range
- (void)displayWillStart
- (void)displayDidFinish
Fetch Data Range
- (void)fetchData
- (void)clearFetchedData
Just remember to call super ok? 😉