Introduces ASLayoutRangeModeVisibleOnly, allowing the preservation of decoded backing stores without any extra padding to
strictly minimize memory usage while supporting immediate re-display of content. Set visible range controllers to this mode
upon app suspend / memory warning, while more aggressively clearing others to the ASLayoutRangeModeLowMemory mode.
By default, when the app is running and recieves a memory warning, we set the range mode for non-visible controllers to
ASLayoutRangeModeVisibleOnly. This is because, unlike in the app suspend case where on app resume we can restore controllers
from LowMemory to VisibleOnly, the memory warning doesn't provide a good opportunity to do this.
A new +Beta API to control this behavior is called +setRangeModeForMemoryWarnings:, as some apps may prefer to use LowMemory
in the memory warning scenario. For these apps, optimal user experience will require manually setting the range mode back
to some larger value as the user navigates the app, or they will encounter controllers that are temporarily blank and need
a moment to re-display their contents as they start to become visible.
The optimization seems correct now, but apps like Pinterest have some core code relying on edit operation
order that is actually not permitted by UIKit (and this diff) but were tolerated previously. We will
re-land this once we have time to adapt the code.
This diff resolves all known consistency issues with ASTableView and ASCollectionView.
It includes significantly more aggressive thrash-testing in ASTableViewStressTest,
which now passes on a variety of device and simulator configurations. It also updates
the unit tests run on every commit to ensure any regression is caught quickly.
A few of the salient changes in this diff:
- ASTableView now uses Rene's ASCollectionViewLayoutController, and actually uses a
UICollectionViewFlowLayout without any UICollectionView. This resolves an issue where
ASFlowLayoutController was generating slightly out-of-bounds indicies when programmatically
scrolling past the end of the table content. Because the custom implementation is likely
faster, I will revisit this later with profiling and possibly returning to the custom impl.
- There is now a second copy of the _nodes array maintained by ASDataController. It shares
the same node instances, but this does add some overhead to manipulating the arrays. I've
filed a task to follow up with optimization, as there are several great opportunities to
make it faster. However, I don't believe the overhead is a significant issue, and it does
guarantee correctness in even the toughest app usage scenarios.
- ASDataController no longer supports calling its delegate /before/ edit operations. No
other class was relying on this behavior, and it would be unusual for an app developer to
use ASDataController directly. However, it is possible that someone with a custom view
that integrates with ASDataController and ASRangeController could be affected by this.
- Further cleanup of organization, naming, additional comments, reduced code length
wherever possible. Overall, significantly more accessible to a new reader.
This applies primarily when beginUpdates / endUpdates is not used.
Due to user interaction-driven edits, like reloads or adding content
at the bottom, sometimes this is unavoidable in app design and thus
critical.
I have a diff in flight to make ASDataController / ASRangeController
robust against very aggressive thrash testing, which will be added
both to the unit test suite and this new example project.
Most UITableViewCell properties aren't useful in conjunction with
ASCellNode -- the system's UIView properties are unsupported for
performance reasons, and properties that configure them (e.g., content
indentation) don't affect custom node hierarchies. This patch adds
support to _ASTableViewCell for the properties that *are* useful.
r=scottg
(1) We can't size nodes without a delegate, and if our owning controller
has been deallocated, our delegate will be nil. Handle this more
gracefully.
(2) Our teardown code needs to be executed on the main thread, but it's
conceivable that we might hit refcount 0 on a background queue. Force
deallocation to occur on the main thread.
Closes#27.
