Status Update
Comments
il...@google.com <il...@google.com> #2
jo...@gmail.com <jo...@gmail.com> #3
since it is already marked as deprecated, we can probably do it by now.
ka...@gmail.com <ka...@gmail.com> #4
[Deleted User] <[Deleted User]> #5
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
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.