search

jackpine / biketag-ios

http://biketag.jackpine.me
1 stars 1 forks source link

Images fail to load on ios9 #117

Closed michaelkirk closed 8 years ago

michaelkirk commented 8 years ago

Some spots never load their image. This seems to happen when I'm on a shoddy network. Even when I refresh (pull-down) the spots list and close and restart the app I see the same 4 of 10 spot images. The other 6 are the pixel-bike loading image.

My theory is that the network request times out or something, and that response is somehow cached.

Possible Solutions:

I was wrong. No images were loading on ios9 due to stronger default ios9 security settings. However, the possible solutions are relevant to the issue of when images fail to load for other reasons.

michaelkirk commented 8 years ago

When I reported this issue - it was actually because images weren't loading at all on ios9. The images that did display were cached (presumably before updating?).

But there is still a problem when an image isn't fetched that there is no way to re-download the image other than refreshing the whole list.

michaelkirk commented 8 years ago

This was due to tighter default security restrictions on ios9.

Moving the api endpoint to ssl was straight forward enough, but getting the assets behind appropriate ssl was trickier.

My hazy recollection of this frantic process was something like:

  1. purchase and install an ssl cert for production api
  2. move the production api to ssl
  3. change the asset host (s3) to use ssl (https://biketag-production.s3.aws.com
  4. discovered that the s3 ssl cert is not signed with a "good enough" algo for apple: read more
  5. purchase ssl cert for assets.biketag.jackpine.me
  6. set up a cloudfront CDN
    1. set origin to s3://biketag-production
    2. attach newly purchased assets ssl cert
  7. have assets.biketag.jackpine.me CNAME point to new CDN
  8. update API's asset host to be assets.biketag.jackpine.me instead of biketag-production.s3.aws.com
michaelkirk commented 8 years ago

As a side note, I was able to fix this entirely on the API side - no client changes required.