Replies: 21 comments 1 reply
-
|
Hi, thank you for your questions.
|
Beta Was this translation helpful? Give feedback.
-
|
You can also get acquainted with the sample project. |
Beta Was this translation helpful? Give feedback.
-
|
@dimonovdd OK thanks for the info. I'll do some testing and get back to you. |
Beta Was this translation helpful? Give feedback.
-
|
Just wanted to let you know, I'm really appreciating your work! I'm also in need of new media-picking functionality. Keep up your good work! I lack knowledge to contribute, but I'll do what I can to test the package and get back with any relevant feedback. |
Beta Was this translation helpful? Give feedback.
-
|
@Brosten Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
What about support for UWP? |
Beta Was this translation helpful? Give feedback.
-
|
I think we can add support for UWP, after the first release |
Beta Was this translation helpful? Give feedback.
-
|
I just made a first attempt to introduce this to my current app. The app looks like this
My shared code is stuck on 2.0, since UWP don't support 2.1 and there doesn't seem to be a plan for it either. So, I can't install MediaGallery on my 2.0 project, since MediaGallery has min target of 2.1. |
Beta Was this translation helpful? Give feedback.
-
|
Please create two issues to support UWP and .net Standard 2.0 |
Beta Was this translation helpful? Give feedback.
-
|
I'm making progress integrating your latest build into my app (thanks for sorting the .NETStandard 2.0 thing so quickly). So far I'm concentrating on testing iOS and it looks like I can get the EXIF data I need from a picked image without needing to ask for additional access to Photos. This is great! And simplifies things for me significantly compared to the what I was doing with the old MediaPlugin. I have some questions about file names. In your documentation you say: //...
var results = await MediaGallery.PickAsync(1, MediaFileType.Image, MediaFileType.Video);
if (results?.Files == null)
return;
foreach(var res in results.Files)
{
var fileName = file.NameWithoutExtension; //Can return an null or empty value
var extension = file.Extension;
var contentType = file.ContentType;
using var stream = await file.OpenReadAsync();
//...
}So even when |
Beta Was this translation helpful? Give feedback.
-
|
iOS below 14 returns null in most cases. To get the actual file name, we need permission to access the gallery. |
Beta Was this translation helpful? Give feedback.
-
|
But a file extension is still returned? |
Beta Was this translation helpful? Give feedback.
-
|
OK, that's really weird. But good to know I guess. |
Beta Was this translation helpful? Give feedback.
-
|
I didn't find a better solution. It will be strange if the property returns us the name: "37cb18fa-2da4-4c81-8eab-6e568208cd6f" |
Beta Was this translation helpful? Give feedback.
-
|
My app supports taking photos as well as picking from the gallery. For taking photos I'm currently using Xamarin.Essentials.MediaPicker.CapturePhotoAsync and the returned FileResult object seems to have a default FileName that is exactly that, a GUID with a file extension on the end of it. So in my situation at least, a GUID file name coming back from the gallery would have seemed less strange and more consistent than a null or empty string. At the end of the day, I really don't care what the file name is as long as it's unique. And as I'm doing parallel saving of multiple image files to local storage when they come in from the gallery, setting the file name as a "yyyyMMdd_HHmmss" timestamp like the old MediaPlugin used to do doesn't seem to be cutting it, so I was actually thinking of just making all my files names GUIDs anyway. ¯\(ツ)/¯ |
Beta Was this translation helpful? Give feedback.
-
|
If we need a guid we can generate it ourselves. But if we need to get the real name of the file, it will be difficult to distinguish it from the guid. For example, I want to upload files with their real names to the server and generate a unique name if there is empty. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah it’s not a big deal to generate a GUID anyway. But maybe another idea could be to have a Boolean that could be passed to PickAsync that makes it generate or not generate a GUID file name if the returned value is null/empty. Or you said in most cases iOS < 14 returns null/empty. Maybe returning a GUID in that situation makes sense? I don’t have an iOS device running < 14 to test with so I’m not sure what “most cases” really means. But whatever you decide to do works for me, I’ll manage. I use F#, so I just don’t like nulls and prefer predictable values. Thanks for your work on this. |
Beta Was this translation helpful? Give feedback.
-
|
I love null. I always check the string using the |
Beta Was this translation helpful? Give feedback.
-
|
Fair enough. It's your library and you should do what makes sense to you. I used to just accept null values as a part of the landscape, then one day I finally got around to learning F# and noticed that the language designers had gone to some effort to eliminate null values as much as possible and I wanted to understand why. Thinking about it now, it makes a lot of sense to avoid the possibility of null reference exceptions. Null reference errors happen at runtime and are one of the most common classes of error. When I think back on my own personal programming experience, I can remember many times when forgetting to add a null check or not expecting a null value caused a runtime error, it's an easy mistake to make. Tony Hoare even being quoted as saying it was his "billion dollar mistake". Just my opinion of course, but I don't think we should be loving null values, at best they should only be tolerated. :) Doesn't change the fact that they are deeply a part of modern programming in general. For this particular topic we're talking about, if it was me, in the case that the original file name wasn't available and noting your use case that you're wanting to cater for, I probably would have made PickAsync return an empty string rather than null. The reason being that I more likely expect a null value file name if no file was returned at all, but I wouldn't expect a file to be returned but with a null file name. An empty string would have made more intuitive sense to me and better fits the "Principle of least astonishment" as applied to an API. But again, this is just my opinion and what astonishes different people is obviously subjective. Keep up the good work! I'm going to get back to hacking on my app. |
Beta Was this translation helpful? Give feedback.
-
|
@gaelian @Brosten |
Beta Was this translation helpful? Give feedback.
-
Hi there. I maintain an app that relies on the MediaPlugin quite heavily. Since support ceased for this plugin it's been a bit difficult, so I was keen to find out what your project here is doing and what plans you might have for future features. I see that you're also contributing back to Xamarin Essentials which is great.
Does your project currently - or will it in the future - support:
SaveMetaData = true? For my use case, I'm specifically interested in saving EXIF GPS data within a photo.selectionLimitis > 1?These features are pretty central to our app and hacking the MediaPlugin code for myself isn't feeling like a viable long term solution. So I'd be keen to try and help out here if I can, with this kind of stuff.
Beta Was this translation helpful? Give feedback.
All reactions