[TIMOB-24195] iOS: currentPage & views properties of Ti.UI.ScrollableView doesn't change after removing a view
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2017-05-21T16:05:36.000+0000 |
Affected Version/s | Release 6.0.0, Release 5.5.0 |
Fix Version/s | n/a |
Components | iOS |
Labels | ios, kroll-thread |
Reporter | Prashant Saini |
Assignee | Hans Knöchel |
Created | 2016-12-05T11:29:37.000+0000 |
Updated | 2018-08-02T22:20:09.000+0000 |
Description
Whenever we remove a view from ScrollableView, *currentPage* and *views* properties do not change immediately. It happens in different cases but not all.
*Javascript Test-Case:*
var win = Ti.UI.createWindow({
backgroundColor: '#fff',
title: 'ScrollableView Test'
});
var nav = Ti.UI.iOS.createNavigationWindow({
window: win
});
var scrollable = Ti.UI.createScrollableView({
views: [
Ti.UI.createView({top: 50, bottom: 50, left: 10, right: 10, backgroundColor: 'red'}),
Ti.UI.createView({top: 50, bottom: 50, left: 10, right: 10, backgroundColor: 'teal'}),
Ti.UI.createView({top: 50, bottom: 50, left: 10, right: 10, backgroundColor: 'cyan'}),
Ti.UI.createView({top: 50, bottom: 50, left: 10, right: 10, backgroundColor: 'pink'}),
]
});
var btn = Ti.UI.createButton({
title: 'Remove view with index 1'
});
btn.addEventListener('click', function() {
Ti.API.info('\nCurrent Page = ' + scrollable.currentPage);
scrollable.removeView(1);
Ti.API.info('Current Page = ' + scrollable.currentPage);
setTimeout(function () {
Ti.API.info('Current Page = ' + scrollable.currentPage);
}, 500);
});
win.add(scrollable);
win.setRightNavButton(btn);
nav.open();
*Alloy Test-Case:*
<Alloy>
<Window backgroundColor="black">
<ScrollableView id="SCROLLABLE_VIEW">
<View backgroundColor="red" top="50" bottom="50" left="10" right="10"><Button>All Good 0</Button></View>
<View backgroundColor="teal" top="50" bottom="50" left="10" right="10"><Button>All Good 1</Button></View>
<View backgroundColor="cyan" top="50" bottom="50" left="10" right="10"><Button>All Good 2</Button></View>
<View backgroundColor="pink" top="50" bottom="50" left="10" right="10"><Button>All Good 3</Button></View>
</ScrollableView>
<Button bottom="10" color="white" onClick="remove">REMOVE PAGE</Button>
</Window>
</Alloy>
function remove() {
Ti.API.info('\nCurrent Page = ' + $.SCROLLABLE_VIEW.currentPage);
$.SCROLLABLE_VIEW.removeView(1);
Ti.API.info('Current Page = ' + $.SCROLLABLE_VIEW.currentPage);
setTimeout(function () {
Ti.API.info('Current Page = ' + $.SCROLLABLE_VIEW.currentPage);
}, 500);
}
To get the bug output, click on the button after swiping to last page (index 3). This output will be shown then:
[INFO] : Current Page = 3
[INFO] : Current Page = 3
[INFO] : Current Page = 2
Hey [~prashant_saini_1], I can reproduce this issue, but only when the
run-on-main-thread
property is not set (or set tofalse
) in the tiapp.xml. It's the recommended way for all apps since 5.4.0 and should be considered over using the legacy (kroll-thread) threading. You can enable it by pasting the following in the top-level tiapp.xml:We will still look into the issue of course, but the above is the recommended way for the future.
Thanks @hansknoechel, can you please confirm that will it work properly by setting run-on-main-thread to false as well, or do we have to set it to true only?
Please read my comment carefully, I just updated it to be more clear. If you don't have the property or have it set to false, it won't work as (of course) the effect is the same then. The reason for this is that the kroll-thread doesn't wait for the removal to be finished, but the main-thread does. So we'd either need to make the method asynchronous (which is no good solution) or lock the execution until all removal-operations are finished.
Thanks again, but I do not want to use or set the property to true because there can be some weird issues in other sections of the app. I have no issue in setting this property to true, but only if it provides complete working of other codes as well. So what could be best use case of setting main thread to true apart from using Hyperloop module?
Hey Prashant, sorry for taking so long to come back to you. I would like to answer your main-thread question more detailed: So if have issues with run-on-main-thread, you should definitely report them. Many had the issue that child events didn't fire, which is fixed on 6.1.0 (try the RC version released last week). If it's something different, please file a JIRA for it, since it will become the default in the next major version for sure. The big advantage is that is guarantees that *UI operations* are executed on the main-thread, which is the way that Apple requires it. Previously (and this ticket is a great example for it), the kroll-thread may handle the execution, leading to weird race conditions that result in this behavior. Things like HTTP-requests or geolocation-fetches are still made on it's own thread to not block your UI, so you should already see a performance increase when activating it. And again: If not, please file a ticket to describe your issue. I hope that this will enlighten the main-thread mysts a bit. Maybe we should have called it "run-ui-on-main-thread" to be more specific. Thanks!
Closing old "Won't fix" tickets. If you disagree, please reopen.