Status Update
No update yet.
Comments
va...@gmail.com
The issue is reproducible with core-ktx 1.2.0 and 1.3.0-rc01.
al...@google.com
The Typeface.weight is not a weight of the underlying font file. It is a display style. On older APIs, the display style is adjusted if the Typeface is created from single font. However, after moving to CustomFallbackBuilder, that adjustment is removed since it can crate Typeface from multiple style font files.
Looks like it is good to set display style by ResourcesCompat.getFont for backward compatibility.
br...@google.com
Hi Nona,
Can you please schedule a release after you merge the fix?
lo...@gmail.com
Branch: androidx-master-dev
commit 3d6aa2e9b3243dcc4de1f54bd8d40339bd69cb05
Author: Seigo Nonaka <nona@google.com>
Date: Wed May 27 17:38:05 2020
Adjust the Typeface display style with the style of given font
This behavir is implicitly done by Typeface.Builder and
Typeface.createXXX function but not to be done by
Typeface.CustomFallbackBuilder since it is designed to be working
with multiple font files which has different style.
Looks like the style argument is ignored on older API implementation.
Bug: 156853883
Bug: 152023266
Test: ResourcesCompatTest#testGetFont_adjustDisplayStyle passes on 29
Test: ./gradlew core:core:connectedAndroidTest on API 29, 28, 23
Change-Id: I3a377c339a7aed50973cf11df86ddf0069f4ec25
A core/core/src/androidTest/assets/fonts/thin_italic.ttf
A core/core/src/androidTest/assets/fonts/thin_italic.ttx
M core/core/src/androidTest/java/androidx/core/content/res/ResourcesCompatTest.java
A core/core/src/androidTest/res/font/thin_italic.ttf
M core/core/src/main/java/androidx/core/graphics/TypefaceCompatApi29Impl.java
mu...@google.com
Any way I can tell what version this will land in?
lb...@gmail.com
Great—works as expected, thanks!
mm...@gmail.com
Can anyone tell me How to use the new declaration of the method
getParcelable(key, T::class.java) and What's T class represent?
lb...@gmail.com
So, before, you used this in Java:
(MyClass) getParcelable("someKey");
and this in Kotlin:
getParcelable("someKey") as MyClass
And now you could use this in Java:
getParcelable("someKey", MyClass.class);
And this in Kollin:
getParcelable("someKey", MyClass::class.java)
What's the point? I have no idea. Both produce the same things, and both will throw an exception in case of failure...
mm...@gmail.com
@11 Sorry I didn't understand what class should I add in the second parameter, I used the old method like the following to save recycler view list state, what should I changed to make it with new method
@Suppress("DEPRECATION") override fun onResume() { super.onResume() val listState = mBundleRecyclerViewState.getParcelable<Parcelable>(recyclerStateKey) binding.homeRecyclerView.layoutManager?.onRestoreInstanceState(listState) }
lb...@gmail.com
pa...@gmail.com
Continuing #4 and #6, if (SDK_INT > T) (strictly greater) so it'll never trigger until U is out. This way devs can start using the new compat method, deal with the deprecation, and not have to worry about how it's implemented. Later, you can adjust the implementation if necessary, but based on
ap...@google.com
Branch: androidx-main
commit b0895cf4dc9a13b63d3d47aeb7b07a99cfc0bd28
Author: Hani Kazmi <hanikazmi@google.com>
Date: Mon Oct 17 16:59:50 2022
Add compat methods for new Bundle and Intent APIs
We have introduced new, safer, APIs for Parcel, Bundle and Intent in T
that we want to encourage developers to use. However the APIs have a bug
(
previously planned Compat methods that developers can use in all Andorid
versios, that will not use the T Apis until U where the bug is addressed.
There are subtle differences in the implementations of the platform
APIs, and so the behaviour of the compat methods:
1. Get Parcelable
public static <T> T getParcelable(@NonNull Bundle in, @Nullable String
key, @NonNull Class<T> clazz)
public static <T> T getParcelableExtra(@NonNull Intent in, @Nullable
String name, @NonNull Class<T> clazz)
These methods match the method signature and behaviour of the post-T,
type-safe APIs - return the value if it exists and is of the `clazz`
type, otherwise return null.
2. Get Collection
public static <T> ArrayList<T> getParcelableArrayList(@NonNull Bundle
in, @Nullable String key, @NonNull Class<? extends T> clazz)
public static <T> SparseArray<T> getSparseParcelableArray(@NonNull
Bundle in, @Nullable String key, @NonNull Class<? extends T> clazz)
public static <T> ArrayList<T> getParcelableArrayListExtra(@NonNull
Intent in, @Nullable String name, @NonNull Class<? extends T>clazz)
On these methods, the method signature matches the post-T APIs, but type
checking is only done on U+ devices, on first deserialisation. Checking
outside of this scenario requires a linear traversal of the array on each
call, and so is not done for performance (see
benchmarking shows a 400x difference for large arrays.
3. Get Array
public static Parcelable[] getParcelableArray(@NonNull Bundle in,
@Nullable String key, @NonNull Class<?> clazz)
public static Parcelable[] getParcelableArrayExtra(@NonNull Intent in,
@Nullable String name, @NonNull Class<?> clazz)
Due to Java generics erasure at runtime, the post-T method signature can
not be safely used on pre-U devices, as the pre-T platform APIs return a
Parcelable[] rather than T[], which can not be implicitely cast to a
subtype even if all items conform. The cost of manually casting is large
(see above). Therefore, we always return Parcelable[] on all device
versions, and we only type-check on U+ devices.
The ParcelCompat methods have been updated to match this behaviour. For
readArray, this is a source breaking API change. But
the current method signature would fail on any current devices if
assigned to anything other than an Object[] - succeeding
at compile time, but failing with a ClassCastException at runtime.
For readParcelableArray, it has been deprecated and replaced with
readParcelableArrayTyped, as updating the type signature would be a ABI
breaking change for libraries.
Bug: 242048899
Test: atest ParcelCompat BundleCompat IntentCompat on T and U devices
Test: Check binary compatibility manually with a test library.
Relnote: "Adds compatibility methods for new APIs introduced in Android
13 for Parcels, Bundles, and Intents.
Note: Some ParcelCompat method signatures have been updated, and may
require a source change on upgrade to confirm to the new signature."
Change-Id: I57e94c6efcc674173d201205fb175cef495bcf82
A core/core/api/current.ignore
M core/core/api/current.txt
M core/core/api/public_plus_experimental_current.txt
A core/core/api/restricted_current.ignore
M core/core/api/restricted_current.txt
M core/core/src/androidTest/java/androidx/core/content/IntentCompatTest.java
A core/core/src/androidTest/java/androidx/core/os/BundleCompatTest.java
M core/core/src/androidTest/java/androidx/core/os/ParcelCompatTest.java
M core/core/src/main/java/androidx/core/content/IntentCompat.java
A core/core/src/main/java/androidx/core/os/BundleCompat.java
M core/core/src/main/java/androidx/core/os/ParcelCompat.java
lb...@gmail.com
Also, can you please offer extension functions for them? Maybe via another library?
Where can I reach these functions?
All in ParcelCompat?
yo...@gmail.com
Can we also get BundleCompat.getSparseParcelableArray and BundleCompat.getSerializable ? those methods are also deprecated (and buggy? ) in Android T.
al...@gmail.com
Could we add KTX functions for them?
Intent.kt
inline fun <reified T : Parcelable> Intent.parcelableExtra(key: String): T? =
IntentCompat.getParcelableExtra(this, key, T::class.java)
inline fun <reified T : Parcelable> Intent.parcelableArrayExtra(key: String): Array<T>? =
IntentCompat.getParcelableArrayExtra(this, key, T::class.java)
inline fun <reified T : Parcelable> Intent.parcelableArrayListExtra(key: String): ArrayList<T>? =
IntentCompat.getParcelableArrayListExtra(this, key, T::class.java)
inline fun <reified T : Serializable> Intent.serializableExtra(key: String): T? =
IntentCompat.getSerializableExtra(this, key, T::class.java)
Bundle.kt
inline fun <reified T : Parcelable> Bundle.parcelable(key: String): T? =
BundleCompat.getParcelable(this, key, T::class.java)
inline fun <reified T : Parcelable> Bundle.parcelableArray(key: String): Array<T>? =
BundleCompat.getParcelableArray(this, key, T::class.java)
inline fun <reified T : Parcelable> Bundle.parcelableArrayList(key: String): ArrayList<T>? =
BundleCompat.getParcelableArrayList(this, key, T::class.java)
inline fun <reified T : Parcelable> Bundle.sparseParcelableArray(key: String): SparseArray<T>? =
BundleCompat.getSparseParcelableArray(this, key, T::class.java)
inline fun <reified T : Serializable> Bundle.serializable(key: String): T? =
BundleCompat.getSerializable(this, key, T::class.java)
[Deleted User] <[Deleted User]>
I agree, KTX extensions would be a very nice addition as well.
ro...@gmail.com
pa...@gmail.com
#15
st...@hedvig.com
st...@gmail.com
Does this PR not include compat APIs when trying to do BundleCompat.getSerializable?
It is also an API which has received the same change, where the normal function is deprecated, and the comment says "Deprecated: Use the type-safer getSerializable(String, Class) starting from Android Build.VERSION_CODES.TIRAMISU." So it also implies that using it in older API versions is problematic as the parcelable one was.
jc...@masttro.com
ry...@memorigi.com
ja...@globe.com.ph
jo...@devoteam.com
androidx.core:core-ktx:1.10.0 provides IntentCompat and BundleCompat
kotlin example: IntentCompat.getParcelableExtra(intent, "result", YourClass::class.java)
28...@qq.com
ca...@digitalchargingsolutions.com
This should really be documented at
al...@gmail.com
Should this be marked as fixed with the new BundleCompat and IntentCompat APIs?
fe...@gmail.com
yo...@gmail.com
A separate ticket for BundleCompat.getSerializable
ch...@gmail.com
This issue exists only when obfuscation is enabled, for me.
Description
Would be nice if there was a
BundleCompat.getParcelable(key: String, clazz: Class)that uses the new getParcelable method on SDK 33.