Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
since these are in public API (:/) we need to do this in 1.2
ch...@gmail.com <ch...@gmail.com> #3
since it is already marked as deprecated, we can probably do it by now.
ch...@gmail.com <ch...@gmail.com> #5
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
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
commit 2560e8fa99d8e13c5907375e69759520fefc8dd5
Author: Ian Lake <ilake@google.com>
Date: Wed Jan 19 00:36:30 2022
Fix getViewModelStore() prior to ON_CREATE
The intention is that the ViewModels associated
with a NavBackStackEntry cannot be accessed prior
to the NavBackStackEntry being added to the
NavController. We were previously using the ON_CREATE
event to signify when this happens, but in fact there are
cases, such as in a Fragment's onCreate(), where a
NavBackStackEntry can be retrieved from the NavController
*before* the Lifecycle reaches CREATED (due to how
fragment lifecycle callbacks relate to Lifecycle changes).
By performing the restore exactly once the first time
updateState() is called, we ensure that ViewModels are
accessible immediately after being added to the NavController.
Test: updated test suites
BUG: 213504272
Relnote: "Fixed an issue where accessing a ViewModel created
via `by navGraphViewModels()` from a Fragment's `onCreate()`
would fail with an `IllegalStateException`."
Change-Id: I8a14dd596195d4ddfa8199c8023a7aedcd286113
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/NavHostFragmentTest.kt
https://android-review.googlesource.com/1953802
Branch: androidx-main
commit 2560e8fa99d8e13c5907375e69759520fefc8dd5
Author: Ian Lake <ilake@google.com>
Date: Wed Jan 19 00:36:30 2022
Fix getViewModelStore() prior to ON_CREATE
The intention is that the ViewModels associated
with a NavBackStackEntry cannot be accessed prior
to the NavBackStackEntry being added to the
NavController. We were previously using the ON_CREATE
event to signify when this happens, but in fact there are
cases, such as in a Fragment's onCreate(), where a
NavBackStackEntry can be retrieved from the NavController
*before* the Lifecycle reaches CREATED (due to how
fragment lifecycle callbacks relate to Lifecycle changes).
By performing the restore exactly once the first time
updateState() is called, we ensure that ViewModels are
accessible immediately after being added to the NavController.
Test: updated test suites
BUG: 213504272
Relnote: "Fixed an issue where accessing a ViewModel created
via `by navGraphViewModels()` from a Fragment's `onCreate()`
would fail with an `IllegalStateException`."
Change-Id: I8a14dd596195d4ddfa8199c8023a7aedcd286113
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/NavHostFragmentTest.kt
il...@google.com <il...@google.com> #7
We've fixed this issue internally and it will be available in the upcoming Navigation 2.5.0-alpha01 and Navigation 2.4.1 releases.
Description
I have two Activities, MainActivity and SecondActivity. Using Navigation architecture in MainActivity, which has two fragments, such as HomeFragment and DetailFragment, the Navigation diagram is declared as follows:
Generate ViewModels in the DetailFragment onCreate with "by navGraphViewModels".
There is a button in DetailFragment, clicking it will jump to SecondActivity, when "Do not keep background Activity" is enabled, pressing the back button in SecondActivity will trigger the program crash:
If I put the vm creation declaration in the onViewCreated lifecycle or later, there will be no crashes.
Does "by navGraphViewModels" necessarily require the user to use it this way?
In my opinion, as long as the NavBackStackEntry viewModelStore corresponding to "R.id.navigation_home_flow" is in the CREATED state, it's OK, not the DetailFragment.
The Navigation version I use is 2.4.0-alpha06.
Thanks in advance if you can address my issue.