Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-16873] iOS: Switch Controls in ListViews are not reused correctly

GitHub Issuen/a
TypeBug
PriorityLow
StatusClosed
ResolutionInvalid
Resolution Date2014-04-23T17:50:57.000+0000
Affected Version/sRelease 3.2.2
Fix Version/sn/a
ComponentsiOS
LabelsListItem, ListView, Switch, ipass1
ReporterMahlon Gumbs
AssigneeIngo Muschenetz
Created2014-04-21T16:12:19.000+0000
Updated2018-08-06T17:37:03.000+0000

Description

When using Switches in ListViews that contain a large enough number of records so that the user must scroll (I'm using 40 in this test), the Switch components are not reused correctly. In the attached test, you can see that tapping the switch in the first row will cause it to change in other rows as those rows are later rendered (and the switch components are reused).

Steps to reproduce

Create an app with the following files:


var items = [];
for(var x=0;x<40;x++){
	items.push({
		template: "tpl1",
		lbl: {
			text: "Switch #" + (x+1)
		},
		done: {
			itemId: "sw_"+x,
			value: false
		}
	});
}
$.main.setItems(items);

$.index.open();

function handleChange(e){
	console.log(JSON.stringify(e,null,2));
}
<Alloy>
	<Window class="container">
		<ListView id="list" defaultTemplate="tpl1">
			<Templates>
				<ItemTemplate name="tpl1">
					<View width="Ti.UI.FILL" height="50">
						<Label bindId="lbl" left="5" />
						<Switch bindId="done" right="5" onChange="handleChange"/>
					</View>
				</ItemTemplate>
			</Templates>
			<ListSection id="main" />
		</ListView>
	</Window>
</Alloy>
".container": {
	top: 40,
	backgroundColor:"white"
}

Run the app and click on the first switch in the list

Scroll down and look at the other switches (need to at least scroll past the last record on the first page)

Expected Results

Only the switch that was tapped should change.

Actual Results

Other switch components are changed as well after scrolling.

Additional Info

Sometimes, scrolling back to the top will show that the wrong switch is modified (depending on the size of your list). I've also been able to reproduce this with text fields if they all start out with the same value or and empty string (""). Seems the reuse issue is somehow related to the initial value of the editable component. In this example, all switches start out in the false ( off ) state.

Comments

  1. Ritu Agrawal 2014-04-23

    Moving this ticket to engineering as I can reproduce this issue with the provided test case. Note that this ticket is similar to TIMOB-13290 but that is on the Table View.
  2. Mahlon Gumbs 2014-04-23

    A couple of updates:

    I've verified the issue exists on Android as well (not iOS specific)

    It looks like it's all input components that are affected, not just Ti.UI.Switch (same test case replacing Ti.UI.Switch with Ti.UI.TextField produces the same issue). So maybe the ticket should be renamed to *Input Controls in ListViews are not reused correctly*

  3. Pedro Enrique 2014-04-23

    Resolving issue as invalid. As you an see in this example, the rows _are_ being reused, that's why changing the value on a switch affect others - they're the same row being reused. Solution (note that this is the way you would also do it in native) keep track of your changes and update as necessary:
       function handleChange(e){
           // Get the current "row"
           var item = e.section.getItemAt(e.itemIndex);
           // Update the switch value
           item.done.value = e.value;
           // Update the section with the new change
           e.section.updateItemAt(e.itemIndex, item);
       }
       
  4. Olga Romero 2014-04-24

    Testing the original provided code, I reproduce the issue with: Appcelerator Studio, build: 3.3.0.201404221437 Titanium SDK, build 3.3.0.v20140422163054 Node.JS Version: v0.10.13 NPM Version: 1.3.2 ├── acs@1.0.14 ├── alloy@1.4.0-dev ├── node-appc@0.2.0 ├── npm@1.3.2 ├── titanium@3.3.0-dev └── titanium-code-processor@1.1.1-beta1 npm -g ls titanium: /usr/local/lib └── titanium@3.3.0-dev (git://github.com/appcelerator/titanium.git#93414d143051df4578b7aa42670008e5ef02c422) XCode Version: 5.1.1 Device: iPhone5S iOS 7.0 I can reproduce it with the reported environment as well.
  5. Eric Merriman 2018-08-06

    Closing as invalid. If incorrect, please reopen.

JSON Source