IssueTracker

#triage_week_35

@8 You should create a POC for this, and report it as a bug.

@10 Instead of casting to the class you want, you put the class type in the parameter.

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...

@12 The class you want to get out of the Bundle/Intent, same as the one that you've put (or someone else had, such as on the Android documentation) into it

Project: platform/frameworks/support
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
    (b/232589966) which could hinder adoption. As such, we are adding
    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 b/222087511). Initial
    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

https://android-review.googlesource.com/2214807

@15 Can you please add IDE inspection that will suggest to use them all?
Also, can you please offer extension functions for them? Maybe via another library?

Where can I reach these functions?
All in ParcelCompat?

DIscussão confusa e desnecessária.  Sejam inteligentes.  Façam um github do fracionamento na solução

Any news on when this is going to be released?

Please update this. Thanks.

androidx.core:core-ktx:1.10.0 provides IntentCompat and BundleCompat

kotlin example: IntentCompat.getParcelableExtra(intent, "result", YourClass::class.java)

没有serializable啊