intelligent preloading updates

_data/nav_docs.yml

@@ -34,7 +34,12 @@
   - multiplex-image-node
 - title: Layout
   items:
+  - automatic-layout-basics
   - automatic-layout-containers
+  - automatic-layout-examples
+  - background-layout-spec
+  - layout-options
+  - layout-engine
   - layout-api-debugging
   - layout-api-sizing
   - layout-transition-api

_docs/background-layout-spec.md

@@ -1,7 +0,0 @@
----
-title: ASBackgroundLayoutSpec
-layout: docs
-permalink: /docs/background-layout-spec.html
----
-
-<div class = "warning">😑 This page is coming soon...</div>

_docs/intelligent-preloading.md

@@ -6,7 +6,7 @@ prevPage: upgrading.html
 nextPage: containers-overview.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.
+While a node's ability to be rendered and measured asynchronously and concurrently makes it quite powerful, another crucially important layer to ASDK is the idea of intelligent preloading.
 
 As was pointed out in <a href = "getting-started.html">getting started</a>, 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.  
 
@@ -18,23 +18,38 @@ A node used outside of a container won't have its state updated by any range con
 
 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.
 
+<img src="/static/images/intelligent-preloading-ranges-with-names.png" width="35%">
+
 A node will be in one of following ranges: 
 
-<ul>
-	<li><strong>Fetch Data Range:</strong> 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.</li>
-	<li><strong>Display Range:</strong> Here, display tasks such as text rasterization and image decoding take place.</li>
-	<li><strong>Visible Range:</strong> The node is onscreen by at least one pixel.</li>
-</ul>
+<table style="width:100%" class = "paddingBetweenCols">
+  <tr>
+    <th>Interface State</th>
+    <th>Description</th> 
+  </tr>
+  <tr>
+    <td><b>Fetch Data</b></td>
+    <td>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.</td>
+  </tr>
+  <tr>
+    <td><b>Display</b></td>
+    <td>Here, display tasks such as text rasterization and image decoding take place.</td>
+  </tr>
+  <tr>
+    <td><b>Visible</b></td>
+    <td>The node is onscreen by at least one pixel.</td>
+  </tr>
+</table>
 
 ## 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.
 
-<img src="/static/images/intelligent-preloading.png">
+<img src="/static/images/intelligent-preloading-ranges-screenfuls.png" width="45%">
 
-In the above visualization of the Pinterest home feed, the user is scrolling down.  As you can see, the sizes of the ranges in the leading direction are quite a bit larger than the content the user is moving away from (the trailing direction).  If the user were to change directions, the leading and trailing sides would dynamically swap in order to keep memory usage optimal.  This allows you to worry about defining the leading and trailing sizes without having to worry about reacting to the changing scroll directions of your user. 
+In the above visualization of a scrolling collection, the user is scrolling down.  As you can see, the sizes of the ranges in the leading direction are quite a bit larger than the content the user is moving away from (the trailing direction).  If the user were to change directions, the leading and trailing sides would dynamically swap in order to keep memory usage optimal.  This allows you to worry about defining the leading and trailing sizes without having to worry about reacting to the changing scroll directions of your user. 
 
-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. 
+Intelligent preloading also works in multiple dimensions. 
 
 ## Interface State Callbacks
 
@@ -44,11 +59,9 @@ As a user scrolls, nodes move through the ranges and react appropriately by load
 `- (void)visibilityDidChange:(BOOL)isVisible;`
 
 ### Display Range
-`- (void)displayWillStart`<br/>
-`- (void)displayDidFinish`<br/>
+`- (void)displayStateDidChange:(BOOL)inDisplayState;`
 
 ### Fetch Data Range
-`- (void)fetchData`<br/>
-`- (void)clearFetchedData`<br/>
+`- (void)loadStateDidChange:(BOOL)inLoadState;`
 
 Just remember to call super ok? 😉