Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support adding attachments to e-mails #2432

Open
2 of 8 tasks
MartinZikmund opened this issue Jan 4, 2020 · 10 comments
Open
2 of 8 tasks

Support adding attachments to e-mails #2432

MartinZikmund opened this issue Jan 4, 2020 · 10 comments
Labels
difficulty/starter 🚀 Categorizes an issue for which the difficulty level is reachable by newcomers good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. kind/enhancement New feature or request platform/android 🤖 Categorizes an issue or PR as relevant to the Android platform platform/ios 🍎 Categorizes an issue or PR as relevant to the iOS platform project/non-ui ⚙️ Categorizes an issue or PR as relevant to winrt (non-ui)

Comments

@MartinZikmund
Copy link
Member

MartinZikmund commented Jan 4, 2020

What would you like to be added:

Uno Platform implementation of EmailManager currently does not support e-mail attachments. The problem is that Andorid and iOS support file-based attachments only, however UWP API is fully based on streams. There would be two options:

  • Take the stream, write to file, use that file as an attachment, then clean it up "sometime" afterward - as it means the API would eat up storage space, which could potentially be in MB range, and there would have to be a check to clean it up even in case something fails. Ideally the file should be stored in the ApplicationData.Current.TemporaryFolder, as that one should get cleaned up by the system automatically
  • Add some Uno-specific methods, that would allow adding file-based attachments - this API could be either Android and iOS specific, or it could exist as a universal extension method, that would work on UWP as well, so it could be truly cross-platform.

Why is this needed:

To send files with e-mail. It is often used for sending crash-dumps.

For which Platform:

  • iOS
  • Android
  • WebAssembly
  • WebAssembly renderers for Xamarin.Forms
  • macOS
  • Windows
  • Build tasks
  • Solution Templates
@MartinZikmund MartinZikmund added kind/enhancement New feature or request triage/untriaged Indicates an issue requires triaging or verification platform/android 🤖 Categorizes an issue or PR as relevant to the Android platform platform/ios 🍎 Categorizes an issue or PR as relevant to the iOS platform and removed triage/untriaged Indicates an issue requires triaging or verification labels Jan 4, 2020
@davidjohnoliver
Copy link
Contributor

Option # 1 is prefererable from a point of view of compatibility with existing code - certainly clean-up afterwards would be a must.

For option # 2, Uno.UI.Toolkit would be the place for it.

For that matter they're not mutually exclusive, both options could exist side-by-side.

@MartinZikmund
Copy link
Member Author

@davidjohnoliver I am only worried that when we do both, microsoft/microsoft-ui-xaml#1 will be immediately discoverable and the developer will never find out that microsoft/microsoft-ui-xaml#2 is the more efficient choice (unless they explicitly check the docs, but you cannot check docs for everything 😀)

@davidjohnoliver
Copy link
Contributor

Valid, but I think the same problem would exist if we were to only implement # 2: people will see that the UWP method is NotImplemented and they'll figure that it's just not supported.

Discoverability is hard!

@MartinZikmund
Copy link
Member Author

@davidjohnoliver Okay - what about doing both and add a comment to microsoft/microsoft-ui-xaml#1 that suggests using microsoft/microsoft-ui-xaml#2 instead. Potentially there could be a Roslyn Analyzer in the future as well, with such a suggestion.

Last question - when to do the backup cleanup in case it, for some reason, fails after the e-mail is sent? Startup could work, but we want to launch as fast as possible. It could run asynchronously though. And the deletion after sending should fail only occasionally anyway.

@davidjohnoliver
Copy link
Contributor

Sure, some remarks in the xml doc of # 1 drawing attention to # 2 (and vice versa) would make sense.

For the backup cleanup - maybe do it the next time the app tries to send an email attachment? Agreed we wouldn't want to slow down launch for this case.

@MartinZikmund
Copy link
Member Author

One thing I am worried - if using the API is a one time thing, we would have a dead weight adding to the app size forever there 😕

@MartinZikmund MartinZikmund mentioned this issue Jan 7, 2020
7 tasks
@MartinZikmund MartinZikmund self-assigned this Feb 12, 2020
@agneszitte agneszitte added the project/non-ui ⚙️ Categorizes an issue or PR as relevant to winrt (non-ui) label Sep 21, 2020
@jeromelaban jeromelaban added the difficulty/tbd Categorizes an issue for which the difficulty level needs to be defined. label Feb 15, 2021
@MartinZikmund MartinZikmund added difficulty/starter 🚀 Categorizes an issue for which the difficulty level is reachable by newcomers area/eu and removed difficulty/tbd Categorizes an issue for which the difficulty level needs to be defined. labels Jun 1, 2021
@MartinZikmund MartinZikmund removed their assignment Jun 1, 2021
@MartinZikmund MartinZikmund added the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label Jun 10, 2021
@Soap-141
Copy link

Any update on this?

@jeanplevesque
Copy link
Member

FYI microsoft/WindowsAppSDK#3433

@marwalsch
Copy link

Xamarin.Essential's implementation of this API has the somewhat narky behaviour of just silently falling back to mail-URIs should the device's provided API be unavailable.
If I am not mistaken Uno currently does the same.

if (MFMailComposeViewController.CanSendMail)
{
        await ComposeEmailWithMFAsync(message);
}
else
{
       await ComposeEmailWithMailtoUriAsync(message);
}

For plain E-Mails this is mostly a non.issue, but since mail-URIs do not support attachments they just end up getting scrapped while letting the API's consumer know nothing of this.

(On iOS this can become quite the nuisance as MFMailComposeViewController.CanSendMail may return false despite the Mail App being apparently configured correctly. I could reproduce this on two devices with an uneven mix of different iOS- and device-versions, third party mail apps and a lot of tough luck.)

Hence my suggestion is to not adopt the same mistake and let the user know of that case, perhaps through throwing an exception when an attachment is passed but the fallback initiated.

@jeromelaban
Copy link
Member

A possible workaround is to use MAUI essentials, until uno supports EmailManager.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
difficulty/starter 🚀 Categorizes an issue for which the difficulty level is reachable by newcomers good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. kind/enhancement New feature or request platform/android 🤖 Categorizes an issue or PR as relevant to the Android platform platform/ios 🍎 Categorizes an issue or PR as relevant to the iOS platform project/non-ui ⚙️ Categorizes an issue or PR as relevant to winrt (non-ui)
Projects
Status: No status
Development

No branches or pull requests

7 participants