Change Details

- [ ] Add SDWebImage Pod - [ ] Create a wrapper around SDWebImage logic (this is for implementing our own logic to fall back to the old image cache) DO NOT IMPLEMENT FALLBACK LOGIC NOW - [ ] Replace caching in URL protocol with our new wrapped SDImageCache - [ ] Replace all logic throughout code to reference our new image cache to obtain images or use the UIImageView category to load images Fallback logic / Migration to be addressed in a future ticket: T101527 —— There are many instances of this pattern in the app which all have the same desired behavior: * If `idealImage` is in memory, show it immediately * Otherwise: ** show `fallbackImage` instead (placeholder or different resolution) ** on a background thread, fetch `idealImage` from the network/disk, cache it, then show it again Let's consolidate all of this into one abstraction so we don't need to reimplement it everywhere. == Expected results == === Will it increase our velocity? === It should increase our velocity, since we'll be replacing multiple untested solutions with a single tested one. === Will it reduce risk? === Yes, by having redundant implementations we reduce the potential for one of them to do the wrong thing, and fixes applied to the shared implementation will apply across all uses. === Will it improve user happiness? === Yes, as we'll reduce more edge cases where images don't appear and we'll be smarter about how to store and pass around image data—which should save memory, disk, and CPU.

- [ ] Add SDWebImage Pod - [ ] Create a wrapper around SDWebImage logic (this is for implementing our own logic to fall back to the old image cache) DO NOT IMPLEMENT FALLBACK LOGIC NOW - [ ] Replace caching in URL protocol with our new wrapped SDImageCache - [ ] Replace all logic throughout code to reference our new image cache to obtain images or use the UIImageView category to load images Fallback logic / Migration to be addressed in a future ticket: T101527 --- There are many instances of this pattern in the app which all have the same desired behavior: * If `idealImage` is in memory, show it immediately * Otherwise: ** show `fallbackImage` instead (placeholder or different resolution) ** on a background thread, fetch `idealImage` from the network/disk, cache it, then show it again Let's consolidate all of this into one abstraction so we don't need to reimplement it everywhere. == Expected results == === Will it increase our velocity? === It should increase our velocity, since we'll be replacing multiple untested solutions with a single tested one. === Will it reduce risk? === Yes, by having redundant implementations we reduce the potential for one of them to do the wrong thing, and fixes applied to the shared implementation will apply across all uses. === Will it improve user happiness? === Yes, as we'll reduce more edge cases where images don't appear and we'll be smarter about how to store and pass around image data—which should save memory, disk, and CPU.

- [ ] Add SDWebImage Pod - [ ] Create a wrapper around SDWebImage logic (this is for implementing our own logic to fall back to the old image cache) DO NOT IMPLEMENT FALLBACK LOGIC NOW - [ ] Replace caching in URL protocol with our new wrapped SDImageCache - [ ] Replace all logic throughout code to reference our new image cache to obtain images or use the UIImageView category to load images Fallback logic / Migration to be addressed in a future ticket: T101527 ——--- There are many instances of this pattern in the app which all have the same desired behavior: * If `idealImage` is in memory, show it immediately * Otherwise: ** show `fallbackImage` instead (placeholder or different resolution) ** on a background thread, fetch `idealImage` from the network/disk, cache it, then show it again Let's consolidate all of this into one abstraction so we don't need to reimplement it everywhere. == Expected results == === Will it increase our velocity? === It should increase our velocity, since we'll be replacing multiple untested solutions with a single tested one. === Will it reduce risk? === Yes, by having redundant implementations we reduce the potential for one of them to do the wrong thing, and fixes applied to the shared implementation will apply across all uses. === Will it improve user happiness? === Yes, as we'll reduce more edge cases where images don't appear and we'll be smarter about how to store and pass around image data—which should save memory, disk, and CPU.