[TECHNICAL] Changes in transfers-related code
Open
Nobody has claimed this yet.
Needs info
Technical
- Dominant language
- Kotlin
- Stars
- 4.2k
- Forks
- 3.1k
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 7
Description
There are several things to find out and some others to improve regarding transfers. Here we can list and discuss everything related with that.
THINGS TO FIND OUT:
- Is a temporal copy (in
.../tmp/...) created for every type of upload? (from content URI, from system) - Why are there 2 different types of upload in case a temporal copy is always made?
- In the case of uploads from content URI, when is the temporal copy removed?
THINGS TO IMPROVE:
- Create 2 different fields in database for transfers:
sourceLocation, which can be a content URI or a path, whatever is the case, andtmpPath, which is the path where the temporal files used for uploads are located. If a temporal copy is always made, both should be always not null (at least once they get copied, which can be before the creation of the transfer object) TransferDaofunctions can use@Updateor@Upsertinstead of@QueryRemoveSourceFileWorkershouldn't receive a content URI as parameter, it can be a path as well. And the key variable (KEY_PARAM_CONTENT_URIcurrently) should be located in the worker itself
TASKS
- Research (if needed)
- Create branch feature/feature_name
- Development tasks
- Implement whatever
- ...
- Implement unit tests (if needed)
- Code review and apply changes requested
- Design test plan
- QA
- Merge branch feature/feature_name into master
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the two upload types and determining when temporary copies are created and removed. Then inspect TransferDao and RemoveSourceFileWorker against the proposed sourceLocation and tmpPath fields and parameter changes. Done means the transfer model and related operations are updated, with the required unit tests and QA plan addressed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- database, mobile
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100