Я использую новый CoordinatorLayout с AppBarLayout и CollapsingToolbarLayout. Ниже AppBarLayout у меня есть RecyclerView со списком контента.
Я проверил, что прокрутка броска работает на RecyclerView, когда я прокручиваю вверх и вниз по списку. Тем не менее, я также хотел бы, чтобы AppBarLayout плавно прокручивался во время расширения.
При прокрутке вверх, чтобы развернуть CollaspingToolbarLayout, прокрутка немедленно прекращается, как только вы убираете палец с экрана. Если вы прокрутите вверх быстрым движением, иногда CollapsingToolbarLayout также снова сворачивается. Такое поведение с RecyclerView, кажется, работает по-другому, чем при использовании NestedScrollView.
Я пытался установить различные свойства прокрутки в окне просмотра, но не смог понять это.
Вот видео, показывающее некоторые проблемы с прокруткой. https://youtu.be/xMLKoJOsTAM
Вот пример, показывающий проблему с RecyclerView (CheeseDetailActivity). https://github.com/tylerjroach/cheesesquare
Вот оригинальный пример, который использует NestedScrollView от Криса Бейнса. https://github.com/chrisbanes/cheesesquare
Ответы:
Ответ Кирилла Бояршинова был почти правильным.
Основная проблема заключается в том, что RecyclerView иногда дает неверное направление, поэтому, если вы добавите следующий код к его ответу, он будет работать правильно:
Я надеюсь, что это помогает.
источник
if (target instanceof SwipeRefreshLayout && velocityY < 0) { target = ((SwipeRefreshLayout) target).getChildAt(0); }
beforeif (target instanceof RecyclerView && velocityY < 0) {
Кажется, что
v23
обновление еще не исправило это.Я нашел что-то вроде взлома, чтобы исправить это сбрасыванием. Хитрость заключается в том, чтобы возобновить событие fling, если верхний дочерний элемент ScrollingView находится близко к началу данных в Adapter.
Используйте это в вашем макете так:
РЕДАКТИРОВАТЬ: пересмотр событий Fling теперь основан на
verticalScrollOffset
количестве предметов сверхуRecyclerView
.EDIT2: Проверьте цель как
ScrollingView
экземпляр интерфейса вместоRecyclerView
. И тоRecyclerView
и другоеNestedScrollingView
реализуем.источник
verticalScrollOffset
который является более общим. Теперь событие броска будет возобновлено приrecyclerView
прокрутке вверх.target instanceof RecyclerView
наtarget instanceof NestedScrollView
или более для общего случаяtarget instanceof ScrollingView
. Я обновил ответ.Я нашел исправление, применив OnScrollingListener к recyclerView. сейчас это работает очень хорошо. Проблема заключается в том, что просмотр в режиме повторного использования предоставил неверную потребляемую стоимость, а поведение не знает, когда просмотр в режиме повторного просмотра прокручивается до вершины.
источник
CoordinatorLayout
иViewPager
спасибо большое за это самое ожидаемое решение. Пожалуйста, напишите GIST для того же самого, чтобы другие разработчики также могли извлечь из этого пользу. Я тоже делюсь этим решением. Спасибо еще раз.Это было исправлено с момента поддержки дизайна 26.0.0.
источник
Это гладкая версия Google Support Design AppBarLayout. Если вы используете AppBarLayout, вы будете знать, что у него есть проблема с fling.
Смотрите библиотеку здесь .. https://github.com/henrytao-me/smooth-app-bar-layout
источник
Это ошибка повторного просмотра. Это должно быть исправлено в v23.1.0.
посмотрите https://code.google.com/p/android/issues/detail?id=177729
источник
v26.0.1
!Это мой макет и свиток. Он работает как надо.
источник
Мое решение пока основано на Мак Синге и Маноло Гарсии ответах .
Это не совсем идеально. Пока я не знаю, как пересчитать правильную скорость, чтобы избежать странного эффекта: панель приложения может расширяться быстрее, чем скорость прокрутки. Но состояние с расширенной панелью приложений и прокручиваемым видом переработчика не может быть достигнуто.
источник
Field viewFlingerField = recyclerView.getClass().getDeclaredField("mViewFlinger"); viewFlingerField.setAccessible(true); Object flinger = viewFlingerField.get(recyclerView); Field scrollerField = flinger.getClass().getDeclaredField("mScroller"); scrollerField.setAccessible(true); ScrollerCompat scroller = (ScrollerCompat) scrollerField.get(flinger); velocity = Math.signum(mVelocity) * Math.abs(scroller.getCurrVelocity());
В моем случае у меня возникла проблема, когда
RecyclerView
не будет плавно прокручиваться, заставляя его застрять.Это было потому, что по какой-то причине я забыл, что я положил
RecyclerView
вNestedScrollView
.Это глупая ошибка, но мне понадобилось время, чтобы понять это ...
источник
Я добавляю вид 1dp высоты внутри AppBarLayout и тогда он работает намного лучше. Это мой макет.
источник
Здесь уже есть несколько довольно популярных решений, но, поиграв с ними, я пришел к более простому решению, которое хорошо мне подошло. Мое решение также гарантирует, что
AppBarLayout
оно расширяется только тогда, когда прокручиваемый контент достигает вершины, что является преимуществом перед другими решениями.источник
Принятый ответ не работал для меня, потому что у меня было
RecyclerView
внутриSwipeRefreshLayout
иViewPager
. Это улучшенная версия, которая ищетRecyclerView
в иерархии и должна работать для любого макета:источник
Ответ: это исправлено в библиотеке поддержки v26
но v26 имеет некоторую проблему в кидании. Иногда AppBar отскакивает снова, даже если бросать не слишком сложно.
Как удалить эффект отскакивания на панели приложений?
Если вы столкнулись с той же проблемой при обновлении до версии v26, вот краткое изложение этого ответа .
источник
Джулиан Ос прав.
Ответ Маноло Гарсии не сработает, если просмотр у переработчика ниже порога и прокрутки. Вы должны сравнить
offset
мнение переработчика иvelocity to the distance
позицию, а не позицию.Я сделал версию Java, ссылаясь на кодлин Джулиана и вычитая отражение.
источник
BaseApplication
Я нашел исправление Эниз Билгин https://stackoverflow.com/a/45090239/7639018
Проблема была решена с библиотеками в этом хранилище.
( https://developer.android.com/topic/libraries/support-library/setup.html )
источник
Что касается трекера проблем Google , то это было исправлено в версии библиотеки поддержки Android 26.0.0-beta2
Пожалуйста, обновите вашу версию библиотеки поддержки Android 26.0.0-beta2.
Если какая-либо проблема не устранена, сообщите на трекер проблем Google, что они снова откроются для изучения.
источник
Добавление еще одного ответа здесь, так как вышеперечисленные, либо не полностью соответствовали моим потребностям, либо не очень хорошо работали. Этот частично основан на распространенных здесь идеях.
Так что же делает этот?
Сценарий сброса вниз: если AppBarLayout свернут, он позволяет RecyclerView переключаться самостоятельно, ничего не делая. В противном случае он сворачивает AppBarLayout и не позволяет RecyclerView выполнить его сброс. Как только он свернут (до точки, требуемой для данной скорости), и если остается оставшаяся скорость, RecyclerView сбрасывается с первоначальной скоростью за вычетом того, что AppBarLayout только что потребовал разрушения.
Сценарий вверх: если смещение прокрутки в RecyclerView не равно нулю, оно сбрасывается с исходной скоростью. Как только это закончится, и если еще останется скорость (т. Е. RecyclerView прокручивается в положение 0), AppBarLayout расширяется до точки, в которой исходная скорость минус только что потребленная потребность. В противном случае AppBarLayout расширяется до точки, требуемой исходной скоростью.
AFAIK, это поведение с отступом.
Здесь много размышлений, и это довольно обычай. Пока проблем не найдено. Это также написано на Kotlin, но понимание этого не должно быть проблемой. Вы можете использовать плагин IntelliJ Kotlin, чтобы скомпилировать его в байт-код -> и декомпилировать обратно в Java. Чтобы использовать его, поместите его в пакет android.support.v7.widget и установите его как поведение CoordinatorLayout.LayoutParams в AppBarLayout в коде (или добавьте конструктор, применимый к xml, или что-то еще)
источник
это мое решение в моем проекте.
просто остановите mScroller, когда получите Action_Down
XML:
FixAppBarLayoutBehavior.java:
источник
для androidx,
Если в вашем файле манифеста есть строка android: hardwareAccelerated = "false", удалите ее.
источник