Using APIs in Windows.ApplicationModel.Email

[tigerw]

May be a long shot, hope to get your opinion.

ApplicationModel.Email is an interface to the system e-mail store, and ApplicationModel.Email.DataProvider allows us to implement a custom sync engine that connects the e-mail client to Exchange/Outlook/Gmail/etc.

I believe Wino Mail currently has tight integration between the frontend parts that display the e-mails, and the sync parts that communicate with the server and maintain a database.

Do you think it's feasible to separate out these into two components, which communicate through the system Email APIs? (and in future, Appointments and Contacts).

The motivating use-case here is to have a common sync engine (Email.DataProvider + background task), maintained by the community, that replaces the one provided by the in-box Mail app. Then users can freely choose whichever front-end they want, as long as it uses the system Email APIs. Including continuing to use Mail indefinitely. This will be useful on Windows Mobile, which 3rd party apps like Wino probably won't support.

Advantages of doing this:

• Make easily swappable front-ends
• Storage of e-mails (appointments, contacts) handled by the system
• Emails/appointments/contacts integrated with the system and visible elsewhere, instead of just in Wino
• Settings will show your accounts added in Wino, more familiarity for users (?)

Disadvantages:

• Potentially wide ranging changes to the Wino codebase for not much benefit
• Limited by whatever the system API provides, may be difficult to extend. The API looks quite Exchange-centric
• The email capability necessary to use the system APIs is listed as restricted

I did a small test with a mock sync engine using Email.DataProvider and can confirm it works. I can add a fake account and some emails and see them show up in the stock Mail app. Conversely pushing the sync button in Mail will call into the mock sync engine background task.

What do you think?

[bkaankose]

This is way to complicated to achieve at the moment. I thought about it in the beginning, but Microsoft Store will not allow using that namespace as you said since it's restricted capability. It's only reserved for in-house applications. That's why I have created everything from scratch.

At this point I don't see any way to abstract parts from Wino without spending some time on it. Only thing that is possible is to write a new synchronizer based on the interfaces. Specially ImapSynchronizer and ImapClientPool can be improved.

It has great benefits, but starting this work right now means re-creating Wino from scratch unfortunately. Someone can abstract the UI more and just create events to react, but even doing that will require some effort. After an empty shell, one can move Wino.Core project to Wino.Core.UWP that its data sync implementation comes from the ApplicationModel.Email namespace.

Also one disadvantage of this is going away from the cross platform world. Wino.Core can run with different client implementations right now with some configuration, but in this case it will be working only for Windows.