refactor(mobile): introduce image request registry on iOS #27486
refactor(mobile): introduce image request registry on iOS #27486LeLunZ wants to merge 2 commits intobugfix-27365from
Conversation
|
Label error. Requires exactly 1 of: changelog:.*. Found: 📱mobile. A maintainer will add the required label. |
1 similar comment
|
Label error. Requires exactly 1 of: changelog:.*. Found: 📱mobile. A maintainer will add the required label. |
| func cancel(requestId: Int64) { | ||
| remove(requestId: requestId)?.cancel() | ||
| } |
There was a problem hiding this comment.
Is there much point to this and the Cancellable protocol? It seems like the caller could easily just do this.
There was a problem hiding this comment.
Yes, Cancellable exists to make registry.cancel() possible.
In #27489 it gets replaced with the ImageRequest base class which also has the cancel function, but because we use a base class we don't really need a protocol anymore.
But you are right, we only have 2 callers, so this helper isn't really that necessary.
There was a problem hiding this comment.
I think it's more composable to have the caller interact with the request and keep the registry lean.
Description
Base branch of this Pr is currently #27471
Currently LocalImageApiImpl and RemoteImageApiImpl each maintain their own mechanism for tracking inflight requests
For me that just feels very inconsistent for the same "work".
Thats why I introduced
Cancellableprotocol and a genericRequestRegistry<T: Cancellable>that centralise all the request tracking together. Everything is done behind aUnfairLockwhich I think is the faster approach between locks, and queues.In the RemoteImageApiImpl we can now remove the lock, and all manual lock/unlock calls as they are replaced by the registry.
In the LocalImageApiImpl we can remove the
cancelQueueandrequestQueueas both are handled by the lock in the registry.Additional change:
removed
assetQueueas NSCache is already thread safe.How Has This Been Tested?
Checklist:
src/services/uses repositories implementations for database calls, filesystem operations, etc.src/repositories/is pretty basic/simple and does not have any immich specific logic (that belongs insrc/services/)Please describe to which degree, if any, an LLM was used in creating this pull request.
unfair lock implementation