[TIMOB-7470] iOS: Set TLS version for imageview
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2012-05-31T13:35:46.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | iOS |
Labels | n/a |
Reporter | Mauro Parra-Miranda |
Assignee | Stephen Tramer |
Created | 2012-01-30T10:54:40.000+0000 |
Updated | 2017-03-09T23:09:28.000+0000 |
Image View gets their images through the image loader, which is a low level aspect. Image Views don't load images directly, so this would not be a property on each individual image view. There's a few options here. 1) Have global settings that can be set to lower the TLS version as a 'compatibility mode' for all images fetched. 2) allow an HTTPClient be bound to an imageView as an image source. Issues here involve that clients can only be opened once, and might be expensive. Either way, we'll have to look into this. I'm hesitant for short-term fix or creeping featurism that may prove expensive to maintain later on.
Believe it or not, the best solution might actually to be to use existing infrastructure to pull the image down from the remote source via an XHR client, and upon completion set it as the imageview's image (via a downloaded file - this has the convenient side-effect of even behaving like our internal image caching). Most developers will not be using TLS versioning to pull images from an HTTPS source so we should definitely be wary of bloat. Setting a TLS version globally runs the risk of errors or insecure communication when contacting multiple servers over HTTPS.
The following is the appropriate way to load images from secure resources. In general, when accessing resources over SSL, an HTTPClient is the "most appropriate" way to interact with the server, due to certificate validation and TLS versioning settings. In the future there may also be many more options which affect interoperability with SSL. As a bonus, it also gives finer-grained control over the "crossfade" animation we provide internally when loading a remote resource, as well as better cache control for downloaded images.
Provided an example of an appropriate way to use HTTP and SSL to interact with remote resources.
The one catch to the sample code is that in a large table view, you'll end up loading images long before they come onscreen, leading to a sudden rush and starving the ones actually onscreen. A more advanced solution would be to do the HTTP client creation and open on image load (IE, when the placeholder image loads) which would have the lazyloading that is optimal. Either way, it's possible that the best solution is not a modification to low level code, but a small JS library snippet that uses what's already there to provide results. It'd be portable, general purpose, and best yet return power to the developer to be able to tweak and tailor the code instead of waiting for a long term low level implementation. Isn't part of the reason for Titanium is that Javascript is powerful enough on its own, and flexible enough to provide solutions?
Sorry, but we're still not fixing this! See the incredibly detailed workarounds and discussion on this ticket for why.
Closing ticket as the issue will not fix.