Errors opening from intent/open-in/copy-to are swallowed about file_picker_writable HOT 5 OPEN

right, but this looks pretty much like the only place?
I guess it would make sense to add a dedicated OpenErrorHandler which is for this specific case - when the plugin receives an open intent/callback from the OS.. otherwise for open file/write file/etc. method calls should continue to result in exceptions.

the only thing i'm not sure about is whether the init method should also result in an thrown error when an exception happens during _handleUrl .. i guess to keep consistent it should succeed.. and the error should be reported to the OpenErrorHandler

from file_picker_writable.

right, but this looks pretty much like the only place?

Yes, sorry, I said “e.g.” because the equivalent entry point also exists on Android.

a dedicated OpenErrorHandler which is for this specific case

Yes, it would be single-purpose, but there’s really no other option to catch this case.

i guess to keep consistent it should succeed.. and the error should be reported to the OpenErrorHandler

I agree, I don’t think there’s a better choice.

from file_picker_writable.

@amake I have now done a bit of refactoring, and also added such error handler for open-in/copy-to - only iOS right now.. and it only contains a string message .. this should probably something more useful the application can parse.. not sure yet what though..

f832621#diff-f540102ae087b792214ddead720f73e1R337-R339

the handling works basically the same as for file open handlers.. f832621#diff-d9a718a3042c2ebab14df5f34ef46a52R102-R112

btw. this is still a bit of a WIP, and I also did a quite bit of refactoring and want to move away from providing temporary files in FileInfo to only providing access to files via a callback..

this way there will be no more left over temporary files.. once the app returns from the callback, file will be deleted immediately.

from file_picker_writable.

Thanks for the update. I think a string message is good enough. Just being able to receive a notification is actually enough for me.

Regarding callbacks, I have to say I'm not a fan. My code is very much designed around Futures and async/await, so it will probably be painful to move to the new API. On the other hand I don't have any other good suggestions for achieving your goals.

from file_picker_writable.

@amake the old api still works the same way for now, it's just deprecated.. and it does use futures and async.. basically nothing changes, except you have to process or copy the file to some location before the callback completes..

in AuthPass the change wasn't too painful authpass/authpass@8f7a952

The result of the callbacks is passed back to the caller, so if you simply read the whole file at once, you could basically just do that in the callback and return a tuple of the FileInfo plus Uint8List (or string) with the file content ..

Maybe it would even make sense to put this into the package, a default callback which returns a future with the FileInfo plus the file content (either string or bytes), i guess not many use cases have to stream the file contents.. 🤔

from file_picker_writable.