Xamarin iOS-每次我从Visual Studio运行时，用户生成的图像都会消失

Question

So I have an app, in which users take photos. I save these photos to the library and display them somewhere in the app. This all works great. However, every time I run the app from Visual Studio (excluding the session when the photos are taken), these images don't show up.

Launching the app from my device directly (so not in debugging mode) works as you would expect - I can see the images just fine.

I know there must be a way for this to work - the local database isn't wiped every time I run from Visual Studio for example - but I cannot for the life of me figure it out.

I've tried saving the images elsewhere (Resources, Application Data, root MyDocuments, etc), but to no avail.

Contents of GetImagePath(string filename) so you can see where I'm saving them:

string libPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "..", "Library");
return Path.Combine(libPath, filename);

Anybody here got any ideas? I think once the app is deployed it should be fine, but it's still damn annoying to have this happen whilst I'm developing.

Thanks in advance!

EDIT: Here's my saving and loading code: Saving: NSData.FromArray(data).Save(path, true, out error)

I'm displaying them like this: Content.Content = new Image { Source = filename }

Answer 1

So, after a bit of playing around and stepping through code I've found the answer.

Your data in iOS is stored in an app container - the GUID associated with this container changes every time you build to the device. As I was storing the full file path instead of just the filename, the images weren't showing up after a re-deploy because the full file path was looking for a no-longer-extant app container. The contents of the Library and Documents folders are copied to the new app container each time - but using the full path from before the current version was build to the device wouldn't be able to find it.

Switching to only store the filename and getting the full file path each time I need to show an image fixed this issue.

I noticed this issue during development, but in production there would have been issues where images weren't being found after an app update.