|Project Name||Stars||Downloads||Repos Using This||Packages Using This||Most Recent Commit||Total Releases||Latest Release||Open Issues||License||Language|
|Custombottomsheetbehavior||851||2 years ago||35||apache-2.0||Java|
|Custom BottomSheetBehavior for Android that mimic Google Maps behavior|
|Shrine Materialdesign2||210||5 years ago||apache-2.0||Kotlin|
|implementation of Material Design 2 Shrine project|
|Google Maps Bottomsheet||65||5 years ago||4||unlicense||Java|
|A BottomSheetBehavior framework mirroring Google Maps'|
|Like Google Maps||22||5 years ago||other||Java|
|Proof of concept to create a coordinator layout behavior that mimics the bottomsheet behvior in the Google Maps app.|
|Bottomsheetbehavior||12||4 years ago||apache-2.0||Kotlin|
|BottomSheetBehavior is an android library extracted from the Google I/O 2018 application source code.|
|Flutter_maps_sample||4||4 years ago||Dart|
|Flutter application using Google Maps, Get Current Location (Devices), Markers, Camera Position, Bottom Sheet, DraggableScrollableSheet, etc 🔥|
Proof of concept; Google Maps like bottomsheet behavior
To achieve the final bottomsheet'esque behavior, the orginal source for the bottomsheet behavior in the Android Design Library was copied, studied, and edited (arguably butchered). The orginal source didn't handle flings and / or transient states, as in, the bottomsheet was either hidden, collapsed or expanded. After any touch / drag interaction, the sheet would snap to a then determined state.
Many different attempts led to unforeseen caveats and some unwanted side effects to overcome, particularly around nested scrolling and the allowance of a "sticky header". The inner workings of coordinator layout needed to be understood. A must watch video, takes a pretty deep dive into the inner workings of nested scrolling and CoordinatorLayout Behaviors. This article by Alex Lockwood on nested scrolling and some borrowed code allowed me to finally achieve the end goal.
The end result is a custom bottomsheet behavior that allows for an optional custom header. Snap can be enabled or disabled, as well as the peek height can be set to either auto, header (height of the header) or a custom value(dp's). As with the original behavior, a flag exists for hideable. I also added a configurable topOffset to prevent expanding past a certain y value.
One important takeaway from this experiment is that if you are creating your own behavior, it usually means the default behaviors in the Design Library are not accommodating to your requirements. So, likely, your end result will be specific to your app's design and flow. We all strive to write robust and resuable code, and that principle should be applied to custom views and behaviors as well, but beware of the cost. The more customizations and options you allow and provide, the more complex your behavior becomes. You need to account for all permutations of state that can occur, and manage those.
|peek=header; snap||peek=header; no snap|
|peek=auto; snap||peek=auto; snap; hideable|