This refactors some of the large and retina image logic that I added in #81 and #84. Now the FetchComicImageFromWeb operation works based on a prioritized list of image URLs. If one fails, it moves to the next one in the list.
Now, we generate that prioritized list of URLs in the Comic model. Makes sense to keep it all in one place. Before, we had an attemptLargeImageDownload flag that was passed into FetchComicImageFromWeb and that operation also determined whether to try for retina or not. It was messy and ugly, and this unifies all of that.
It also adds some special case handling for 256, 273, and 980. 256 and 273 link directly to a large image in their link JSON, so we don't have to guess at a _large image. 980 has a _huge image, which we now infer just like we do for most of the _large images.
TiledImage was causing some memory issues when displaying the huge image from 980, which seems to be the opposite of what that class was trying to do. It uses way less memory when using a UIImageView directly (a few MB versus 17+ GB—I don't know when it actually stops allocating, I stopped when my computer ran out of memory and started swapping). Anyway, I removed TiledImage completely to get rid of that issue.
This refactors some of the large and retina image logic that I added in #81 and #84. Now the
FetchComicImageFromWeboperation works based on a prioritized list of image URLs. If one fails, it moves to the next one in the list.Now, we generate that prioritized list of URLs in the
Comicmodel. Makes sense to keep it all in one place. Before, we had anattemptLargeImageDownloadflag that was passed intoFetchComicImageFromWeband that operation also determined whether to try for retina or not. It was messy and ugly, and this unifies all of that.It also adds some special case handling for
256,273, and980.256and273link directly to a large image in theirlinkJSON, so we don't have to guess at a_largeimage.980has a_hugeimage, which we now infer just like we do for most of the_largeimages.TiledImagewas causing some memory issues when displaying the huge image from980, which seems to be the opposite of what that class was trying to do. It uses way less memory when using aUIImageViewdirectly (a few MB versus 17+ GB—I don't know when it actually stops allocating, I stopped when my computer ran out of memory and started swapping). Anyway, I removedTiledImagecompletely to get rid of that issue.