Fixed
Status Update
No update yet.
Comments
an...@backx.org
since these are in public API (:/) we need to do this in 1.2
il...@google.com
since it is already marked as deprecated, we can probably do it by now.
an...@backx.org
Opening diff shortly
il...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/61 .
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
https://android-review.googlesource.com/1396827
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request from
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
an...@backx.org
> What you need to do manually right now is ensure that your Fragment destination hosting your nested NavHostFragment tells its parent FragmentManager (the one returned by requireFragmentManager()) that it wants system back button presses.
This is what I was looking for, my apologies for the confusion. I couldn't find anywhere how to get the parent FragmentManager to allow its children to receive back button presses. We currently went with multiple activities for multiple navigation graphs, but are still interested in this.
> I'll reopen this to evaluate if it would be possible to call setPrimaryNavigationFragment as part of FragmentNavigator's operations to remove the manual step.
Regardless of whether this will be done, could more documentation be added in the future regarding nested NavHostFragments? I'd also appreciate some deeper documentation, how it handles the transactions and works with the fragment manager behind the scenes.
This is what I was looking for, my apologies for the confusion. I couldn't find anywhere how to get the parent FragmentManager to allow its children to receive back button presses. We currently went with multiple activities for multiple navigation graphs, but are still interested in this.
> I'll reopen this to evaluate if it would be possible to call setPrimaryNavigationFragment as part of FragmentNavigator's operations to remove the manual step.
Regardless of whether this will be done, could more documentation be added in the future regarding nested NavHostFragments? I'd also appreciate some deeper documentation, how it handles the transactions and works with the fragment manager behind the scenes.
be...@google.com
Joshua, we can triage these nav doc bugs I'm assigning together when I'm back.
il...@google.com
We've updated FragmentNavigator such that it always sets the current Fragment as the primary navigation fragment and the change will be available in alpha05.
This means that nesting NavHostFragments that use app:defaultNavHost="true" will 'just work' when it comes to the system back button - the inner NavHostFragment's back stack will be cleared before the outer NavHostFragment is popped.
This means that nesting NavHostFragments that use app:defaultNavHost="true" will 'just work' when it comes to the system back button - the inner NavHostFragment's back stack will be cleared before the outer NavHostFragment is popped.
il...@google.com
And by alpha05, I mean alpha04. Getting ahead of myself :)
an...@backx.org
This is great to hear. I'm curious as to what is recommended when for example you need to navigate between screens with different BottomNavigationViews. Is it recommended to have separate activities or nested NavHostFragments? If it's NavHostFragments, how should this best be achieved? Would love some added documentation on this in time for alpha04.
Also thank you very much for the quick responses on the issue!
Also thank you very much for the quick responses on the issue!
il...@google.com
Per the material design guidelines (https://material.io/design/components/bottom-navigation.html ), bottom navigation bars should be consistent and appear on the bottom on every screen so changing the BottomNavigationView isn't really a recommended pattern.
ra...@gmail.com
1.0.0-alpha04 introduces a new bug where using a BottomNavigationBar 'NavigationUI.setupWithNavController(bottom_bar, navController)' results in the BottomNavBar not being synchronized.
The selected tab icon is not set when the fragment changes, it stays on the last icon that was tapped.
The selected tab icon is not set when the fragment changes, it stays on the last icon that was tapped.
Description
Version used: 1.0.0-alpha02
Devices/Android versions reproduced on: Nexus 5, OnePlus One
We want to implement nested NavHostFragments because we want to navigate between 2 screens that each have 2 different Bottom Navigation Bars. We also thought about nesting NavHostFragments so we can bind ViewModels to a navigation part of our app. Parts that need to clean up the data they were using after being navigated through. The problem we're facing is that the outer most NavHostFragment intercepts the back button navigation before the child NavHostFragments do. The result is that when pressing the back button, it completely goes back to the destination before the child NavHostFragment. Are there any plans to support nesting NavHostFragments or is there a different solution to nested navigation that is seemingly not supported by nesting navigation graphs because I don't see how you can for example navigate between fragments with different Bottom Navigation Bars and navigate the fragments that belong to the Bottom Navigation Bar?