[TIMOB-930] coverflow bug
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-04-17T01:54:42.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.5.0 |
| Components | iOS |
| Labels | n/a |
| Reporter | Nolan Wright |
| Assignee | Blain Hamon |
| Created | 2011-04-15T02:39:26.000+0000 |
| Updated | 2011-04-17T01:54:42.000+0000 |
Description
http://helpdesk.appcelerator.net/tickets/2354">http://helpdesk.appcelerator.net/tickets/2354
coverflow is loaded with 33 images - initially you can only see
10-13 but as you scroll through the images the others appears
code attached
Attachments
| File | Date | Size |
|---|---|---|
| archive.zip | 2011-04-15T02:39:27.000+0000 | 6628014 |
Fits in with the other coverflow bugs I have. We're going to have to do a rewrite.
valid, needs testcase
as noted by Nolan, when the app loads only some of the images are shows, scroll through, back the beginning and the right again shows all the images. Additional to only a subset of the images appearing, scrolling through is pretty clunky in that the animations are nto smooth.
Do you guys know if there's been any update to this issue? We're currently experiencing this same problem.
Same here, only some images are loaded.
Reclaiming as part of the coverflow view rewrite/fix.
(from [fa4c0e8f94ce1c3fd93a409602e8baa6f1b19202]) [#930 state:fixed-in-qa][#587 state:fixed-in-qa][#442 state:fixed-in-qa][#2119 state:fixed-in-qa] Coverflow rewrite to restore functionality. Setting images works more like imageView, but image resizing/using imageviews in coverflow is not yet supported. http://github.com/appcelerator/titanium_mobile/commit/fa4c0e8f94ce1c3fd93a409602e8baa6f1b19202"> http://github.com/appcelerator/titanium_mobile/commit/fa4c0e8f94ce1...
1.5.0.5dc262e 3.2.2 ipad, 4.0.2 ipod touch 3rg gen.
Hi,
I don't think this isn't really fully fixed. Compared to the old one I think the following issues still remain:
1) There is no way easy way to prevent the default image from loading before other remote images
2) Cover flow seems loads the images in reverse order, so when you first view it, there are just blank images (or the default image) which isn't the best experience for the user.
Thanks,
James
1) Perhaps as a future feature request, some means to define the default image. Note that if we did not have a default image, someone else would open a bug complaining about the lack of a default image.
2) This is just the nature of remote images. There's a number of factors, including the speed at which the server sends back images. Another possibility is that the first images are requiring a DNS lookup and firing up the network connection, while latter images already have the DNS cached and possibly even still have a connection to the server. So the faster-loading later images 'appear' to have loaded first, since there was less of a wait.
One possible solution to remote images being slow is to make them not remote. For example, in the background before the coverflow is even used, and you know the images are going to used, use HTTPClient to save them locally.
Either way, the original bug is fixed.
1) I've added a new ticket here: https://appcelerator.lighthouseapp.com/projects/32238-titanium-mobile/tickets/2526-option-to-set-default-image-or-have-no-default-image-on-coverflow-view"> https://appcelerator.lighthouseapp.com/projects/32238-titanium-mobi...
2) It really seems to load in reverse order, not randomly starting with whichever image that didn't have to go through the DNS. So it seems the functionality compared to the previous version is different. This was never an issue on the previous version. I've been poking around the objective C trying to figure it out, but would really appreciate if someone that new the code more could have a look.
Thanks,
James