Self explanatory.
Great. Awaiting for updates :)
@miguelpruivo thanks for this awesome package!
Interestingly enough, I landed here because I was looking for this very feature 😄
Do you have any idea of the perceived effort involved for this?
Cheers.
@jamesdixon thanks! Actually, I'm positive that not much. I was thinking on also supporting compression parameters hence the delay, but for the time being, I guess I'll implement it right away so people can start picking multiple pictures/videos from gallery with original quality and leave the compression for now (after all, there are other packages that can be used to compression afterwards with a lot of options).
There are some compression libraries (that use native compression) that are very easily to use and therefor also good to combine with your package. Compression straight out of your package would be a nice feature tho.
Let me know where I can buy you a cup of coffee.
@miguelpruivo sweet! Yes, honestly, the multiple picking feature is something that it seems a lot of people are looking for. There are a couple of other libraries that do it, but your library is the cleanest and most versatile with regards to picking files, so having multi-select would be 🔥
More than happy to help where I can!
By the way, saw you're from Portugal. My wife and I had a trip planned for May and it obviously was cancelled. We're so bummed. We hear nothing but amazing things about your country!
@jamesdixon thank you! It turns out that I've been working on the implementation for this since yesterday and I thought that it would be out-of-the-box but then found out that on iOS, the ImagePickerViewController doesn't allow you to pick multiple items, thus, I'm working around that — probably will use a good iOS lib with the features I need or else will have to create my own. Nevertheless, I think I'll have this on the plugin really soon (will work a bit on it today as well).
As for Portugal, you are right, this virus got us all and I still definitely recommend you to come when all of this goes away, but preferably, by the spring/summer, where you can really take advantage of this amazing country weather, beaches, food and people, of course.
@miguelpruivo thanks for the update! Did you end up picking an existing iOS library?
Yes, we're definitely planning on rebooking our trip for next spring. Stay safe!
@jamesdixon yes, it's already on the go. I'm adding BSImagePicker since that after researching and see details of more than 5 different good options available, this one seems to be the most reliable as far as it concerns to iCloud picking, native gallery UI, different albums, picking limits and so on.
Also, is one of the few that still has a decent support, having myself issued a PR here and here for Objective-C backwards compatibility so I can add it into the plugin.
I started an implementation today (you can checkout to the branch if you want to give it a try) but it's still missing some things before I can merge it into master (and deploy a new version). I believe that even this week I'll be able to get it done.
Ok, the feature has landed on pub.dev with 1.7.0. 🎉
Have in mind that currently filtering with different albums is not supported (already issued a PR for the BSImagePicker for exposing that to ObjC as well). As soon as it's available, I'll add it. Picking single files remains the same, using the iOS SDK image picker instead, just for reliability purposes.
Also, you will need to set your iOS project's minimum version to 10.0 and start using use_framework! on your Podfile.
Thank you all. Any discussion regarding this could still be done in this thread.
@miguelpruivo Great! Thanks for the update.
@miguelpruivo fantastic! Will give this a try. Thank you for your work 🙌
@jamesdixon I'm actually right now working on this, I wasn't satisfied with the provided result of BSImagePicker, so I'm replacing it with DKImagePicker which actually provides more customization, allows camera and so on. Also, I can make it ready for albums and videos right now as DKImagePicker exposes everything to Objective-C already.
Last but not least, it requires a minimum version of iOS 8.0 whereas BSImagePicker requires 10.0 — won't make much of a difference nowadays anyway.
@miguelpruivo ah, okay nice! I was actually just logging a bug. Was seeing that when you first load the gallery, it's blank. Subsequent loads work just fine.
I'll wait for this new version then.
Cheers.
Yes, also on that one I had to manually handle iCloud files (and also add the progress bar loading on the UI) which cluttered a bit the readability of the obj-c implementation of the plugin. I'll keep. you updated!
@jamesdixon and others in this thread, it's done (1.7.1). I believe that now is more reliable and you can also have the freedom to pick from different albums and use both FileType.image and FileType.video. Any feedback is appreciated.
I've added a simple modal loading dialog while exporting the assets from the picker and it can actually take a bit if you select a lot that are stored on iCloud as they need to be downloaded along the way. I would like to have some detailed message such as _Exporting..._ or so, but that doesn't add much and would force-me to support internalization. Let me know what you think.
Thank you.
@miguelpruivo Thanks for the quick fix. I would like to suggest to make the loading dialog a widget I can manually insert like:
FilePicker.getMultiFile(type: FileType.image, loadingDialog: Container(),); Or something like that. The message thing (and internalization) could be fixed by the developer himself then.
Also, is it correct that there's no option to let the user pick multi images and videos (at the same time) from the Photos app on iOS?
@DebugTheCode the loading is being made on the iOS native side and not Flutter's. So thats not actually possible, but I can provide a way for a custom loading, just want to keep it simple.
As for your question, currently is not possible, but I can add a FileType.media for that use case, probably that's a good option.
@miguelpruivo Ah, I understand! FileType.media would be a good solution!
@DebugTheCode I'll add it later today.
Thank you.
@miguelpruivo nice! I'm working on integrating this but ran into an error. Seems like there may be a conflict with flutter_image_cropper?
When I try and build, I am getting an error about a missing .h file from that package. This didn't happen before 1.7.1, so I'm wondering if there's an issue. Would you mind installing it on your end to see if you also get a build error?
@DebugTheCode already added FileType.media as demanded. It's live on 1.8.0. 🙂
@jamesdixon indeed they must be conflicting somehow, as both packages use TOCropViewController — I wish there was a way to specify subdependencies that I want to include from my pod's subspecs, but that's not actually possible (not that I know), because I don't actually need the cropper at all.
Were you previously using use_frameworks! before? I'm trying to understand whether this is a bridge conflict or versioning.
Thanks!
@miguelpruivo yes, I was using use_frameworks! previously. I was curious if DKImagePicker is even using that dependency as I didn't see cropping mentioned in its feature set.
Unfortunately, flutter_image_cropper is the best implementation I've seen, so trying to determine a workaround.
I don’t like the idea of having conflicts with other packages dependencies as well @jamesdixon, so let me know if you find a way!
@miguelpruivo Great! I came across (probably) a bug. When I use FileType.custom with allowedExtensions it throws the following error: Unhandled Exception: Exception: If you are using a custom extension filter, please use the FileType.custom instead.
This is what I'm calling: await FilePicker.getFile(type: FileType.custom, allowedExtensions: ['mp3']);
Hope this is enough information for you to fix this (if it is a bug in the package).
@DebugTheCode yeah, that shouldn’t happen. Which platform are you on? iOS?
@miguelpruivo Yes on iOS. Also tested it on Android: same error.
@DebugTheCode what if you use specify than just one type?
@miguelpruivo What do you mean? Also tried is with more than one extension in the array. Still the same. It worked before the 1.8.0
I think I see the issue in your code. On line 69 in file_picker.dart you're checking for uppercase CUSTOM. In the new version you've made everything lowercase. Maybe this is it?
Yes, good catch. I was afraid of missing some @DebugTheCode. Refactored to make it more clean as I don't need to maintain a switch case for handling types now.
I'm deploying a 1.8.0+1 with a fix for it in a few minutes. Thanks!
@DebugTheCode done. It should be all fine now. Let me know if you find something else — actually, feel free to file and issue for it.
Thanks!
Most helpful comment
@jamesdixon thanks! Actually, I'm positive that not much. I was thinking on also supporting compression parameters hence the delay, but for the time being, I guess I'll implement it right away so people can start picking multiple pictures/videos from gallery with original quality and leave the compression for now (after all, there are other packages that can be used to compression afterwards with a lot of options).