Status Update
Comments
am...@google.com <am...@google.com>
am...@google.com <am...@google.com> #2
this would be nice but given Compose and all other priorities, we are not planning to make any big investments in data binding (support KSP is a very big task).
ca...@gmail.com <ca...@gmail.com> #3
Makes sense. And is there any way to trigger data binding without kapt plugin, assuming there are no custom binding adapters in given module?
ki...@gmail.com <ki...@gmail.com> #4
unfortunately no. data binding still needs to be able to read your code and annotation processing is the only API that allows us to do it :(
am...@google.com <am...@google.com> #5
It's a very disappointing decision for many projects who heavily depend on data binding, which will never be able to get rid of all bindings code and especially rewrite all UI to Compose.
It means that bindings are essentially deprecated
[Deleted User] <[Deleted User]> #6
It does not mean data binding is deprecated unless KAPT is deprecated (if that happens, we would need to support KSP).Unfortunately, moving data binding to KSP is a large order so it makes more sense to keep focusing on KAPT than rewrite data binding.
We might re-consider this in the future based on KSP becoming stable, Compose adoption and KAPT stability but it is very unlikely to happen.
t....@gmail.com <t....@gmail.com> #8
Unfortunately this is still a NO for 2022 planning due to reasons mentioned in #2.
[Deleted User] <[Deleted User]> #9
kapt seems no longer adding new feature
kapt is in maintenance mode. We are keeping it up-to-date with recent Kotlin and Java releases but have no plans to implement new features. Please use the Kotlin Symbol Processing API (KSP) for annotation processing. See the list of libraries supported by KSP.
So this mean databinding will also deprecated or will be support KSP?
ad...@gmail.com <ad...@gmail.com> #10
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.
[Deleted User] <[Deleted User]> #11
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.
I have been waited this answer in several years.
Because it is an important basis to convince co-workers and for determining the technology stack of an app.
ch...@google.com <ch...@google.com> #12
Databinding is in maintenance mode as well.
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.
A bit of a tangent here, but what about ViewBinding? Will that one stay going strong or will it fade along with DataBinding?
[Deleted User] <[Deleted User]> #13
So if you are using Views, ViewBinding will keep working.
It is the same for Data Binding as well though. The main difference is that if KAPT stops working, DataBinding will stop working whereas ViewBinding will keep working. Hopefully, any such situation will be far enough that no-one will care and everyone will be using Compose :)
[Deleted User] <[Deleted User]> #16
#14 Kapt will be supported on K2, there are no plans to stop supporting it in Kotlin
ch...@google.com <ch...@google.com> #17
ar...@google.com <ar...@google.com> #19
az...@gmail.com <az...@gmail.com> #20
dg...@gmail.com <dg...@gmail.com> #21
[Deleted User] <[Deleted User]> #22
jo...@gmail.com <jo...@gmail.com> #23
dr...@gmail.com <dr...@gmail.com> #24
fa...@gmail.com <fa...@gmail.com> #25
ps...@gmail.com <ps...@gmail.com> #26
dr...@gmail.com <dr...@gmail.com> #27
dr...@gmail.com <dr...@gmail.com> #28
al...@google.com <al...@google.com> #29
am...@google.com <am...@google.com> #30
ps...@gmail.com <ps...@gmail.com> #31
de...@gmail.com <de...@gmail.com> #32
de...@gmail.com <de...@gmail.com> #33
pr...@gmail.com <pr...@gmail.com> #34
[Deleted User] <[Deleted User]> #35
ay...@gmail.com <ay...@gmail.com> #36
9g...@gmail.com <9g...@gmail.com> #37
[Deleted User] <[Deleted User]> #38
za...@gmail.com <za...@gmail.com> #39
sh...@gmail.com <sh...@gmail.com> #40
ja...@gmail.com <ja...@gmail.com> #41
de...@gmail.com <de...@gmail.com> #42
pe...@gmail.com <pe...@gmail.com> #43
Hoping to see a proper solution, currently this is my workaround until then. Not the best workaround, but does work for me:
Override
public void onScrollStateChanged(final int state)
{
super.onScrollStateChanged(state);
if (state == RecyclerView.SCROLL_STATE_SETTLING)
{
this.stopScroll();
}
}
pe...@gmail.com <pe...@gmail.com> #44
hu...@gmail.com <hu...@gmail.com> #45
[Deleted User] <[Deleted User]> #46
an...@gmail.com <an...@gmail.com> #47
[Deleted User] <[Deleted User]> #49
ha...@gmail.com <ha...@gmail.com> #50
ri...@gmail.com <ri...@gmail.com> #51
fa...@gmail.com <fa...@gmail.com> #52
de...@gmail.com <de...@gmail.com> #53
au...@google.com <au...@google.com> #54
sh...@google.com <sh...@google.com> #55
The issue is that after a fling event, the nested scrolling api has no way of informing the RecyclerView that a fling animation has reached the end of the scroll distance, and thus sometimes, the scroll animation is continuing in the background such that when the first tap occurs, it is interpreted as an interruption to the fling, which puts the RV back into its scrolling state as if the user started scrolling, and thus, the touch events don't propagate down to the child to cause a click to occur.
Some larger changes are needed to fix this (and at least one other) issue, and I'm in the midst of that work.
Sorry for the inconvenience.
za...@gmail.com <za...@gmail.com> #56
dr...@gmail.com <dr...@gmail.com> #57
May I ask in this version, fix this issue?
sh...@google.com <sh...@google.com> #58
sp...@gmail.com <sp...@gmail.com> #59
sh...@google.com <sh...@google.com> #60
When RecyclerView is flung, and it hits the bounds of it's scrollable distance and has a NestedScrollingParent, it continues to animate the fling so that the NestedScrollingParent might receive the events and scroll. RV has no way of knowing if any NestedScrollingParents have hit their bounds, and thus it continues the fling even if nothing is moving.
On top of that, when RV is flinging and is touched, it stops it's fling and prevents the touch event from causing a click, so that a touch meant to stop a fling doesn't cause a click.
Put those two things together and you get the perceived behavior that when an RV is flung, and stops, the next touch event doesn't click.
I'm pursuing a but can't make any promises as to when it will be available. Sorry for the inconvenience.
ha...@gmail.com <ha...@gmail.com> #61
pr...@gmail.com <pr...@gmail.com> #63
su...@gmail.com <su...@gmail.com> #64
sh...@google.com <sh...@google.com> #65
ny...@gmail.com <ny...@gmail.com> #66
fa...@gmail.com <fa...@gmail.com> #67
le...@gmail.com <le...@gmail.com> #68
pi...@gmail.com <pi...@gmail.com> #69
yi...@gmail.com <yi...@gmail.com> #70
de...@gmail.com <de...@gmail.com> #71
t....@gmail.com <t....@gmail.com> #72
cn...@gmail.com <cn...@gmail.com> #73
za...@gmail.com <za...@gmail.com> #74
da...@gmail.com <da...@gmail.com> #75
[Deleted User] <[Deleted User]> #76
ro...@gmail.com <ro...@gmail.com> #77
an...@googlemail.com <an...@googlemail.com> #78
sh...@google.com <sh...@google.com> #79
I am actively solving this issue. In fact, the CL that makes the necessary changes in RecyclerView has been submitted to aosp (as AndroidX is now developed there):
The fix is coming by way of an update to nested scrolling and thus need to be implemented across multiple classes. For example, for the issue to be fixed when a RecyclerView is in a CoordinatorLayout with the AppBarLayout.Behavior, implementation has to be done in each of those classes.
Unfortunately the rollout of these changes is also going to take some time, but do know that we are taking as seriously as we can.
fr...@gmail.com <fr...@gmail.com> #80
sh...@google.com <sh...@google.com> #81
sh...@gmail.com <sh...@gmail.com> #83
I've tried both java and xml ways but in vain.
Checked on emulator running on 5.0 and physical device running on 7.1.1
Any ideas ?
sh...@gmail.com <sh...@gmail.com> #84
ss...@gmail.com <ss...@gmail.com> #85
am...@gmail.com <am...@gmail.com> #87
am...@google.com <am...@google.com>
pa...@gmail.com <pa...@gmail.com> #88
Dear Google developers, can you please take it on priority?
we...@gmail.com <we...@gmail.com> #89
kp...@gmail.com <kp...@gmail.com> #90
I think it is related with NestedScrollingChild3 and NestedScrollingParent3 and since 1.1.0-alpha01 RecyclerView and CoordinatorLayout implements those.
sh...@google.com <sh...@google.com> #91
sh...@google.com <sh...@google.com> #92
androidx.core 1.1.0-alpha01
androidx.appcompat 1.1.0-alpha01
androidx.coordinatorlayout 1.1.0-alpha01
androidx.recyclerview 1.1.0-alpha01
androidx.swiperefreshlayout 1.1.0-alpha01
(and an upcoming release of the android material design library)
This issue should be fixed!
I'm closing it, but do let me know if it seems to still be happening!
pa...@outlook.com <pa...@outlook.com> #93
This is a BottomSheet with a NestedScrollView, it does not contain any RecyclerView:
<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout
xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="match_parent"
android:clipChildren="false">
<com.google.android.material.appbar.AppBarLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<!--Other views and tested with and without a Toolbar inside-->
</com.google.android.material.appbar.AppBarLayout>
<androidx.core.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@color/white"
app:layout_behavior="@string/appbar_scrolling_view_behavior">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
android:paddingBottom="8dp"
android:paddingTop="8dp">
<!--Enough views to create a scrollable area-->
</LinearLayout>
</androidx.core.widget.NestedScrollView>
</androidx.coordinatorlayout.widget.CoordinatorLayout>
In this scenario (with or without a Toolbar view in the AppBarLayout parent) whenever you scroll the NestedScrollView to the top or to the bottom and try to tap on any items inside the LinearLayout the first tap will always fail to initiate the expected action, forcing you to do a second tap since after the first one the taps start working. This happens whenever you scroll to the top or bottom of the NestedScrollView every single time, even after you tap for a second or n times.
I am using the library versions or most up to date (a couple were already updated since then) the Assignee listed in his last reply.
sh...@google.com <sh...@google.com> #94
There isn't a public bug that I'm aware of that is tracking that precise work, but know that your specific issue will be fixed in an upcoming release of the Android Material Design library.
pa...@outlook.com <pa...@outlook.com> #95
me...@google.com <me...@google.com> #96
yq...@gmail.com <yq...@gmail.com> #97
pv...@gmail.com <pv...@gmail.com> #98
recyclerview-v7:28.0.0
vz...@gmail.com <vz...@gmail.com> #99
sh...@google.com <sh...@google.com> #100
The AndroidX version of RecyclerView picks up where that version left off and is currently supported:
sh...@google.com <sh...@google.com> #101
sa...@gmail.com <sa...@gmail.com> #102
[Deleted User] <[Deleted User]> #103
[Deleted User] <[Deleted User]> #104
sh...@google.com <sh...@google.com> #105
te...@gmail.com <te...@gmail.com> #106
sh...@google.com <sh...@google.com> #107
ma...@gmail.com <ma...@gmail.com> #108
ma...@gmail.com <ma...@gmail.com> #109
but it's working fine if I double tap it quickly
sh...@google.com <sh...@google.com> #110
bo...@gmail.com <bo...@gmail.com> #111
Updated my AndroidX dependencies and fixed the issue with appbarlayout/bottomnav/recyclerview. Did not try out MotionLayout
Description
Version used: 26.0.2
Theme used: Theme.AppCompat.NoActionBar
Devices/Android versions reproduced on: AVD API 25
I just upgraded to API 26 and support library 26.0.2. But I found that my RecyclerView items is not clickable right after the scrolling. If you wait for a second, it will work. But if you click the item immediately, it won't. Even if the RecyclerView is not scrolling at all(e.g. has scrolled to the top).
When I downgraded to support library 25.4.0 everything goes fine again. The key point is that my RecyclerView is in a CoordinatorLayout and has a SCROLL_FLAG_SCROLL flag on my Toolbar of the AppBarLayout. If I don't use this flag, then this problem will disappear.
I've tried to add focusable="false" to the CoordinatorLayout but still had no luck.
Is there any way to disable this behavior? Because it's really annoying to click twice to trigger the click event.
I think the problem is the scrollState of the RecyclerView. When it's stopped scrolling, it's not changed to SCROLL_STATE_IDLE immediately. Looking into the source code of RecyclerView, I found there's a ViewFlinger controlling the scroll state. When I fling down to scroll to the top, it's not calling setScrollState(SCROLL_STATE_IDLE) immediately. Instead, it wait for a while to trigger this method. The more fast I fling, the more time I need to wait. It just like the RecyclerView is still scrolling in the background. Because the scroller.isFinished() doesn't return true right after the RecyclerView stop scrolling when it touched the top. Maybe it's a bug of the RecyclerView when it's in a CoordinatorLayout.
The attachment is a screen recording of this behavior.
<android.support.design.widget.CoordinatorLayout
android:id="@+id/coordinateLayout"
android:layout_width="match_parent"
android:layout_height="match_parent">
<android.support.design.widget.AppBarLayout
android:id="@+id/fragmentAppBar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:elevation="0dp"
android:background="@null">
<include
android:id="@+id/dynamicActionBarHolder"
layout="@layout/dynamic_action_bar"/>
</android.support.design.widget.AppBarLayout>
<android.support.v4.widget.SwipeRefreshLayout
android:id="@+id/pullToRefreshMailRecycler"
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layout_behavior="@string/appbar_scrolling_view_behavior">
<android.support.v7.widget.RecyclerView
android:id="@+id/mailRecyclerView"
android:layout_width="match_parent"
android:layout_height="match_parent"/>
</android.support.v4.widget.SwipeRefreshLayout>
</android.support.design.widget.CoordinatorLayout>
layout/dynamic_action_bar.xml
<FrameLayout xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="?attr/actionBarSize"
app:layout_scrollFlags="scroll"
android:clickable="true"
android:background="?theme.dynamicActionBarBackground">
<ImageButton
android:id="@+id/dynamicAcbMenuIcon"
android:layout_width="?attr/actionBarSize"
android:layout_height="?attr/actionBarSize"
android:background="@drawable/article_explicit_button_background"
android:src="?theme.menuIcon"/>
<RelativeLayout
android:id="@+id/dynamicAcbTitleHolder"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_marginStart="?attr/actionBarSize"
android:paddingTop="5dp"
android:paddingBottom="5dp"
android:paddingEnd="5dp"
android:layout_gravity="center_vertical">
<TextView
android:id="@+id/dynamicAcbTitle"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="true"
android:textSize="@dimen/action_bar_title_portrait_size"
android:textColor="?theme.listItemTitleColor"
android:ellipsize="end"
android:text="ActionBar"/>
<TextView
android:id="@+id/dynamicAcbSubtitle"
android:layout_below="@+id/dynamicAcbTitle"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="true"
android:textSize="@dimen/action_bar_subtitle_portrait_size"
android:textColor="?theme.listItemTitleColor"
android:ellipsize="end"
android:text="If you say so"/>
</RelativeLayout>
</FrameLayout>