Good morning Mark

hello, Ed!

how can I help you today?

if I save a temp file to share it with another application as a viewer.... what is the best way to insure I delete the temp file after my application exits?

Is it save to delete it after the intent is passed? I didn't think that would be wise.

no, because you do not know when the other app is done with it

that's a general problem with this sort of inter-app content sharing

are you using FileProvider?

looking....

Yes, I'm actually using your example version

usually what I recommend is having some sort of policy (e.g., the file is no longer needed after 24 hours) and some trigger for implementing the policy (e.g., will check on each app launch, will use JobScheduler to check every day)

in particular "after my application exits" is not a good policy (the other app might still be using it) nor a good trigger (as you don't reliably get control at that point)

Good to know

another question along these lines... assume I have a temp file I allow them to view but it is only uses within the app.

what is the best practice to delete or purge this temp file, if it isn't used by any other application?

worst-case, you take the same approach that I described

if you know somewhere in the flow of your app that you are definitely done with the file, delete it then

this sort of thing tends to be driven a lot by app requirements, and I don't know much about your scenario

so when the viewer screen is destroyed or they leave that screen ?

if there is no way for them to get back to there where they would need that data, that would be a reasonable trigger

thanks Mark!

I didn't think it would be wise to delete it if they exported the file to an external viewer

appreciate your time

I draw a distinction between "user exported" and "the app happens to make it available"

if the user is explicitly saying "I want this data to be visible to the other app", perhaps the answer is that you let the user choose where to save that data (e.g., ACTION_CREATE_DOCUMENT), after which it is up to the user to get rid of it

great point