Closed pinarol closed 6 days ago
App Name | Gravatar SwiftUI Prototype Build | |
Build Number | 1216 | |
Version | 1.0 | |
Bundle ID | com.automattic.gravatar-sdk-demo-swiftui.prototype-build | |
Commit | 564c1ac2186c045d67edab00bc30c3fe4faafa81 | |
App Center Build | Gravatar SDK Demo - SwiftUI #104 |
App Name | Gravatar UIKit Prototype Build | |
Build Number | 1216 | |
Version | 1.0 | |
Bundle ID | com.automattic.gravatar-sdk-demo-uikit.prototype-build | |
Commit | 564c1ac2186c045d67edab00bc30c3fe4faafa81 | |
App Center Build | Gravatar SDK Demo - UIKit #105 |
Solves a problem where a UI glitch occurs because of the async access to the cached image. The problem was first reported here: https://github.com/wordpress-mobile/WordPress-iOS/pull/23534#discussion_r1745530517
Check out the small "Me" icon:
https://github.com/user-attachments/assets/a3d1a82d-4897-4a0e-9b6c-5bb2346354b7
Description
Some History
We updated
ImageCaching
to comply with the new concurrency model with this PR: https://github.com/Automattic/Gravatar-SDK-iOS/pull/252 . As described there, we discovered that making protocol functions async doesn’t dictate it on the implementations. Types conforming to ImageCaching could still have their non-asyncsetEntry(…)
,getEntry(..)
implementations. So keeping the protocol functions async was the more "inclusive" way.The problem
But here’s the downside, “Gravatar.ImageCache.shared” is public, so one can just directly get the cached image from there. However, since these methods are async, the system can suspend there to do sth else. So the UI change can’t happen immediately in a synchronous way and can cause UI glitches.
One should be able to just:
Is this critical/urgent?
Nope. WordPress injects its own cache to the Gravatar SDK, so they can access their cache synchronously inside the repo. This is more of a problem for cases where they rely on the SDK's cache.
Testing Steps
CI should be sufficient but let's also smoke test the UIKit demo app.