Skip to content
This repository has been archived by the owner on Feb 22, 2023. It is now read-only.

[video_player] add http headers #3671

Merged
merged 20 commits into from
Mar 25, 2021

Conversation

PiN73
Copy link
Contributor

@PiN73 PiN73 commented Mar 3, 2021

This enables to pass HTTP headers to VideoPlayerController.network.

Actually this is rebasing @Yarikk26's implementation #897 on top of video_player 2.0.0.

Fixes: flutter/flutter#16466

Pre-launch Checklist

  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I read the [Tree Hygiene] wiki page, which explains my responsibilities.
  • I read and followed the [Flutter Style Guide] and the [C++, Objective-C, Java style guides].
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
  • I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
  • I updated CHANGELOG.md to add a description of the change.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the [CLA].
  • All existing and new tests are passing.

@PiN73
Copy link
Contributor Author

PiN73 commented Mar 3, 2021

As described in CONTRIBUTING.md, video_player in the PR is temporary using overriden video_player_platform_interface_dependency because it isn't published yet

@stuartmorgan stuartmorgan self-requested a review March 3, 2021 21:13
@stuartmorgan
Copy link
Contributor

Thanks for picking up this PR! I'll try to take a look in the next week or so.

@BartusZak
Copy link

Looking forward to see that.

nt4f04uNd added a commit to nt4f04uNd/plugins that referenced this pull request Mar 9, 2021
nt4f04uNd added a commit to nt4f04uNd/plugins that referenced this pull request Mar 9, 2021
nt4f04uNd added a commit to nt4f04uNd/plugins that referenced this pull request Mar 9, 2021
Copy link
Contributor

@stuartmorgan stuartmorgan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks really good. Two things it'll need:

  • The platform interface change moved to its own PR
  • Dart tests in the video_player package that ensure that headers passed into the API reach the platform interface (via a mock/fake platform interface implementation)

# the parent directory to use the current plugin's version.
dependency_overrides:
video_player_platform_interface:
path: ../../video_player_platform_interface
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need to be removed, and the PR split into two parts, before landing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't it make sense to keep the override to make anyone cloning the source to work with local copy?

Just like video_player: dependency in the example is declared as path: ../ to point to local copy of video_player package, this would do the same for video_player_platform_interface package

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't it make sense to keep the override to make anyone cloning the source to work with local copy?

There are several issues with that, most notably that it causes the integration tests to run against a configuration that is different from what actual clients of this package would run, making it easy to have a PR pass CI and be landed and published, but break everyone because it doesn't work with the published interface package.

Just like video_player: dependency in the example is declared as path: ../ to point to local copy of video_player package

The example is part of that package. It's an internal reference.

this would do the same for video_player_platform_interface package

Overriding dependencies in a multi-package graph is definitely not the same thing.

Copy link
Contributor Author

@PiN73 PiN73 Mar 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, thanks, I understand the problem now. May it be commented out or should be completely deleted?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't check in commented out code, generally speaking. It's very easy for someone who wants this behavior for temporary testing to re-add it.

Copy link
Contributor Author

@PiN73 PiN73 Mar 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I'll delete it. But the #3702 need to be landed first (if there aren't any other issues in the current PR) because the example won't built otherwise

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deleted it now

frameUpdater:(FLTFrameUpdater*)frameUpdater
httpHeaders:(NSDictionary<NSString*, NSString*>*)headers {
NSDictionary<NSString*, id>* options = nil;
if (headers != NULL) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nil, not NULL

{this.formatHint,
this.closedCaptionFile,
this.videoPlayerOptions,
this.httpHeaders})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will format better if you add a comma after httpHeaders

@PiN73
Copy link
Contributor Author

PiN73 commented Mar 11, 2021

@stuartmorgan I fixed all problems you mentioned except removing dependency_overrides in example app. If I remove it now, the example won't compile. Should #3702 be merged and I remove the override then, right?

@PiN73 PiN73 requested a review from stuartmorgan March 15, 2021 08:59
@PiN73
Copy link
Contributor Author

PiN73 commented Mar 23, 2021

Any additional edits needed from me?

Copy link
Contributor

@stuartmorgan stuartmorgan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the review delay; doing both now.

super(VideoPlayerValue(duration: Duration.zero));

/// The URI to the video file. This will be in different formats depending on
/// the [DataSourceType] of the original video.
final String dataSource;

/// HTTP headers used for the request to the [dataSource].
final Map<String, String>? httpHeaders;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We generally prefer to make collections non-nullable and defaulting to empty, so that we don't have both null and empty as codepaths that mean the same thing (except in cases where null and empty actually mean different things, but that's not true here). It avoids bugs where, e.g., one platform implementation handles them the same, but one fails with one or the other (or treats them differently on accident).

Copy link
Contributor Author

@PiN73 PiN73 Mar 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As pigeon doesn't currently support non-nullable fields, generated fields will be still nullable. If we make headers non-nullable in VideoPlayerController class, should we check for nulls in platform code then or rely that non-nullable value will be passed from Dart?

Copy link
Contributor Author

@PiN73 PiN73 Mar 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I made it non-nullable and empty by default. Also I kept check for null and added check for empty in platform code. So the default behavior is untouched (don't call function that sets headers in native code if no headers were passed). And also, if null will get into platform side somehow, it will be also ignored

@@ -30,6 +30,9 @@ class FakeController extends ValueNotifier<VideoPlayerValue>
@override
String get dataSource => '';

@override
Map<String, String>? get httpHeaders => null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same.

@PiN73 PiN73 requested a review from stuartmorgan March 23, 2021 19:28
stuartmorgan pushed a commit that referenced this pull request Mar 24, 2021
@PiN73
Copy link
Contributor Author

PiN73 commented Mar 25, 2021

Now, as video_player_platform_interface 4.1.0 is published, I removed dependency overrides. Any additional changes needed, @stuartmorgan?

Copy link
Contributor

@stuartmorgan stuartmorgan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

@BartusZak
Copy link

Thank you very much.

I'm going to test it right away :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Video Player plugin - Support HTTP headers
3 participants