[ALOY-1712] ImageViews constantly reloading while scrolling in ListView templates
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | None |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Titanium SDK |
| Labels | alloy, griffin-app, listview |
| Reporter | Brenton House |
| Assignee | Bruce Wayne |
| Created | 2019-12-01T05:04:07.000+0000 |
| Updated | 2020-01-28T19:03:25.000+0000 |
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.
I 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.
[~bhouse] any code we can use to reproduce this? This also maybe seems like something at the SDK level rather than Alloy itself?
This is the expected behavior for ListView. ListView 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. The 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.
[~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. [~topener] put together [to.cachedimageview](https://github.com/Topener/to.cachedimageview) that might suit this task well?
[~eharris], right, this is not a bug. This is by design. Perhaps 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: * We should load rows that are just outside of the screen so that they're ready when scrolled-in. * Not unload rows that have just been scrolled out in case end-user scrolls back. So, I suppose a "story" ticket would be better. What [~bhouse] raises is a valid use-case.