Status Update
Comments
il...@google.com <il...@google.com> #2
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
jo...@gmail.com <jo...@gmail.com> #3
ka...@gmail.com <ka...@gmail.com> #4
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
[Deleted User] <[Deleted User]> #5
Currently the combination of Hilt, SavedStateHandle and Safe args is not possible. The closest I've seen is to drop using safe args and just use magic strings. This also not ideal re dependency inversion as now you have to construct a mock SavedStateHandle for unit tests etc.
class ArticleViewModel @ViewModelInject constructor(
private val repository: ArticleRepository,
@Assisted savedStateHandle: SavedStateHandle
) {
// FIXME: oops, magic "articleId" string
private val articleId: Long = savedStateHandle["articleId"]
?: throw IllegalArgumentException("Article ID required")
}
g....@gmail.com <g....@gmail.com> #6
I thought I needed this, but then I realized that I can just create an empty Bundle, store the Fragment's arguments in it as a Bundle (so a Bundle inside a Bundle) and use that to initialize the SavedStateHandle. Then I can just retrieve the arguments from the SavedStateHandle and use the already existing fromBundle
method.
What I like about this is that I get to have immutable init arguments, as long as I store the Fragment's arguments with a key that I would never use for other entries.
With a helper function and a base ViewModel class you can hide this entire process and have ViewModels that expose the arguments object as property/member of the ViewModel itself.
ka...@gmail.com <ka...@gmail.com> #7
Could you provide an example of how you achieve that?
g....@gmail.com <g....@gmail.com> #8
What I wrote requires the ability to provide a Bundle
to initialize the SavedStateHandle
and currently that's not possible with Hilt. You need to wait for this to be fixed:
If you do not use Hilt, then what I wrote becomes straightforward. Rather than passing the Fragment's arguments directly, you provide a Bundle
with the Fragment's arguments in it:
Bundle().apply { putBundle(SOME_SPECIAL_BUNDLE_KEY, arguments) }
By doing so you'll be able to do the following in your ViewModel
:
val fragmentArgs = savedStateHandle[SOME_SPECIAL_BUNDLE_KEY]
val args = YouFragmentArgs.fromBundle(fragmentArgs)
You still need to use a magic key for the Bundle, but it can be a project-wide constant and you only have to pass a single argument. The initialization is also the same for all the ViewModels, so you can easily write helpers to abstract away the process.
al...@linguistica360.com <al...@linguistica360.com> #9
If you are using hilt you can wrap the incoming arguments in fragment like so
open class BaseFragment : Fragment() {
override fun setArguments(args: Bundle?) {
if (args != null) {
super.setArguments(Bundle(args).apply {
putBundle(BUNDLE_ARGS, args) // Wrap the arguments as BUNDLE_ARGS
})
} else {
super.setArguments(null)
}
}
}
and then for the view model, you can inherit from something like that
open class ArgsViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() {
val arguments get() = savedStateHandle.get<Bundle>(BUNDLE_ARGS)
@MainThread
inline fun <reified Args : NavArgs> navArgs() = NavArgsLazy(Args::class) {
arguments ?: throw IllegalStateException("ViewModel $this has null arguments")
}
}
Hope that helps
il...@google.com <il...@google.com>
al...@linguistica360.com <al...@linguistica360.com> #11
Do you know when this will be released?
il...@google.com <il...@google.com> #12
Re #11 - The public hotlist listed at the top of this bug says "androidx-navigation-2.4.0-alpha01" - that's the expected release.
ho...@gmail.com <ho...@gmail.com> #13
It seems this has been included in the
But is there any additional setup required besides updating the navigation dependencies? With the following dependencies on my project
object Navigation {
private const val version = "2.4.0-alpha01"
const val compose = "androidx.navigation:navigation-compose:$version"
const val fragment = "androidx.navigation:navigation-fragment-ktx:$version"
const val safeArgsPlugin = "androidx.navigation:navigation-safe-args-gradle-plugin:$version"
const val ui = "androidx.navigation:navigation-ui-ktx:$version"
}
my safeargs don't generate fromSavedStateHandle()
.
fromBundle()
is still the only auto-complete suggestion.
FooFragmentArgs.fromSavedStateHandle(savedStateHandle)
is an unresolved reference in my ViewModel.
ok...@gmail.com <ok...@gmail.com> #14
Android Studio : 4.2.1
com.android.tools.build:gradle:4.2.1
androidx.navigation:navigation-safe-args-gradle-plugin:2.4.0-alpha01
Is there any thing we can do about this?
il...@google.com <il...@google.com> #15
Re #13, #14 - please upgrade to the latest version of Android Studio and file a bug against Android Studio if you are still not seeing this method in the Studio generated light classes.
ho...@gmail.com <ho...@gmail.com> #16
I'm using Arctic Fox | 2020.3.1 Canary 9. I've just updated Navigation to 2.4.0-alpha02 and still seeing the bug, so I've filed a bug against AS.
ho...@gmail.com <ho...@gmail.com> #17
As mentioned in the linked issue, manually downloading the latest version of Android Studio Preview fixes the issue
Description
androidx.navigation:navigation-safe-args-gradle-plugin:2.0.0
androidx.lifecycle:lifecycle-viewmodel-savedstate:1.0.0-alpha02
Allow SafeArgs to be created `fromSavedStateHandle` as one would from a bundle.