locked
Is there a way to pre-fill the subject and email address for sharing with the mail app?

    Question

  • I wonder if we can set any data.property that the mail app will recognize and pre-fill the subject, recipient and body with?

    it seems that the app checks for the "subject" property, but unfortunatly not when sending storageitems. Also it would be nice if it would support "to" or "recipient" properties.

    • Edited by phil_ke Thursday, March 7, 2013 11:05 AM
    Thursday, March 7, 2013 10:44 AM

Answers

  • Hi Phil,

    If you didn't disagree I'd think somebody had hacked your account ;)

    That said, I think you're making my point for me. Many of the current apps aren't using the contracts to their full potential. You don't want to be one of those apps ;) If you carefully craft your app to try to talk to a specific app rather than to the general usage then it may work well with that app but is likely to work poorly with others. When that app is updated (as we hope the poor apps will be) your app will not work well with anything.

    If you write your app properly then it will be much more likely to work well across the board.

    On the other hand though, your use case doesn't fit into the contracts. You're not trying to share data arbitrarily with whoever the user wants. The value of the share contract is to let the user share the data wherever and however they want, which is neither needed nor appropriate for your developer feedback scenario. In that case, since the direct data link is what you want a webservice to accept your specific data which you want sent only to you is appropriate. Going through sharing or the email app adds extra steps for the user without any added value. It's a bit easier on the developer than writing a dedicated service, but an ideal app emphasizes the user.

    --Rob

    • Marked as answer by phil_ke Wednesday, March 13, 2013 11:22 AM
    Tuesday, March 12, 2013 7:18 PM
    Owner

All replies

  • I've tried to look up how to do this before and didn't find anything either. I think this would be an excellent addition though.
    Thursday, March 7, 2013 4:35 PM
  • Hi phil_ke,

    Since the sharing target (Mail App) is a built-in windows store app, what we can prefill in the sharing UI is totally depend on the Mail app's implementation.

    Based on my test, the "subject" and "body" fields can be customized by the data we supply in our sharing source app. For example, we can add data to the following properties ( in our sharing source app):


    request.data.properties.title = "email subject...";
    request.data.properties.description = "description ....";
    request.data.setUri(new Windows.Foundation.Uri(.....));
    request.data.setBitmap(....);


    Then, in the sharing flyout window, the Mail app will prefill the "subject" by using the "title" property and all the other properties (description, uri and bitmap) will be put together into the body field.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, March 11, 2013 2:50 AM
    Moderator
  • Steven, thanks for your answer. As I wrote the mail app does not honor the title, description, subject and body fields if the source app set storageitems. I checked the code, it just ignores those properties whenever storageitems. Which makes no sense to me, honestly.
    Monday, March 11, 2013 10:44 AM
  • Hi Phil,

    The sharing contract is not a mail-specific contract: it is a general data sharing plan designed to allow the user to share data with whichever apps desired (possibly Mail, but also other social apps as well as apps such as OneNote). It cannot be used to target specific apps or people. Designing the formats too carefully for a specific share target will likely provide a poor experience when using other share targets (possibly including updated versions of the original).

    The different formats provided in the DataRequest are intended to be different views of the same data. The share target can then choose the most appropriate (generally the richest) format available. While it may include multiple views from different data types, this isn't something the share source can or should depend on.

    As for sending mail to a specific target, the best way depends on your specific use case? If it is for feedback to you then consider hiding the transport and providing a form which uploads to your web service. If you need to send email to a specific target and subject line then consider launching a mailto: URL, but beware that this depends on the user having email set up which supports mailto: (not the case for web mail). Lastly, if you need to connect to a specific mail service (if you are writing a share target, for example) then most services provide some sort of web API the app can connect to.

    --Rob

    Monday, March 11, 2013 8:21 PM
    Owner
  • Thank Rob for taking your time to shed some light on the issue. Still, I tend to disagree with you. The usage of contracts between apps is still very poor, especially between the MSFT apps. The question is why does the Mail target app handles content type so differently. The Share Contract offers the possibility to add properties to your shared data, and the target app can choose to read those properties. The Mail app does read the title, and subject properties for all content types except when your content type is IStorageFile. What's the reason for this inconsistency? Its not predictable behaviour. 

    I would even consider a mail micro-format to be part of my share source and potential target apps (such as mail apps) could read even more from this source micro format like recipients etc. The decission to choose IStorageFiles as the "richest" representation and omitting everything else in the DataRequest seems unlogic to me.

    So my use-case is simply to use the existing apps (MSFT motto: your app is not an island) for sending mails with attachments. We are using the mailto protocol for feedback mails, but this does not allow to attach files (like log files). Writing a webservice to handle things the client systems app should be able to handle seems not the correct way to do things on Windows 8.

    The general use of contracts has to improve for the Win8 ecosystem to really take off. Consider the Skype App, which does not even facilitate the Contact Picker contract when you want to dial phone numbers. Let alone provides a contact picker for other apps.

    Lots of things to do, and we want to integrate with all the (good) apps out there as best as possible.

    Tuesday, March 12, 2013 10:47 AM
  • Hi Phil,

    If you didn't disagree I'd think somebody had hacked your account ;)

    That said, I think you're making my point for me. Many of the current apps aren't using the contracts to their full potential. You don't want to be one of those apps ;) If you carefully craft your app to try to talk to a specific app rather than to the general usage then it may work well with that app but is likely to work poorly with others. When that app is updated (as we hope the poor apps will be) your app will not work well with anything.

    If you write your app properly then it will be much more likely to work well across the board.

    On the other hand though, your use case doesn't fit into the contracts. You're not trying to share data arbitrarily with whoever the user wants. The value of the share contract is to let the user share the data wherever and however they want, which is neither needed nor appropriate for your developer feedback scenario. In that case, since the direct data link is what you want a webservice to accept your specific data which you want sent only to you is appropriate. Going through sharing or the email app adds extra steps for the user without any added value. It's a bit easier on the developer than writing a dedicated service, but an ideal app emphasizes the user.

    --Rob

    • Marked as answer by phil_ke Wednesday, March 13, 2013 11:22 AM
    Tuesday, March 12, 2013 7:18 PM
    Owner