Added handlebar to playerview

[newhinton]

No description provided.

[newhinton]

Beofre:

After:

[newhinton]

I have reused the grabber icon, but this could be quickly exchanged, i'm open for suggestions

[newhinton]

That would also look good imho

[newhinton]

i removed the shadow and exchanged the image

[newhinton]

Do we need the audio controls if the queue is open? if we slide it out of the view and only show the handlebar and the queue, we would clear the ui even more

(The lineageOS stock mediaplayer does it this way and it looks quiet nice)

[adrian-bl]

Honestly: i dont think that this looks good.

Can we take a step back to check what problem we try to solve?

[newhinton]

I want to make it very easy (and easily discoverable) to open the queue, which is currently only possible if you know that you can swipe on the cover
the handlebar visually shows that there is something out of the view and makes it easily accessible.

(audible and some other apps do it this way, and i think it is quiet unobstrusive)

Why do you think it does not look good? (what can be changed to make it look good? Is it the size, or the position? or overall?)

[adrian-bl]

I want to make it very easy (and easily discoverable) to open the queue, which is currently only
possible if you know that you can swipe on the cover

Menu -> Show queue -- the animation also gives a hint that you can drag it up.

I do agree that it is not completely obvious, but then i'd rather add a quick tutorial on first launch than adding this permanent bar which wouldn't even work in the library view (where we have multiple stages of expansions)

Why do you think it does not look good? (what can be changed to make it look good? Is it the size,
or the position? or overall?)

I find it distracting and it doesn't seem to add much value.

[newhinton]

What do you mean that it would not work in the library view? It is only visible in the playeractivity and not on the library view, so there is no problem at all

Also, dragging does not really work because the main controls are not draggable. The cover is movable in 3 directions, which can easily intercept the swipe gesture (which is a swipe, not a drag, therefore your hint does not work)

Forcing/Requiring users to read stuff is not at all a good idea :D They simply wont do that, and in the best case, they don't know that this feature exist, worst case, they start complaining :D

it is quiet big and i'm all for reducing it's size, but i don't think that a dialog or a fancy animation would solve this problem

[adrian-bl]

What do you mean that it would not work in the library view? It is only visible in the playeractivity and
not on the library view, so there is no problem at all

But the bottom part is draggable in both views: so why would we only add a handle bar in the playback view?

Also, dragging does not really work because the main controls are not draggable

What do you mean? Dragging works perfectly: i use it all the time.

[newhinton]

Interesting, my handlebar breaks the "normal" dragging

That is indeed a good question, but to be honest: it is more important in the player view

In the library view, you already have all your music available, so you dont nessessarily need the queue at hand.
That is not true for the playbackactivity, there you need quick access to it, which is realized with dragging. (since dragging is already working, it is about showing the user that he can do so)

[newhinton]

@adrian-bl Regardless whether this pr gets merged or not, i would like to fix the handlebar. My understanding of the code/xml files, the sliding-"grip" is attached to a linearlayout, which has the controls as a child. Therefore the child is the element by which the slidingview gets pulled up/down. This means that the layout/childelements of the controls should not influence the sliding-handle.

This is not the case, only my imageview is draggable.

Do you know why this happens and how to solve it/what is causing this behavior?

[newhinton]

Nevermind, i found out how to fix it. However, shouldn't the method that attaches the handler be recursive? and maybe limited by a predefined depth?