Fixed
Status Update
No update yet.
Comments
am...@google.com
I'm going to leave this here as well, for reference: http://stackoverflow.com/questions/40171801/bottomnavigationview-hides-when-scrolling-up-instead-of-down
In my use case, the BottomNavigationView is inside a fragment, inside a FrameLayout which is contained in a CoordinatorLayout and the scroll to hide technique works, but in reverse compared to how it's supposed to work. Using the BottomNavigationView directly inside the CoordinatorLayout doesn't have any scroll behavior though.
In my use case, the BottomNavigationView is inside a fragment, inside a FrameLayout which is contained in a CoordinatorLayout and the scroll to hide technique works, but in reverse compared to how it's supposed to work. Using the BottomNavigationView directly inside the CoordinatorLayout doesn't have any scroll behavior though.
an...@gmail.com
I'm having the same issue. There is an estimation when this issue will be fixed?
am...@google.com
This has been released in support library 25.0.1.
d....@gmail.com
Scroll behavior is still missing. For those that are looking for one, sample project archive contains it.
d....@gmail.com
Elevation part was fixed. Still working on the behavior.
am...@google.com
Elevation is broken if you use app:itemBackground rather than android:background since it's setting the elevation on itself rather than mMenuView. Why is itemBackground exposed? Should I not just use android:background?
d....@gmail.com
[Comment deleted]
do...@gmail.com
Set transparent color for app:itemBackground and use solid color on the BottomNavigationView background. That would be the only way to see the elevation, otherwise the top most parent (BNV) will not draw the elevation onto which you are applying elevation, since it doesnt have solid background.
If android:background is used on < 21, shadow is overlaid over the background. Elevation does not cast upward shadow, does it? So the method addCompatibilityTopDivider() in current 25.0.1 should be available for all versions.
If android:background is used on < 21, shadow is overlaid over the background. Elevation does not cast upward shadow, does it? So the method addCompatibilityTopDivider() in current 25.0.1 should be available for all versions.
gi...@gmail.com
app:itemBackground is meant to be used for adding ripples/pressed state. By default it just has a round ripple. To set the background color for you should use android:background, once you do so you will see the shadow on API 21+ above BottomNavigationView (just using elevation) and for pre API 21 we add a simple 1dp divider to separate it from the background as elevation does not exist in these platforms.
Am I missing something?
Am I missing something?
tw...@gmail.com
You can't cast shadow to the top. I tried to add android:elevation="40dp" and android:elevation="8dp" on a solid background but still I was unable to see the shadow cast on the top, shadow is cast only below the BNV (this is perfectly normal). Given this, I said that top divider should be available for all version to achieve top shadow.
mr...@gmail.com
I was just confused by what app:itemBackground was for, but that makes sense. thanks!
[Deleted User] <[Deleted User]>
When is the scrolling behavior planned to be released?
[Deleted User] <[Deleted User]>
I have updated to the new Support Library version (25.1.0) and I still see no shadow above the BNV, see attached screenshot.
<android.support.design.widget.BottomNavigationView
android:elevation="40dp"
android:id="@+id/bottom_navigation"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_alignParentBottom="true"
android:background="@color/darkestGray"
app:itemIconTint="@drawable/nav_item_color_state"
app:itemTextColor="@drawable/nav_item_color_state"
app:menu="@menu/bottom_navigation_widget" />
<android.support.design.widget.BottomNavigationView
android:elevation="40dp"
android:id="@+id/bottom_navigation"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_alignParentBottom="true"
android:background="@color/darkestGray"
app:itemIconTint="@drawable/nav_item_color_state"
app:itemTextColor="@drawable/nav_item_color_state"
app:menu="@menu/bottom_navigation_widget" />
[Deleted User] <[Deleted User]>
Updated to 25.1.0. Shadow doesn't displayed.
<android.support.design.widget.BottomNavigationView
android:id="@+id/bottom_navigation"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_alignParentBottom="true"
android:background="@color/colorPrimary"
android:elevation="8dp"
app:elevation="8dp"
app:itemIconTint="@drawable/bottom_nav_color_state"
app:itemTextColor="@drawable/bottom_nav_color_state"
app:menu="@menu/bottom_navigation_main"/>
<android.support.design.widget.BottomNavigationView
android:id="@+id/bottom_navigation"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_alignParentBottom="true"
android:background="@color/colorPrimary"
android:elevation="8dp"
app:elevation="8dp"
app:itemIconTint="@drawable/bottom_nav_color_state"
app:itemTextColor="@drawable/bottom_nav_color_state"
app:menu="@menu/bottom_navigation_main"/>
[Deleted User] <[Deleted User]>
is the shadow and scrolling behavior has been added?
Description
Version used: 25.1.0
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: every devices I tested on, for example : Sony Xperia Z3 tablet, Samsung Galaxy Tab S2.
It seems related to other issues being reported about fragment replace transactions, but this one does not use the replace method.
Steps to reproduce :
- Add a fragment with a simple transaction :
getSupportFragmentManager()
.beginTransaction()
.setCustomAnimations(android.R.anim.fade_in, android.R.anim.fade_out)
.add(R.id.fragment_container, new TestFragment())
.commit()
- Remove the fragment using a simple remove, and just after start a new activity :
final Fragment fragment = getSupportFragmentManager().findFragmentById(R.id.fragment_container);
if (fragment != null) {
getSupportFragmentManager()
.beginTransaction()
.setCustomAnimations(android.R.anim.fade_in, android.R.anim.fade_out)
.remove(fragment)
.commit();
startActivity(new Intent(this, MainActivity.class));
}
- Go back to the old activity
What should happen : the fragment that was added should not be here anymore.
What happens : the fragment is still here. But the thing is it's only some sort of "ghost view" : it's impossible to reach it in debug using the view hierarchy. I even tried to activate the debug option "show layout bounds", which does not shows the bound on the fragment view. The view is not clickable, if I call removeAllViews() on the container it's still here.
Another thing : even with this view still here, if I re-add a fragment it will be added below the "ghost view". Everything works, but the old view is still here.
I attached a sample project to reproduce this issue. The "remove fragment" button is just here to validate the behaviour without starting another activity. You can see the bug using :
- "Add fragment"
- "Remove fragment and start activity"
- Press the back button
The old fragment is still here. If you press the add fragment button, another fragment will appear behing the old fragment, which should not be possible.
If you use the "show layout bounds" option, the bug is really visible :
- Start from scratch (kill the app)
- "Add fragment"
- Enable the "show layout bounds" option.
- "Remove fragment and start activity"
- Press the back button
Here everything seems normal except for the fragment still being here. But if you disable the "show layout bounds" option, the fragment view will stay unchanged, with layout bounds displayed. As if it were a cached view not recognized by the system.
I also attached a screenshot of this behavior. You can see the "show layout bounds" option is disabled, but it still shows on the fragment view.
All this does not happen with support lib 25.0.1.