Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I think this solution is short-sighted and generally incorrect (even if it does what it says). Why? Because if some other ever-present component that handles input gets added to the carousel, or an existing one starts to handle it, you'll have to add this hack local to that other component too.
I'd say this should be fixed at the carousel level if at all possible and not here. Via overriding
ShouldBeConsideredForInput()
. Something like so (quick and dirty):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.
At the point of doing this I'd probably explore making the displays update nicely when coming into view as I proposed.
I think it's optimal if they should some animation when they come back on-screen (if there's something they can animate since last time).
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.
Not sure I get where this is coming from? It's not like the above is some horrible eldritch hack no? Certainly no more than what this PR currently is.
I dunno if I agree with that either. Not sure how you do it with something like the breakdown without it just spamming texts.
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 in, if we can avoid
AlwaysPresent
altogether none of this needs to exist.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.
Can show the last n scores with a delay between each.
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.
Your concern is valid. I tend to avoid overcomplicating things whenever possible, but I admit I was too lenient in this case. I would've agreed on going with the diff above as alternative to the solution in my PR, but I realise now that this whole situation has already been addressed in #29187.
If we want to bring back the concept of updating screen while hidden, we can also consider turning all feeds to
VisibilityContainer
s as an alternative option to the diff above, as that disables input handling based onVisibility
state rather than the direct drawable presence. Something for later.