-
Notifications
You must be signed in to change notification settings - Fork 9.8k
[video_player] add http headers #3671
[video_player] add http headers #3671
Conversation
… video_player_update_pigeon
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 |
Thanks for picking up this PR! I'll try to take a look in the next week or so. |
Looking forward to see that. |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 aspath: ../
to point to local copy ofvideo_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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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}) |
There was a problem hiding this comment.
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
packages/video_player/video_player_platform_interface/lib/messages.dart
Outdated
Show resolved
Hide resolved
@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? |
Any additional edits needed from me? |
There was a problem hiding this 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; |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same.
platform_interface portion of #3671
Now, as video_player_platform_interface 4.1.0 is published, I removed dependency overrides. Any additional changes needed, @stuartmorgan? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
Thank you very much. I'm going to test it right away :) |
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
[shared_preferences]
///
).