plus_plugins icon indicating copy to clipboard operation
plus_plugins copied to clipboard

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

Open miquelbeltran opened this issue 1 year ago • 4 comments

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 avatar Oct 07 '24 11:10 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.

miquelbeltran avatar Oct 07 '24 11:10 miquelbeltran

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 avatar Oct 07 '24 11:10 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 :smile: 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

holzgeist avatar Oct 07 '24 12:10 holzgeist

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 avatar Oct 07 '24 12:10 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 https://github.com/fluttercommunity/plus_plugins/issues/3377 and https://github.com/fluttercommunity/plus_plugins/pull/3372

miquelbeltran avatar Dec 03 '24 07:12 miquelbeltran