Major rework to player

[Luna712]

This practically rebuilds the entire player (sans IPlayer/CS3IPlayer), aimed to remove the FullScreenPlayer inheritance from ResultFragmentPhone, use BaseFragment for ResultFragmentPhone and the player, and make the player easier to maintain and expand in the future, as well overall cleanup to code readability and adding documentation to methods in the player. Also aimed to not fully crash if the layouts have minor differences as well.

Eventually FullScreenPlayer could be entirely factored out into helper methods for GeneratorPlayer, and AbstractPlayerFragment removed completely, but to reduce the chance of harder to resolve merge conflicts with removed files, I decided to not do it in this PR.

[Luna712]

This is mostly ready for review. Though there may still be a few bugs since I wrote a lot of the code from scratch in many places (some of the code is stuff I worked on ~6 months ago, for about two months but gave up as I ran into some issues I couldn't figure but finally finished it and expanded to all the new features since then now).

If you feel this should be done a different way I could do that also, but this was just designed to make it easier in the future.

[fire-light42]

I have not looked in-depth at each line yet, given the sheer magnitude of this diff. It is hard to keep track of what is refactored, moved or unchanged. However, I like what I see so far.

[fire-light42]

Very good pull request! I did not find any big glaring issues in the code or when testing.

The only bugs I found was:

1. player_video_title_rez is not hidden when locked
2. Brightness and volume sliders are still accessible when locked
3. player_metadata_scrim is visible on trailers on phone

Please also note that while your formatting is great, it is not standard to android studio, and will cause the next person to touch the file to get +-500. Please format it with android studio or figure out some setting to disallow it on these files.

I have also noticed that you removed a lot of comments, I am fine if you reword it. However, functions like verifyVolume lose context of why it is done, similar for currentZoomMatrix, and for the comments in createScaleGestureDetector. You should never remove a "why" comment, as it makes it harder to read the code later and understand the decision, intent, and why something else is not done.

To be clear, doc comments that explain the "what" is done, e.g. functionally is entirely free to update, as they do not contain any inherit information that can not be gleaned from the code.

While the clean code book is not perfect, and has a lot of misguided advice, the comments sections is worth reading: https://bitsyncvortex.github.io/Books/pdfs/ComputerScience/CleanCode.pdf page 55+

[Luna712]

Thank you for the review! I will try and finish this up tomorrow.

[Luna712]

Is "player_video_title_rez is not hidden when locked" an issue on pre as well? I don't see where it hides on pre either. I can fix it here though anyway and may be just missing it.

Also not sure what you mean by "Please also note that while your formatting is great, it is not standard to android studio, and will cause the next person to touch the file to get +-500. Please format it with android studio or figure out some setting to disallow it on these files."

Because I wrote it within Android Studio in the first place and it does not try to reformat or anything.

[Luna712]

The 3 bugs mentioned should be fixed now. Comments restored as well. Still not sure what was meant by formatting though.

Also, another side effect of this now is trailer_custom_layout should be able to be its own thing. It will no longer cause inflation errors if deviating from the other player layouts and the other player layouts no longer need anything only used in trailer either. I could do a follow-up PR to clean this up if wanted unless you want to still keep it exactly in sync even though no longer needed?

[fire-light42]

The 3 bugs mentioned should be fixed now. Comments restored as well.

What I gave as examples is fixed, but there is comments in almost every function and around them that has been removed.

It is very inconstant with what comments are removed and what is not. Please go through every comment in the entire pull request you removed and add them back within reason. Even small comments like // +- 5% that should be self evident when reading 0.05f makes it easier to parse, as kotlin does not always have great typing for units.

Still not sure what was meant by formatting though.

It looks like you have use a different code formatter, I tried to find some online formatter to compare but it looks every code formatter for kotlin is custom and there is no standard. However in general it looks like you:

open fun f() {
    throw NotImplementedError() // This is the general kotlin style in CloudStream
}

vs

open fun f() { throw NotImplementedError() } // This is not

And have code like bindViews that adds a lot of space to make it line up:

exoDuration                  = root.findViewById(androidx.media3.ui.R.id.exo_duration)
exoFfwdText                  = root.findViewById(R.id.exo_ffwd_text)

Please check your settings in android studio ❤️

[Luna712]

@fire-light42 fixed comments (hopefully I didn't miss any...) and formatting as best I could. My PC broke down yesterday so I was more so guessing what it should look like now, I will get a new PC within the next couple weeks, but can't actually see what Android Studio does again right now or check my settings there. If you want, feel free to commit to this, or can wait until I get a new PC again, but I hope it doesnt create massive merge conflicts in the meantime... I do apologize for that bit of inconvenience with this.

Most of the formatting now though aligns with at least some other parts of the app, so if it still has issues, other unrelated parts could probably use some formatting fixes eventually as well.

[fire-light42]

Very good changes, unfortunately I found another bug. You updated the function isValidTouch, and now it is not working at all. Please revert that function. Otherwise this is mergable, which is surprising for such a large pull request. The code is really good, compared to what we have now.

[Luna712]

Very good changes, unfortunately I found another bug. You updated the function isValidTouch, and now it is not working at all. Please revert that function. Otherwise this is mergable, which is surprising for such a large pull request. The code is really good, compared to what we have now.

@fire-light42

Can you please provide reproduction steps so I can test this when I fix it? What do you do that isn't working properly?

[fire-light42]

Can you please provide reproduction steps so I can test this when I fix it? What do you do that isn't working properly?

Swiping to pull up the system UI from both the top and right when in horizontal mode seeks the video or changes the brightness/volume. We purposefully invalidate those touches for better UX, but this pull request allows all touches, even those opening the system UI.

[fire-light42]

I also want to add that while you fixed the trailer popup issue, it still hides the seekbar when paused in a few sec. Just hiding the view is not enough.

[Luna712]

I also want to add that while you fixed the trailer popup issue, it still hides the seekbar when paused in a few sec. Just hiding the view is not enough.

Fixed

[Luna712]

Can you please provide reproduction steps so I can test this when I fix it? What do you do that isn't working properly?

Swiping to pull up the system UI from both the top and right when in horizontal mode seeks the video or changes the brightness/volume. We purposefully invalidate those touches for better UX, but this pull request allows all touches, even those opening the system UI.

This should now be fixed as well.

[fire-light42]

Do not forget the getter.

class X {
    var x : Int? = null
    val x_default : Int? = x
    val x_get : Int? get() = x
}


fun main() {
    val x = X()
    x.x = 123
    println(x.x_default) // <-- null
    println(x.x_get)     // <-- 123
}

[Luna712]

@fire-light42 I was wondering your thoughts about my future plans (as in future PR(s)) for this as well:

• Move all player helper classes into a new player/helper directory for organization
• Factor FullScreenPlayer out fully into helper methods
• Remove AbstractPlayerFragment entirely
• Rename GeneratorPlayer to GeneratorPlayerFragment and make it the main fragment, extending BaseFragment directly and using the helper methods factored out of FullScreenPlayer to reduce inheritance tree
• Seperate all trailer player logic from ResultFragmentPhone directly into ResultTrailerPlayer, and move ResultTrailerPlayer to a new class called PhoneTrailerPlayerFragment (or something similar that is not final) in the player directory
• Add a new callback implementation to ResultFragmentPhone so that the new trailer fragment can manipulate the parent UI visibility etc... without so much inheritance and fully separated fragments just using BaseFragment directly
• Remove everything not actually used in trailer from trailer_custom_layout (as it is no longer necessary to exactly match the other layouts), and likewise remove everything (if anything) only used in trailer from other player layouts to reduce some complexity if possible

My goal with these current plans is to make things clearer and easier to manage and find where things come from then going down the rabbit hole of so much inheritance, unnecessarily, give the player code where it is actually used (especially for the trailer), and make it more consistent with how all other fragments work. I originally planned a lot of this as part of this PR as well, but decided to reduce it as it was already large enough and these could be better split out into other PRs.

I just wanted some thoughts in this future plan I was currently thinking though before doing it after this is merged, so I don't do it if the architecture design is not good with you.

Also noting if I do this I will try not to do so while large PRs are open touching these areas, as I dont want to create harder to resolve merge conflicts with deleted/renamed classes for others or myself in those PRs doing it also.