GitHub Issue | n/a |
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2013-04-09T19:42:37.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 3.1.0, 2013 Sprint 08 Core, 2013 Sprint 08, Release 3.2.0 |
Components | iOS |
Labels | ios, listview, listviewitem, qe-closed-3.1.0, qe-testadded, release-note, triage |
Reporter | Carter Lathrop |
Assignee | Max Stepanov |
Created | 2013-04-09T04:01:32.000+0000 |
Updated | 2014-12-01T02:39:14.000+0000 |
*Problem*
When selecting a row and navigating to the next screen then tapping back to the window with the listview the selected row is still selected. Apple will reject apps with this behavior.
*Expected Behavior*
The listview should be deselected when returning to the window.
*Requested Feature*
This control also needs to a method to support deselectItem
*Steps to Reproduce*
1. Copy and paste code provided below into app.js
2. Run on 3.1.xx or higher on iOS
3. Click "Open ListView Tests" button
4. Click "Basic" ListViewRow
5. Click on any row
6. Click back nav button
7. Notice "Basic" is still selected
var rootWin;
var isAndroid = Ti.Platform.osname == 'android';
function createAndroidNavGroup() {
return {
open : function(openWin, props) {
openWin.fullscreen = true;
openWin.backgroundColor = 'blue';
openWin.open();
}
}
}
var navGroup = isAndroid ? createAndroidNavGroup() : Ti.UI.iPhone.createNavigationGroup({
window : rootWin = Ti.UI.createWindow()
});
var button = Ti.UI.createButton({
title: 'Open ListView Tests'
});
button.addEventListener('click', function() {
openTestsWindow();
});
var label = Ti.UI.createLabel({
text: "Return to this screen to check for memory leaks.\nEnsure garbage collection by doing 'Simulate Memory Warning'",
left: 5,
color: 'red',
bottom: 20
});
if (isAndroid) {
var navWin = Ti.UI.createWindow({ backgroundColor: 'white' });
navWin.add(button);
navWin.add(label);
} else {
rootWin.add(button);
rootWin.add(label);
var navWin = Ti.UI.createWindow();
navWin.add(navGroup);
}
navWin.open();
function openTestsWindow() {
var win = Ti.UI.createWindow({
title : 'ListView Tests'
});
var listView = Ti.UI.createListView();
var section = Ti.UI.createListSection({
headerTitle : 'Items'
});
section.setItems([{
properties : {
title : 'Basic',
itemId : 'basic',
accessoryType : Ti.UI.LIST_ACCESSORY_TYPE_DISCLOSURE
}
}]);
listView.appendSection(section);
listView.addEventListener('itemclick', function(e) {
var f = tests[e.itemId];
if (f)
f();
});
win.add(listView);
navGroup.open(win, {
animated : true
});
}
var tests = {};
tests.basic = function() {
var win = Ti.UI.createWindow({
title : 'Basic'
});
var section = Ti.UI.createListSection();
var items = [];
for (var i = 0; i < 1000; ++i) {
items.push({
properties : {
title : 'Item ' + i
}
});
}
section.setItems(items);
var listView = Ti.UI.createListView({
sections : [section]
});
win.add(listView);
navGroup.open(win, {
animated : true
});
}
Darren, In order for a bug to be reviewed, we need to see a test case that explicitly shows the issue. By this I mean a simple piece of code that can be copy and pasted into an app.js that shows the problem. Please refer to: https://wiki.appcelerator.org/display/guides/How+to+Submit+a+Bug+Report on how to write an acceptable bug report. Thanks, Carter
I have added a simple test case and screenshot showing the row still selected after navigating back to the list view.
@Darren, confirmed bug. I have moved along to engineering. Please keep a watch on this for the fix. Thank you for bringing this to our attention. Regards, Carter
PR https://github.com/appcelerator/titanium_mobile/pull/4132 3_1_X PR https://github.com/appcelerator/titanium_mobile/pull/4133
Merged
Verified fixed in simulator and on device: Mac OS 10.8.3 Xcode 4.6 CLI: 3.1.0-cr Alloy: 1.1.0-cr Appcelerator Studio, build: 3.1.0.201304082106 Titanium SDK version 3.1.0.v20130409124549 iPhone 5 6.0
The selection of the cell item seems to be ok. Unfortunately, the cell stays selected until the opened window is closed (in contrast to the older API, where the selection was blured when opening the window). Combined with this problem, after closing a window, the color of the rows stays default and not reacts to the highlightedColor property, although it is set. Should i wrap it up in a single entry?
I am getting an error trying the deselect function. My app has a custom navigation using views appears to not call the will show function. Was this function not exposed?? [ERROR] : message = "'undefined' is not a function (evaluating 'listView.deselectAll(false)')"; [ERROR] : name = TypeError; [ERROR] : sourceId = 233103680;
deselectAll is not exposed to the JS side. Private API
Shouldn't the ListItems be deselected by default when receiving a click event? The native UITableView-API does that and the "old" Ti.UI.TableView as well.
Agree with Hans. I open an optionDialog on click instead of a child window, in this case the row always stays selected. So in TiUIListView.m I have added:
Any update on deselecting ListItems? Thanks.
[~mokesmokes] DeselectItem was implemented as part of TIMOB-13417
I just copied and pasted the "List View Sections" example from [Titanium.UI.ListView](http://docs.appcelerator.com/titanium/latest/#!/api/Titanium.UI.ListView), the deselectItem bug is not fixed in 3.2.0. [http://i.imgur.com/csxk2uj.png]
And this is a screenshot of the sample in this ticket: [screenshot](http://i.imgur.com/HWXv9Pq.png)
I can confirm that this worked fine in 3.1.2GA but stopped working properly in 3.1.3GA. A fix would be greatly appreciated...
Hi All, I am facing the similar issue. I have posted my question on forum.http://developer.appcelerator.com/question/174326/listview-background-color Please look into that and help me to sort out this. Thanks in advance.
Hi All, When i use , myList.addEventListener('itemclick', function(e){ myList.deselectItem(e.sectionIndex, e.itemIndex); }); It's working fine on iOS. But Android giving the error of "deselect is not a method" . Is there any solutions.?
I have Coded for separate os by checking the Ti.Platform.osname. And for android deselectItem is no need. Because already its looks like deselecteditem. Thanks
What's the latest on this fix? The stopgap solution is a bit slower than desired...