Why the layout? about bottomsheet HOT 11 CLOSED

Functionally speaking, how would you propose this be handled as a dialog? It's built this way right now so that you can have the content view interact with its movements accordingly, and it's not much work to stuff this down into a base activity.

from bottomsheet.

Going to close this for now, we can revisit if others have some good suggestions for how to implement a dialog approach while maintaining interaction with the content view

from bottomsheet.

Just a thought here, but perhaps bottomsheet could be refactored to use Google's CoordinatorLayout its Behavior implementation for scrolling. Since this library is trying to aid in material design support having the design support lib as a dependency wouldn't be bad I don't think.

from bottomsheet.

How would that work implementation-wise? I'm not too familiar with
CoordinatorLayout yet
On Fri, Jul 24, 2015 at 9:04 AM Nathan Schwermann [email protected]
wrote:

Just a thought here, but perhaps bottomsheet could be refactored to use
Google's CoordinatorLayout its Behavior implementation for scrolling. Since
this library is trying to aid in material design support having the design
support lib as a dependency wouldn't be bad I don't think.

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

from bottomsheet.

CoordinatorLayout is a ViewGroup that looks at every child's layout params for a Behavior. The Behavior tells the CoordinatorLayout how that childview should interact with other views and handles nested scrolling and other things.

For example, when you add a FloatingActionButton to a CoordinatorLayout it finds FAB's default Behavior attached and uses it to move the button on the screen based off of its anchor View, or to animate and hide if it gets too close to the Toolbar.

What I'm suggesting for bottomsheet is instead of BottomSheetLayout being a top level view it would be refactored into a view that implements a default Behavior. That would help avoid nesting so many containers like the pseudo XML below required to support both FAB and Bottomsheet in a single view.

<!--Bottomsheet must be the outer most view because it can only have one child -->
<com.flipboard.bottomsheet.BottomSheetLayout>
       <android.support.design.widget.CoordinatorLayout>
          <!--Toolbar, Content, FAB, etc all goes here.  BottomSheetLayout replacement here as well instead>
       </android.support.design.widget.CoordinatorLayout>

</com.flipboard.bottomsheet.BottomSheetLayout>

from bottomsheet.

Right, I did understand that much. It's behavior implementations themselves
that I'm not too knowledgable on. Are they flexible enough allow for the
same API? Allowing for custom ViewTransformer implementations to interact
with the content view is a must for us.

On Fri, Jul 24, 2015 at 9:47 AM Nathan Schwermann [email protected]
wrote:

CoordinatorLayout is a ViewGroup that looks at every child's layout params
for a Behavior
https://developer.android.com/reference/android/support/design/widget/CoordinatorLayout.Behavior.html.
The Behavior tells the CoordinatorLayout how that childview should interact
with other views and handles nested scrolling and other things.

For example, when you add a FloatingActionButton to a CoordinatorLayout it
finds FAB's default Behavior attached and uses it to move the button on the
screen based off of its anchor View, or to animate and hide if it gets too
close to the Toolbar.

What I'm suggesting for bottomsheet is instead of BottomSheetLayout being
a top level view it would be refactored into a view that implements a
default Behavior. That would help avoid nesting so many containers like the
pseudo XML below required to support both FAB and Bottomsheet in a single
view.

<com.flipboard.bottomsheet.BottomSheetLayout>
<android.support.design.widget.CoordinatorLayout>
<!--Toolbar, Content, FAB, etc all goes here. BottomSheetLayout replacement here as well instead>
</android.support.design.widget.CoordinatorLayout>

</com.flipboard.bottomsheet.BottomSheetLayout>

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

from bottomsheet.

I'm not following you on the requirement for ViewTransformer implementations. But I don't think your API would change at all, only the requirement for a top-level view. But thinking about it I suppose there is no reason your BottomSheetLayout needs to be top level either, I suppose it could still be moved inside the CoordinatorLayout in my example above. I guess to that point moving to Behavior doesn't really change anything, just a different way of solving the same problem.

from bottomsheet.

This is what I'm referring to

We have to be able to maintain that level of control for the animation.

I agree though that the simple solution would just be to move it inside of CoordinatorLayout, and probably what I'd rather suggesting for now unless CoordinatorLayout offers us some useful API to improve/simplify this logic.

from bottomsheet.

I would like to add something about this. I'm currently using a CoordinatorLayout and an AppBarLayout. I'm using the app:layout_behavior="@string/appbar_scrolling_view_behavior" so when I scroll down, the toolbar hides. Using the BottomSheetLayout as root is not an option because then the expanded view would go on top of the toolbar leaving no space for the user to click outside of the BottomSheet (as Google guidelines say). What I did was putting the layout under the AppBarLayout, wrapping the content. This creates another problem.

Let me explain how app:layout_behavior="@string/appbar_scrolling_view_behavior" works. When you scroll down, the toolbar goes up as well as the childs that use this behavior. When you scroll up, the toolbar comes down and those childs also come down (going offscreen or under the Android virtual buttons). With this behavior the contents height ignores the toolbar height because it will be moved up when the toolbar hides.

The problem is that going offscreen means that the last element present on the BottomSheet list is going to be hidden. I couldn't find a decent solution for this yet. What I'm currently doing is adding an empty MenuItem so it pulls the real items up. And then on the onClickListener I ignore that empty item.

from bottomsheet.

I don't have much experience with CoordinatorLayout but could you not just
place the BottomSheetLayout in the root view of your content?

Also I think your comment about the design guidelines is incorrect. Google
has plenty of examples of full screen bottom sheets covering the whole
view. It's intuitive enough that users know they can drag or press back to
dismiss it. If you really must leave space above, you can set a custom peek
height or use LayoutParams to set your desired expanded height.

Code samples would really help here if you have one.
On Wed, Feb 17, 2016 at 9:43 AM Ricardo [email protected] wrote:

I would like to add something about this. I'm currently using a
CoordinatorLayout and an AppBarLayout. I'm using the
app:layout_behavior="@string/appbar_scrolling_view_behavior" so when I
scroll down, the toolbar hides. Using the BottomSheetLayout as root is not
an option because then the expanded view would go on top of the toolbar
leaving no space for the user to click outside of the BottomSheet (as
Google guidelines say). What I did was putting the layout under the
AppBarLayout, wrapping the content. This creates another problem.

Let me explain how
app:layout_behavior="@string/appbar_scrolling_view_behavior" works. When
you scroll down, the toolbar goes up as well as the childs that use this
behavior. When you scroll up, the toolbar comes down and those childs also
come down (going offscreen or under the Android virtual buttons). With this
behavior the contents height ignores the toolbar height because it will be
moved up when the toolbar hides.

The problem is that going offscreen means that the last element present on
the BottomSheet list is going to be hidden. I couldn't find a decent
solution for this yet. What I'm currently doing is adding an empty MenuItem
so it pulls the real items up. And then on the onClickListener I ignore
that empty item.

—
Reply to this email directly or view it on GitHub
#9 (comment)
.

from bottomsheet.

Wouldn't NestedScrollLayout be a better choice (handling ScrollEvents correctly and stuff)

from bottomsheet.