**As** a user of the app Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion **I want to** cache my WorkPackage data Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion **so that** I can see a list of WorkPackages faster

**Acceptance criteria**

Begin of the insertion-End of the insertion Begin of the deletion * End of the deletion when user opens WorkPackages list, he should see them Begin of the insertionfaster

End of the insertion Begin of the deletion faster 


End of the deletion **Technical notes**

Begin of the insertion- loading data from server should be implemented with the maximum available page size
- storing ofEnd of the insertion Begin of the deletion * take into account that everyEnd of the deletion WorkPackage Begin of the insertioninstances 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”End of the insertion Begin of the deletion contains schemaEnd of the deletion and Begin of the insertionon every sync we should sync only a delta between stored time a current time
-

**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\.

End of the insertion Begin of the deletion other corresponding data


<br>End of the deletion