STOP MAKING ALL USEFUL APIS INTERNAL [229839039]

Duplicate

of 163132293

Bug

Status Update

No update yet.

Description

bl...@gmail.com

created issue #1

Apr 21, 2022 11:47AM

PLEASE STOP MAKING ALL USEFUL APIS INTERNAL

When Compose was released, it was accompanied with confident gloating about how it was easy to mix and match components with different granularity on the UI layers. One aspect of this was that many implementation APIs are accessible to developers. To my horror, more and more APIs are marked internal in the Material 3 library. For example, all the SwipeableState APIs (i.e. rememberSwipeableState and all associated classes / functions) are now internal, while they were public in Material 2. This forces me to copy-paste the exact library code for swipe state into my own project, just so I can get a reference to the swipeable state, and this seems kind of idiotic to me.

PLEASE STOP MAKING ALL USEFUL APIS INTERNAL

Jetpack Compose component used: androidx.compose.material3:material3:1.0.0-alpha10

Steps to Reproduce or Code Sample to Reproduce:

Try to migrate from M2 to M3
Give up because it's a total mess

Comments

jo...@google.com <jo...@google.com> #2Apr 25, 2022 09:43AM

Status: Duplicate of

163132293

Hi,

Thank you for your feedback. I understand that this is a frustrating experience - we aren't in a super easy spot with Swipeable. It currently has a number of critical bugs that need to be addressed first (we are working on this), which is why we are limiting the surface we are exposing for Swipeable in M3 for the time. Our plan for the coming months is to focus on this specific area and improve developer experience.

Material 3 for Jetpack Compose is still in alpha - this means we consider components production-ready, but the API shape is flexible while in alpha. This gives us space to iterate while getting real-world feedback from developers, which ultimately helps improve your experience. Copy-pasting source code for components that are not (fully) implemented or exposed in an alpha version can be a good thing to do in the meantime! Owning the source code while the API shape is still flexible gives you a number of benefits like ease of updating dependencies, even if the APIs change, and allows you to evolve your components in your own pace.

We are aware of your request to expose rememberSwipeableStateFor in M3 though and will do so when the time is right and Swipeable in a good enough spot. I will close this issue in favor of b/163132293 which has a bit more historical context.

bl...@gmail.com <bl...@gmail.com> #3Apr 25, 2022 09:16PM

..and no such anger. Sorry about that. Agree, close this. And thank you for your considerations. :)

bl...@gmail.com <bl...@gmail.com> #4May 19, 2022 01:25PM

Just asking, do you have a reference to the critical bugs in swipeable? I'm using the M2 variant and I'm actually pretty happy with it... Curious about which issues I can expect with it.

jo...@google.com <jo...@google.com> #5May 19, 2022 01:31PM

Of course - they are mostly related to how we handle anchors currently. Check out https://issuetracker.google.com/issues/215501262, https://issuetracker.google.com/issues/205866531, https://issuetracker.google.com/issues/210991864, https://issuetracker.google.com/issues/206022555, https://issuetracker.google.com/issues/200980998 for some examples.

The current implementation works well for things like swipe to dismiss. What are your use cases?

bl...@gmail.com <bl...@gmail.com> #6May 19, 2022 03:48PM

That makes sense, because that is what I'm using it for. :-) I wanted my UI screens to be swipeable a la Telegram (example)

Sadly the navigation authors are unresponsive to feature requests which would facilitate this pattern, so I've been hacking it out myself with just Compose + State. It works surprisingly well so far. I have to commend you guys, Compose is a blast!

bl...@gmail.com <bl...@gmail.com> #7May 23, 2022 10:27PM

I've noticed one little glitch. Velocity seems to be too high if I 'jiggle' the swipeable element and then release. See attached video: the pane is swiped all the way even though I wouldn't expect it to for such a small drag.

Maybe it's the same issue as https://issuetracker.google.com/issues/216582726 ?

video5215400932384187196.mp4

609 KB

Download

bl...@gmail.com <bl...@gmail.com> #8Aug 24, 2022 08:17PM

https://android.googlesource.com/platform/frameworks/support/+/071c483c7223af673a5c0145e2fee7b0c94af1fd%5E%21/

PLEASE

STOP

MARKING

USEFUL

APIS

INTERNAL

ni...@google.com <ni...@google.com> #9Nov 4, 2022 07:01PM

Hi, we hear your frustration and as my colleague pointed out, we are balancing many factors when committing to API surfaces. Each API goes through multiple internal reviews and we do read through all feedback/bugs as input on what APIs we build next. We ask for patience and we appreciate the time you've taken to give us input from the community!

However, all-caps aggressive complaints like #comment8 provide little value, are not productive, and violate the terms of our tracker. When you find APIs that you need, please continue to file bugs, but remember to be respectful in how you communicate here.

to...@gmail.com <to...@gmail.com> #10Mar 28, 2023 04:21AM

Hi,
I hope you guys will public the swipe api in material3.
I still use both material and material3 because I need `Modifier.swipeable` which is available in material 2 but internal in material 3.

jo...@gmail.com <jo...@gmail.com> #11Mar 29, 2023 11:47PM

Just access the internal stuff anyway and slap a visibility supress annotation. Internal is so anoying

sy...@gmail.com <sy...@gmail.com> #12Jul 28, 2023 05:06PM

Please add an ability to pass our own set of possible positions for a bottom sheet as a parameter for BottomSheetScaffold. Due to the lack of this possibility, I had to write my own implementation of a bottom sheet, which took a lot of time. Sometimes it is necessary that a bottom sheet could be not only in three positions: Hidden, PartiallyExpanded and Expanded. The current implementation of BottomSheetScaffold does not allow you to add other positions.
Also, it is not at all encouraging that methods such as swipeableV2 and swipeAnchors are internal. If they were available, it would be much easier for me to create my own implementation of a bottom sheet. I join the request to make useful APIs available.

jo...@google.com <jo...@google.com> #13Jul 31, 2023 08:38AM

#12, the underlying APIs have been published in Foundation 1.6.0-alpha01 as AnchoredDraggable. We are currently working on migrating the M3 components from SwipeableV2 to AnchoredDraggable, which will make copying easier. The M2 components have been migrated and can be used as a reference in the meantime.

As for the BottomSheetScaffold feature request: The current layering is very much intentional. Customizing anchor positions can alter the behavior of the component to not match Material Design guidelines, which the Material 2 and 3 libraries are providing implementations for. If your use cases or design systems call for different behavior, we recommend building your own component (as you have). I will leave your original issue to the Material team to comment on.

A note on the ability to copy-paste code: we always strive to make sure our code is as easily copyable as possible, but have to make tradeoffs. In the case of BottomSheetScaffold, ModalBottomSheet(Layout) and more, we decided to opt for bringing behavioral and stability improvements before committing to a public API. Hope this helps!