Apple renderer: a virtualising container, so LazyColumn stops mounting every row #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
docs/12records this as the worst of the current gaps, because it works in the demo and dies in an app:AppleRendererdoes not overridesupportsVirtualRows, so it inheritsfalseandLazyColumnfalls back to mounting every row. On the 10 000-row screen that is 30 000 widgets on the main thread of a phone.GTK and Android both implement it and the contract needed no changes for either, so
RowSource[Handle]is already proven as an abstraction rather than a description of Android.What to do
override def supportsVirtualRows: Boolean = true.createVirtualList(source: RowSource[Handle]):NSTableView(view-based, one column,makeView(withIdentifier:)for recycling) on AppKit;UITableViewwithdequeueReusableCellon UIKit.GtkSignalListItemFactorybind callback has: a trampoline that calls back into Scala with the row index and the recycled handle, andRowSource.onInvalidatewired toreloadData.RowSource.bindreturns the row's root handle. Rows must have a single root widget — aFragmentrow is rejected with a message saying so, exactly as the other two renderers do; do not mount something the table cannot place.How to verify.
TodoApp.Route.Bigis the 10 000-row screen and the shared self-test already pushes it. Add the check the other two have: after pushing, count materialised rows and assert it is bounded. Android reports ~66, GTK ~205. Record the Apple number in the report — a number, not "works".See
docs/12-component-status.md§12.3 and §12.5.