Cache mechanism for photos

[g123k]

What

If we migrate to a non-blocking uploading photo feature (#1593), we have to implement a local cache.
Indeed, if a photo is not yet sent to the server (offline mode for example), the user shouldn't be aware of that.

The change required here is basically to say:

• Is a photo available in the cache? -> If true, take it
• Otherwise, make a request

The idea is to use this folder: https://pub.dev/documentation/path_provider/latest/path_provider/getTemporaryDirectory.html
When a new task is created, the photo is stored there and removed once the task is successful.

Part of

• Product addition (tracker) #1379

[monsieurtanuki]

@g123k I don't think it's safe to use a temporary directory, as "Files in this directory may be cleared at any time." (it means: when other apps need space).
The files we're talking about are files that the user assume are to be uploaded; we don't want those files to be deleted from out of nowhere.
I suggest getApplicationDocumentsDirectory instead.

You're not mentioning either the fact that some day we'll have to upload the pictures (and delete them).

Or maybe there's confusion with #413 and #1593.

I do think those are distinct issues:

• non-blocking upload (safe folder)
• cache (tmp folder)
• special case of user when the upload is not finished - check in the safe folder, then in the cache folder, then a request?

[g123k]

Yes and no.

On Android, it's only based on the user's decision.
However, you're right, on iOS, it may be erased by the OS.
Hence, my confusion on this.

Also, after reading how Hive is implemented, it also uses getApplicationDocumentsDirectory. So we should follow the same impl.

Thanks for your feedback.

This issue is indeed for #1593, as this cache is only temporary, whereas #413 is a long-living cache.

You're not mentioning either the fact that some day we'll have to upload the pictures (and delete them).
That's what will be done in #1593

To summarize, this issue only consists in implementing a system to store temporary files while they're being uploaded.

[monsieurtanuki]

@g123k Thank you for your answer.

I still don't agree on several points:

• getTemporaryDirectory / getCacheDir files on Android can be deleted directly by the OS on low memory (it's not "only" based on the user's decision), and that's not at all what we want in the case of the user having taken a picture for Smoothie - we need to keep these files alive until it's uploaded, temporarily but regardless of the OS, therefore getApplicationDocumentsDirectory is relevant
• Picture cache for slow connectivity / offline #413 is not about a "long-living" cache, it's about managing offline and slow connectivity the best we can but without taking too much space, therefore getTemporaryDirectory should be used for cache, no need to clog the disk
• to avoid the confusion I would recommend marking the current issue as duplicate with Picture cache for slow connectivity / offline #413 and close it, and you can start The "uploading image" dialog should not block the user from moving to the next photo #1593 without having to wait for Cache mechanism for photos #1595/Picture cache for slow connectivity / offline #413 because they're dealing at 90% with different files (and 100% with different folders)

[g123k]

A PR #1600 is available with both short and long living cache storage.

Hmmm I’m not sure to understand your last point.
For the cache mechanism implementation (what I’ve done in the PR) to which issue will it be linked?

[monsieurtanuki]

@g123k Actually you fixed both cases (cache and to-be-uploaded) in just one PR, so you can ignore my last point.