[TIMOB-25820] postlayout on TableViewRow doesn't work on iOS
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Resolved |
| Resolution | Won't Fix |
| Resolution Date | 2018-08-09T08:25:00.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | n/a |
| Labels | n/a |
| Reporter | ILAY SENER |
| Assignee | Hans Knöchel |
| Created | 2018-02-28T03:37:19.000+0000 |
| Updated | 2018-08-09T08:25:00.000+0000 |
Description
postlayout event doesn't trigger when used on TableViewRow.
To replicate, create a new Alloy MObile Project.
Replace index.xml contents with below:
Index.xml
Replace index.js contents with below:
$.win.open();
function test1() {
alert("hello");
}
$.tvr.addEventListener("postlayout", test1);
function test2() {
alert("clicked");
}
You can see the click event is working, but not the postlayout.
This might be the expected behavior on iOS because of the following background. The underlaying
UITableViewdoes not render it's cells like usual views (UIViewsubclasses). Instead of finishing a layout by having a view on-screen, table-view cells (both for Ti.UI.ListView and Ti.UI.TableView - they use the same native API internally) are rendered off-screen and are presented to the user once they reach the visible area of the scroll-interaction. After "scrolling them away", either up or down, the cells are being destructed again. This is done to ensure the best scrolling-performance across that native API and is decided by the iOS system itself. Now when it comes to thepostlayoutevent, it is usually called on "normal" views when they finished layouting on the screen, e.g. they have reached their final rect (width / height) and origin (x- / y-position). For table-view-rows, they are always embedded in the vertical stack of cells inside theUITableViewor their section, so they won't fire because of that. They also do not fire when their sub-views are ready, because that goes under the rendering-pipeline as discussed above, which "finishes" layouting even before you know that you will use that cell (by using the scroll-direction to determine and prepare the next cells to present). That's the long story behind why it does not fire. We *could* make it fire by manually firing the event at some point of the layouting-pipeline, but that's really against what this API is meant for and it should be considered as a native limitation. For sure, we should update the docs to reflect this behavior. I'd love your feedback [~isener]!