Fixed
Status Update
Comments
[Deleted User] <[Deleted User]> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
ka...@gmail.com <ka...@gmail.com> #3
[Deleted User] <[Deleted User]> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically ( b/140759491 ).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
https://android-review.googlesource.com/1288456
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
ca...@gmail.com <ca...@gmail.com> #5
Any suggestions for a workaround until an official solution is released? The only way I can think of is break my nav_graph into graphs that match the scope that I want for my viewmodel, but then that becomes inflexible since I might want to share viewmodels across different graphs.
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-master-dev
commit a57c661958456fc4782121ec37858fd767d5d2f2
Author: jbwoods <jbwoods@google.com>
Date: Mon Mar 25 17:29:53 2019
Class ViewModelLazy class to take a ViewModelStoreProducer
Changed ViewModelLazy to take a ViewModelStoreProducer instead of a
ViewModelStoreOwner making the class more generic.
Test: ran FragmentViewModelLazy, ActivityViewModelLazy, and
ViewModelProvider test.
./gradle checkApi
BUG: 111614463
Change-Id: I111b4df94cd6c8b272a2fec89a66de86616aa1ad
M activity/ktx/src/main/java/androidx/activity/ActivityViewModelLazy.kt
M fragment/ktx/api/1.1.0-alpha06.txt
M fragment/ktx/api/current.txt
M fragment/ktx/src/main/java/androidx/fragment/app/FragmentViewModelLazy.kt
M lifecycle/viewmodel/ktx/api/2.1.0-alpha04.txt
M lifecycle/viewmodel/ktx/api/current.txt
M lifecycle/viewmodel/ktx/src/main/java/androidx/lifecycle/ViewModelProvider.kt
M lifecycle/viewmodel/ktx/src/test/java/androidx/lifecycle/ViewModelLazyTest.kt
https://android-review.googlesource.com/932932
https://goto.google.com/android-sha1/a57c661958456fc4782121ec37858fd767d5d2f2
Branch: androidx-master-dev
commit a57c661958456fc4782121ec37858fd767d5d2f2
Author: jbwoods <jbwoods@google.com>
Date: Mon Mar 25 17:29:53 2019
Class ViewModelLazy class to take a ViewModelStoreProducer
Changed ViewModelLazy to take a ViewModelStoreProducer instead of a
ViewModelStoreOwner making the class more generic.
Test: ran FragmentViewModelLazy, ActivityViewModelLazy, and
ViewModelProvider test.
./gradle checkApi
BUG: 111614463
Change-Id: I111b4df94cd6c8b272a2fec89a66de86616aa1ad
M activity/ktx/src/main/java/androidx/activity/ActivityViewModelLazy.kt
M fragment/ktx/api/1.1.0-alpha06.txt
M fragment/ktx/api/current.txt
M fragment/ktx/src/main/java/androidx/fragment/app/FragmentViewModelLazy.kt
M lifecycle/viewmodel/ktx/api/2.1.0-alpha04.txt
M lifecycle/viewmodel/ktx/api/current.txt
M lifecycle/viewmodel/ktx/src/main/java/androidx/lifecycle/ViewModelProvider.kt
M lifecycle/viewmodel/ktx/src/test/java/androidx/lifecycle/ViewModelLazyTest.kt
ap...@google.com <ap...@google.com> #7
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 1e09fdb1e5ce72359698bf5fa37e31a931e8c575
Author: jbwoods <jbwoods@google.com>
Date: Mon Mar 25 22:36:00 2019
Add ViewModel support at NavGraph scope
Allows users to get a ViewModelStore for a NavGraph. The ViewModelStore
is retrieved using the graph ID. Only NavGraphs on the NavController
back stack can create a ViewModelStore.
Test: New Tests and reran NavControllerTest
./gradlew checkApi
BUG: 111614463
Change-Id: Ib60bb0eda2c1dc9d2cd5a5aa132162105d172b68
M navigation/common/src/main/java/androidx/navigation/NavBackStackEntry.java
M navigation/fragment/ktx/api/2.1.0-alpha02.txt
M navigation/fragment/ktx/api/current.txt
M navigation/fragment/ktx/build.gradle
A navigation/fragment/ktx/src/androidTest/java/androidx/navigation/fragment/NavGraphViewModelLazyTest.kt
A navigation/fragment/ktx/src/main/java/androidx/navigation/NavGraphViewModelLazy.kt
M navigation/fragment/src/main/java/androidx/navigation/fragment/NavHostFragment.java
M navigation/runtime/api/2.1.0-alpha02.txt
M navigation/runtime/api/current.txt
M navigation/runtime/build.gradle
M navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
A navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerViewModelTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
A navigation/runtime/src/main/java/androidx/navigation/NavControllerViewModel.java
https://android-review.googlesource.com/932046
https://goto.google.com/android-sha1/1e09fdb1e5ce72359698bf5fa37e31a931e8c575
Branch: androidx-master-dev
commit 1e09fdb1e5ce72359698bf5fa37e31a931e8c575
Author: jbwoods <jbwoods@google.com>
Date: Mon Mar 25 22:36:00 2019
Add ViewModel support at NavGraph scope
Allows users to get a ViewModelStore for a NavGraph. The ViewModelStore
is retrieved using the graph ID. Only NavGraphs on the NavController
back stack can create a ViewModelStore.
Test: New Tests and reran NavControllerTest
./gradlew checkApi
BUG: 111614463
Change-Id: Ib60bb0eda2c1dc9d2cd5a5aa132162105d172b68
M navigation/common/src/main/java/androidx/navigation/NavBackStackEntry.java
M navigation/fragment/ktx/api/2.1.0-alpha02.txt
M navigation/fragment/ktx/api/current.txt
M navigation/fragment/ktx/build.gradle
A navigation/fragment/ktx/src/androidTest/java/androidx/navigation/fragment/NavGraphViewModelLazyTest.kt
A navigation/fragment/ktx/src/main/java/androidx/navigation/NavGraphViewModelLazy.kt
M navigation/fragment/src/main/java/androidx/navigation/fragment/NavHostFragment.java
M navigation/runtime/api/2.1.0-alpha02.txt
M navigation/runtime/api/current.txt
M navigation/runtime/build.gradle
M navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
A navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerViewModelTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
A navigation/runtime/src/main/java/androidx/navigation/NavControllerViewModel.java
il...@google.com <il...@google.com> #8
Navigation 2.1.0-alpha02 now supports ViewModels at the navigation graph level.
This allows you to write such as:
val viewModel: RegistrationViewModel
by navGraphViewModels(R.id.registration_graph) { factory }
or if you're using Java:
ViewModelStore store =
navController.getViewModelStore(R.id.registration_graph);
RegistrationViewModel viewModel = new ViewModelProvider(store, factory);
And the ViewModel will live until the containing host and its ViewModelStore is cleared or the navigation graph is popped off the back stack.
This allows you to write such as:
val viewModel: RegistrationViewModel
by navGraphViewModels(R.id.registration_graph) { factory }
or if you're using Java:
ViewModelStore store =
navController.getViewModelStore(R.id.registration_graph);
RegistrationViewModel viewModel = new ViewModelProvider(store, factory);
And the ViewModel will live until the containing host and its ViewModelStore is cleared or the navigation graph is popped off the back stack.
ap...@google.com <ap...@google.com> #9
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 3cc9b77742508c095f3268b60956967bce46f0ed
Author: Ian Lake <ilake@google.com>
Date: Sat Mar 30 08:40:04 2019
Save and restore back stack UUIDs for getViewModelStore()
As each NavBackStackEntry has a UUID which matches
the non-config ViewModelStore for each graph, we
need to make sure that those UUIDs are properly
saved and restored across configuration changes to
ensure that when you ask for a particular
ViewModelStore, you get the same object back.
Test: new testSaveRestoreGetViewModelStore
BUG: 111614463
Change-Id: Ie174eeae7318e9b8ba233e58df57f960a8861d99
M navigation/common/src/main/java/androidx/navigation/NavBackStackEntry.java
M navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
https://android-review.googlesource.com/936699
https://goto.google.com/android-sha1/3cc9b77742508c095f3268b60956967bce46f0ed
Branch: androidx-master-dev
commit 3cc9b77742508c095f3268b60956967bce46f0ed
Author: Ian Lake <ilake@google.com>
Date: Sat Mar 30 08:40:04 2019
Save and restore back stack UUIDs for getViewModelStore()
As each NavBackStackEntry has a UUID which matches
the non-config ViewModelStore for each graph, we
need to make sure that those UUIDs are properly
saved and restored across configuration changes to
ensure that when you ask for a particular
ViewModelStore, you get the same object back.
Test: new testSaveRestoreGetViewModelStore
BUG: 111614463
Change-Id: Ie174eeae7318e9b8ba233e58df57f960a8861d99
M navigation/common/src/main/java/androidx/navigation/NavBackStackEntry.java
M navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/runtime/src/main/java/androidx/navigation/NavController.java
tu...@gmail.com <tu...@gmail.com> #10
unresolved reference: by navGraphViewModels(R.id...)?
[Deleted User] <[Deleted User]> #11
In that case what if I have a global navigation action screen let's say for this example a CountryPickerFragment where I want to share data between this screen and the parent caller fragment only (not the entire navigation graph) and I want it cleared after the parent is done how could I scope the ViewModel in that case?
[Deleted User] <[Deleted User]> #12
That is a different issue, that is not yet available. What you want is actually opening a screen while waiting for a result. Check:
https://issuetracker.google.com/issues/79672220
b9...@gmail.com <b9...@gmail.com> #13
What's the difference between graph scoped and parent Fragment/Activity scoped ViewModel?
Navigation graph use child fragment manager to navigate its graph, I think it equals to use parent Fragment scoped ViewModel.
Navigation graph use child fragment manager to navigate its graph, I think it equals to use parent Fragment scoped ViewModel.
ra...@gmail.com <ra...@gmail.com> #14
In reference to #8 how would this work when one needs to implement an app flow of "single activity wih multiple fragments" where also you could share a parent fragment viewmodel with it's child/nested fragments. Referring to your talk on Google IO/19 navGraphViewModels work with only the fragments within the same graph, so how does one share the parent fragment viewmodel with it's child fragment in such a case?
ma...@gmail.com <ma...@gmail.com> #15
In reference to #14... ¿When using dynamic feature modules, the navGraphViewModels property delegate work while the destination are in the same nav graph, how do i handle the scenario when the destinations are included dynamically and separated in their respective DFM ?
Description
Version used: 1.0.0-alpha03
When using nested graph or included graphs to represent certain flows (such as user sign up or checkout), it would be nice to have a built in way to share data across all of these destinations while ensuring that it is cleaned up after the entire graph is removed from the back stack.
Effectively a ViewModel that has a scope somewhere between a single Fragment / ViewModelStoreOwner destination and an Activity scoped ViewModel.