[Request]: (share_plus) EXTRA_TITLE in share Intent on Android

[miquelbeltran]

Plugin

share_plus

Use case

As a plugin user I'd like to be able to set the EXTRA_TITLE when sharing conent (URL, Text or Files) with share_plus when using Android.

Proposal

See PRs #3306 and #3270.

Several options:

1. Add a title optional parameter. This is only used on Android.
2. Simply pass the subject as the EXTRA_TITLE intent extra.
3. Create a way to pass Intent extras directly (e.g. a Map<String, String>)
4. Create an "Android params" optional payload for the share methods.

Each one has advantages and disadvantages, I'd like to discuss them in this ticket.

[miquelbeltran]

Solution 1: title param.

The main issue I see is that subject and title kind of mean the same thing depending on the implementation. Some users may assume that title is used when in reality subject is being used.

A similar solution would be to remove subject and replace it by title, and instead create an optional subject that is only used in email subjects if supported by the platform. That would be a breaking change, but at least is somehow logic.

Solution 2: Use existing subject param.

The issue I can see with it, as mentioned in #3306, when a plugin user wants to specify a different subject and title (maybe that's the case for email clients on Android?) so there are side effects that we cannot really know unless we verify on many receiving apps.

3: Extras payload

This would be interesting when requiring multiple extras, e.g. EXTRA_EMAIL, although at this point I'd recomment to use android_intent_plus.

4: Android payload

This probably escalates the best for all the platform exclusive params, also like the origin offset and things like that.

[holzgeist]

Solution 5: add (yet) another method to the interface that's compatible with Web Share API. Specs here

The main issue is probably a confusing interface because then the same thing can be achieved by (at least) two functions

[holzgeist]

Ad 1) I agree, that would be most logical, but definitely a breaking change
Ad 2) I realized that the unexpected behavior happens in the receiving apps, not in the app using share_plus while trying to write my first answer, before you posted your opinion on all solutions. I'm not an Android developer, but I try to pick up stuff on the way 😄
Ad 3/4) I guess that are the most flexible, but least preferable solutions. After all, the nice thing about flutter is that you don't need to know about platforms too much and still have it working as expected

[miquelbeltran]

Solution 5: add (yet) another method to the interface that's compatible with Web Share API. Specs here

Yeah, refactoring the three existing methods into a single one is something I'd like to see eventually as well. That would make adding extra options easier, too.

[miquelbeltran]

My proposal for a SharePlus refactor is as follows:

• Unify the three methods share(), shareUri and shareFiles() into a single method.
• Make SharePlus class instantiable, instead of exposing static functions.
• Create a ShareParameters class to group all possible parameter combinations that can be passed to the share() method.

like e.g.

class ShareParams {
  final String? text;

  /// Used as share sheet title where supported (e.g. EXTRA_TITLE on Android)
  final String? title;

  /// Only used as email subject where supported (e.g. EXTRA_SUBJECT on Android)
  final String? subject;

  /// Only used in Android as preview thumbnail
  final XFile? previewThumbnail;

  /// Only used in iPad and Mac as share sheet origin
  final Rect? sharePositionOrigin;

  /// Share a URI, alternative to sharing [text]
  final Uri? uri;

  /// Share multiple files, can be used in combination with [text]
  final List<XFile>? files;

I plan to do this refactor in late December or January, when I will have time.

Afterward, we can incorporate the other pending features like #3377 and #3372