Status Update
No update yet.
Comments
va...@gmail.com
<transition xmlns:android="
<item android:drawable="@drawable/test_drawable_blue"/>
<item android:drawable="@drawable/test_drawable_green"/>
</transition>
where blue/green drawables look like this:
<shape
xmlns:android="
android:shape="rectangle">
<size
android:width="@dimen/drawable_large_size"
android:height="@dimen/drawable_small_size" />
<solid
android:color="@color/test_blue" />
</shape>
Then added this test:
@Test
public void testMutateTransitionDrawable() {
Drawable drawable = ResourcesCompat.getDrawable(mResources,
R.drawable.test_transition_drawable, null);
assertTrue(drawable instanceof TransitionDrawable);
Drawable mutated = drawable.mutate();
assertTrue(drawable instanceof TransitionDrawable);
assertTrue(mutated instanceof TransitionDrawable);
}
It passes on the device. Going to also try on other earlier devices a bit later in the day once they are charged.
al...@google.com
br...@google.com
lo...@gmail.com
also bugs me about Parcel.readParcelable. if ya gonna nag me in a gazilion places through my code at least give me a nice way to resolve it. these 'blah is deprecated' msgs for code that works on my minSdkVersion just kill me. sticking an if or a supress on every second line of my code is just ...
a little comment about the above kotlin inline fun, I need both kotlin and java solution.
za...@gmail.com
Re #4, I think Google should offer this even if it's only going to work on U+ because right now the original APIs are deprecated and the replacements are not safe to use.
mu...@google.com
mo...@gmail.com
To add to #5, I went half an hour through the app, thinking the new method is backwards-compatible. Android Studio reported no issues, having the compileSdkVersion to 33 and minSdkVersion at 23.
Run the app on the device and boom, crash. Time to revert everything or replace every method with a backwards-compatbile function that I have to integrate on my own :(.
lb...@gmail.com
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.