{
	"id": "174499",
	"key": "ALOY-1712",
	"fields": {
		"issuetype": {
			"id": "1",
			"description": "A problem which impairs or prevents the functions of the product.",
			"name": "Bug",
			"subtask": false
		},
		"project": {
			"id": "11113",
			"key": "ALOY",
			"name": "Alloy",
			"projectCategory": {
				"id": "10400",
				"description": "Tools for developing applications",
				"name": "Tooling"
			}
		},
		"fixVersions": [],
		"resolution": null,
		"resolutiondate": null,
		"created": "2019-12-01T05:04:07.000+0000",
		"priority": {
			"name": "None",
			"id": "6"
		},
		"labels": [
			"alloy",
			"griffin-app",
			"listview"
		],
		"versions": [],
		"issuelinks": [],
		"assignee": {
			"name": "batman",
			"key": "batman",
			"displayName": "Bruce Wayne",
			"active": true,
			"timeZone": "America/New_York"
		},
		"updated": "2020-01-28T19:03:25.000+0000",
		"status": {
			"description": "The issue is open and ready for the assignee to start work on it.",
			"name": "Open",
			"id": "1",
			"statusCategory": {
				"id": 2,
				"key": "new",
				"colorName": "blue-gray",
				"name": "To Do"
			}
		},
		"components": [
			{
				"id": "12332",
				"name": "Titanium SDK",
				"description": "Any integration or issues with the TiSDK"
			}
		],
		"description": "If you have a ListView with an ImageView that uses a remote image url, it will load once the screen is visible but if you scroll down and back up, the default image is shown and the image is reloaded again.  I have monitored this with Charles and have confirmed that it is repeatedly calling out to the remote server for the urls.\r\n\r\nI have tried to get around this by creating my own ImageView but adding the module attribute to the Alloy tag and/or to the ImageView tag does nothing to controls that are in the ListView Templates.  ",
		"attachment": [],
		"flagged": false,
		"summary": "ImageViews constantly reloading while scrolling in ListView templates",
		"creator": {
			"name": "bhouse",
			"key": "bhouse",
			"displayName": "Brenton House",
			"active": true,
			"timeZone": "America/Chicago"
		},
		"subtasks": [],
		"reporter": {
			"name": "bhouse",
			"key": "bhouse",
			"displayName": "Brenton House",
			"active": true,
			"timeZone": "America/Chicago"
		},
		"environment": "iOS 13.2 Simulator\r\nTitanium SDK 1.3.0.GA\r\nMacOS 10.15.1\r\n",
		"comment": {
			"comments": [
				{
					"id": "452958",
					"author": {
						"name": "eharris",
						"key": "eharris",
						"displayName": "Ewan Harris",
						"active": true,
						"timeZone": "Europe/Dublin"
					},
					"body": "[~bhouse] any code we can use to reproduce this? This also maybe seems like something at the SDK level rather than Alloy itself?",
					"updateAuthor": {
						"name": "eharris",
						"key": "eharris",
						"displayName": "Ewan Harris",
						"active": true,
						"timeZone": "Europe/Dublin"
					},
					"created": "2019-12-02T10:19:13.000+0000",
					"updated": "2019-12-02T10:19:13.000+0000"
				},
				{
					"id": "452975",
					"author": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "This is the expected behavior for ListView.\r\n\r\nListView will only load the views that are shown on-screen and rows scrolled off-screen will have their views *recycled*/*re-used* by the rows scrolled on-screen. Meaning the ImageView that was scrolled-off will be re-used by the rows scrolled-in to display a different image. This behavior is intentional because a ListView is designed to handle thousands of rows where there isn't enough memory to load all contents.\r\n\r\nThe images will typically load faster if they're loaded from storage. Normally, images downloaded from the Internet are cached so that subsequent loads will be faster (should only download from Internet once)... unless the HTTP response header from the server has flagged it as \"no-cache\" or something similar.",
					"updateAuthor": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2019-12-02T19:10:55.000+0000",
					"updated": "2019-12-02T19:10:55.000+0000"
				},
				{
					"id": "453843",
					"author": {
						"name": "eharris",
						"key": "eharris",
						"displayName": "Ewan Harris",
						"active": true,
						"timeZone": "Europe/Dublin"
					},
					"body": "[~bhouse] [~jquick] I think this might be a wont fix then? I think it's out of scope for alloy/sdk to try and do caching of images for folks.\r\n\r\n[~topener] put together [to.cachedimageview|https://github.com/Topener/to.cachedimageview] that might suit this task well?",
					"updateAuthor": {
						"name": "eharris",
						"key": "eharris",
						"displayName": "Ewan Harris",
						"active": true,
						"timeZone": "Europe/Dublin"
					},
					"created": "2020-01-28T11:04:25.000+0000",
					"updated": "2020-01-28T11:04:25.000+0000"
				},
				{
					"id": "453859",
					"author": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "[~eharris], right, this is not a bug. This is by design.\r\n\r\nPerhaps what's needed is to research if we can expand the off-screen range of rows before they're recycled on Android/iOS. The idea being:\r\n* We should load rows that are just outside of the screen so that they're ready when scrolled-in.\r\n* Not unload rows that have just been scrolled out in case end-user scrolls back.\r\n\r\nSo, I suppose a \"story\" ticket would be better.\r\nWhat [~bhouse] raises is a valid use-case.",
					"updateAuthor": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2020-01-28T19:03:25.000+0000",
					"updated": "2020-01-28T19:03:25.000+0000"
				}
			],
			"maxResults": 5,
			"total": 5,
			"startAt": 0
		}
	}
}