Content
View differences
Updated by Oleksii Borysenko about 21 hours ago
**As** a user of the app
**I want to** cache my WorkPackage data
**so that** I can see a list of WorkPackages faster
<br>
**Prerequisite**
The app currently fetches all WorkPackages from the OpenProject API on every access, no local persistence exists for them. Adding a cache layer lets the app serve stale-but-useful data when the network is unavailable, and is the essential first step toward full offline support.
Before starting this task, please make sure that task <mention class="mention" data-id="73915" data-type="work_package" data-text="###73915">###73915</mention> is ready and we know which places are affected <br>
**Acceptance criteria**
* when user opens WorkPackages list, he should see them faster
**Technical notes**
* loading data from server should be implemented with the maximum available page size (taken from config data)
* storing of WorkPackage instances should be done per user. In case of switching user, workpackages should persist in database, but shouldn’t be visible for a different user
* an update logic should be based on filter “updated\_at” and on every sync we should sync only a delta between stored time a current time
* as a first stage we should store only a first layer of data (WorkPackages themselves), All related instances like users, attachments, comments (a second layer) will be fetched from the network or cached within a separate task.
<br>
**Out of scope**
* the time of opening a detail of the WorkPackage won’t change significantly because of two reason. First - we’ve already changed the logic of the WorkPackage so that it shows subject, description, type, status and the project almost immediately from the build 995. Second - loading activities, relations, files info are separate requests and won’t be included in the first phase of caching WorkPackages.
**I want to** cache my WorkPackage data
**so that** I can see a list of WorkPackages faster
<br>
**Prerequisite**
The app currently fetches all WorkPackages from the OpenProject API on every access, no local persistence exists for them. Adding a cache layer lets the app serve stale-but-useful data when the network is unavailable, and is the essential first step toward full offline support.
Before starting this task, please make sure that task <mention class="mention" data-id="73915" data-type="work_package" data-text="###73915">###73915</mention> is ready and we know which places are affected
**Acceptance criteria**
* when user opens WorkPackages list, he should see them faster
**Technical notes**
* loading data from server should be implemented with the maximum available page size (taken from config data)
* storing of WorkPackage instances should be done per user. In case of switching user, workpackages should persist in database, but shouldn’t be visible for a different user
* an update logic should be based on filter “updated\_at” and on every sync we should sync only a delta between stored time a current time
* as a first stage we should store only a first layer of data (WorkPackages themselves), All related instances like users, attachments, comments (a second layer) will be fetched from the network or cached within a separate task.
<br>
**Out of scope**
* the time of opening a detail of the WorkPackage won’t change significantly because of two reason. First - we’ve already changed the logic of the WorkPackage so that it shows subject, description, type, status and the project almost immediately from the build 995. Second - loading activities, relations, files info are separate requests and won’t be included in the first phase of caching WorkPackages.