35 lines
1.7 KiB
Plaintext
35 lines
1.7 KiB
Plaintext
# Workers should just perform API calls
|
|
|
|
* Status: Accepted
|
|
* Deciders: Marino, Zorica, Stefanija, Davide, Tomasz, Maciej
|
|
* Date: 08/09/2021
|
|
|
|
|
|
|
|
## Context and Problem Statement
|
|
|
|
Currently in the project we still use multiple different approaches for doing background work. As we are
|
|
trying to settle on using Android Worker, we want to define the particular use case in which we are gonna
|
|
need to rely on said Worker. It's easy to abuse the Worker component if we are calling it from different places
|
|
and for different usages, so we needed to be specific on when and why we should use it.
|
|
|
|
## Decision Outcome
|
|
|
|
* Android Worker should only perform API calls (no business logic, no local data handling)
|
|
* Worker should only be called from Repositories
|
|
* They can be called as a "fire and forget" in some cases (eg. star message, since a failure is very
|
|
unlikely and even if verified the consequences would be light).
|
|
* When we need the UI to be able to react to API failures, we should have the repo returning a flow
|
|
(first "optimistically" just after saving to DB and then once we get the API response)
|
|
|
|
### Exceptions
|
|
|
|
Some special cases call for a different use of Worker. So we agreed on some exceptions where workers
|
|
will contain more:
|
|
* Case of "send message": we need all of the business logic to be in a worker as killing the app right
|
|
after hitting send is a valid use case
|
|
* Case of "add lots of labels to a message": we need to dispatch this through a worker because of
|
|
"performances constraints" (the operation is started from an action view model which won't live long
|
|
enough for the action to complete, but even if it wasn't the case the action is very slow and resource
|
|
intensive so it would block the UI if performed in the VM)
|