Status Update
Comments
ja...@gmail.com <ja...@gmail.com> #2
Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Galhardo <
Link:
Suppress deprecate warning in AbstractSavedStateViewModelFactory tests
Expand for full commit details
Suppress deprecate warning in AbstractSavedStateViewModelFactory tests
Test: N/A
Bug: 388590327
Change-Id: Ibe2f04f4cb46f7d19d7fcab22ba2cecb4c82c68c
Files:
- M
lifecycle/lifecycle-viewmodel-savedstate/src/androidInstrumentedTest/kotlin/androidx/lifecycle/viewmodel/savedstate/SavedStateFactoryTest.kt
- M
lifecycle/lifecycle-viewmodel-savedstate/src/androidInstrumentedTest/kotlin/androidx/lifecycle/viewmodel/savedstate/ViewModelsWithStateTest.kt
Hash: c944a864317d80aeae8c5ee5812eb20eb1e3d0a8
Date: Mon Jan 13 17:39:17 2025
mi...@gmail.com <mi...@gmail.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Galhardo <
Link:
Deprecate AbstractSavedStateViewModelFactory in favor of CreationExtras API
Expand for full commit details
Deprecate AbstractSavedStateViewModelFactory in favor of CreationExtras API
`AbstractSavedStateViewModelFactory` is deprecated as it creates a `SavedStateHandle` for every `ViewModel`, causing unnecessary overhead. Use `ViewModelProvider.Factory` with `CreationExtras.createSavedStateHandle` instead for more efficient `ViewModel` creation.
- Updated KDoc with deprecation details and alternatives.
- Added `@Deprecated` annotation.
RelNote: "`AbstractSavedStateViewModelFactory` is deprecated as it creates a `SavedStateHandle` for every `ViewModel`, causing unnecessary overhead. Use `ViewModelProvider.Factory` with `CreationExtras.createSavedStateHandle` instead for more efficient `ViewModel` creation."
Test: N/A
Bug: 388590327
Change-Id: Ia920b66ccabde85a105cf4e6f80aa980270098ee
Files:
- M
lifecycle/lifecycle-viewmodel-savedstate/api/current.txt
- M
lifecycle/lifecycle-viewmodel-savedstate/api/restricted_current.txt
- M
lifecycle/lifecycle-viewmodel-savedstate/src/androidMain/kotlin/androidx/lifecycle/AbstractSavedStateViewModelFactory.android.kt
Hash: a3dcd46d7c08fa2d407aa9f8f91fb181aa342cc8
Date: Mon Jan 13 14:45:34 2025
pa...@gmail.com <pa...@gmail.com> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-viewmodel-savedstate:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-android:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-desktop:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-iosarm64:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-iossimulatorarm64:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-iosx64:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-linuxarm64:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-linuxx64:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-macosarm64:2.9.0-alpha09
androidx.lifecycle:lifecycle-viewmodel-savedstate-macosx64:2.9.0-alpha09
br...@gmail.com <br...@gmail.com> #5
ja...@gmail.com <ja...@gmail.com> #6
ra...@gmail.com <ra...@gmail.com> #7
al...@android.com <al...@android.com>
ma...@gmail.com <ma...@gmail.com> #8
[Deleted User] <[Deleted User]> #9
mi...@gmail.com <mi...@gmail.com> #10
[Deleted User] <[Deleted User]> #11
[Deleted User] <[Deleted User]> #12
[Deleted User] <[Deleted User]> #13
bo...@gmail.com <bo...@gmail.com> #14
[Deleted User] <[Deleted User]> #15
ma...@gmail.com <ma...@gmail.com> #16
ja...@gmail.com <ja...@gmail.com> #17
mo...@gmail.com <mo...@gmail.com> #18
m....@gmail.com <m....@gmail.com> #19
de...@gmail.com <de...@gmail.com> #20
me...@gmail.com <me...@gmail.com> #21
kr...@gmail.com <kr...@gmail.com> #22
su...@gmail.com <su...@gmail.com> #23
ar...@connectmedica.com <ar...@connectmedica.com> #24
ia...@gmail.com <ia...@gmail.com> #25
ke...@pinxterapp.com <ke...@pinxterapp.com> #26
ni...@google.com <ni...@google.com>
[Deleted User] <[Deleted User]> #27
+1 for this feature.
ja...@gmail.com <ja...@gmail.com> #28
[Deleted User] <[Deleted User]> #29
ru...@gmail.com <ru...@gmail.com> #30
sa...@gmail.com <sa...@gmail.com> #31
ช่วยแก้ไข browser ให้ผมหน่อยครับ
Description
However, for my app, the derived colors for both are noticeably different than the rest of my application. While the functionality of custom tabs is winning over the designer, they are not happy with the visual result.
Therefore, I'd like to be able to specify the status bar color to use with the custom tab (ie the primaryColorDark from my application). Seems reasonable if the developer doesn't specify a status bar color it uses the derived color as it does today.
As well I'd like to control the icon tint in the tool bar for the default "close" and "overflow" icons. While, specifying my own bitmap works around the "close" icon, the overflow icon tint is still controlled by the custom tab and may not match the overall theme.