Android studio функция как параметр

Функция как параметр функции в Java

У меня есть класс, с Thread в качестве суперкласса, я передаю функцию в качестве параметра, и этот класс просто выполняет эту функцию. Этот класс использует его для создания потоков, поэтому я могу выполнять любую функцию в потоке, не создавая другой класс.

Теперь, чтобы создать несколько потоков одного и того же метода, я использую блок ‘for’, например:

Чего я хочу добиться, так это обобщить предыдущее «для», чтобы я мог выполнить метод, которому я передам в качестве параметров (следуя примеру) список «Компьютеров» и функцию. Этот метод выполнит блок «for» и создаст поток для каждого «компьютера», поэтому я передам в качестве параметра предыдущую функцию потоку, и эта функция будет иметь в качестве параметра «компьютер». Я хочу получить что-то вроде этого (ВНИМАНИЕ: НЕПРАВИЛЬНО):

Надеюсь, я хорошо себя объяснил, потому что это очень запутанная проблема.

2 ответа

Для синхронного решения посмотрите @JB Nizet.

Асинхронное решение

Во-первых, ваш ThreadEjecucionLambda класс не создает поток, потому что для запуска нового потока вам нужно вызвать метод start() из Thread .

Во-вторых, этот класс не имеет смысла! Thread уже работает таким образом.

В-третьих, Runnable как есть, не принимает аргумент. Что вам действительно нужно сделать, это создать свой собственный Runnable , который принимает Computer в качестве аргумента.

А затем используйте его для вашего метода выше.

В теме уже есть конструктор, принимающий Runnable в качестве аргумента и выполняющий его при запуске, поэтому ваш подкласс бесполезен и запутан. Не только это, но вы никогда не запускаете поток. Таким образом, вы можете просто запустить Runnable напрямую, не создавая Thread или ThreadEjecucionLambda.

Если я правильно понимаю, вы хотите выполнить ту же функцию, принимая компьютер в качестве аргумента, в списке компьютеров.

Вам не нужна тема, чтобы сделать это. Все, что вам нужно, это Consumer :

Но, как вы видите, этот метод бесполезен, поскольку вы можете просто вызвать forEach в списке напрямую.

Итак, предположим, что вы хотите напечатать имя каждого компьютера в списке, вы должны использовать

Источник

Передача функции в качестве параметра в Java

Я знакомлюсь с платформой Android и Java и требуемый для создания общего класса «NetworkHelper», который обработал бы большую часть сетевого кода, позволяющего мне просто назвать веб-страницы от него.

Я следовал этой статье из developer.android.com для создания моего сетевого класса: http://developer.android.com/training/basics/network-ops/connecting.html

В моем классе действия я использую класс этот путь:

Проблема, которую я имею, состоит в том, что я должен так или иначе сделать обратный вызов назад к действию, и это должно быть определимо в «downloadUrl ()» функция. Например, когда загрузка заканчивается, общественность пусто «handleWebpage (Строковые данные)» функция в действии называют с загруженной строкой как ее параметр.

Я сделал некоторый поиск с помощью Google и нашел, что должен так или иначе использовать интерфейсы для достижения этой функциональности. После рассмотрения немногих подобных stackoverflow вопросов/ответов я не получил его работа, и я не уверен, понял ли я интерфейсы правильно: Как я передаю метод в качестве параметра в Java? Быть честным использованием анонимных классов является новым для меня, и я не действительно уверен, где или как я должен применить отрывки примера кода в упомянутом потоке.

Таким образом, мой вопрос состоит в том, как я мог передать функцию обратного вызова своему классу сети и назвать его после того, как загрузка заканчивается? То, куда объявление интерфейса идет, реализует ключевое слово и так далее? Обратите внимание на то, что я — новичок с Java (имейте другой фон программирования хотя), таким образом, я ценил бы в течение объяснения 🙂 Спасибо!

Источник

Java: передача параметров по значению или по ссылке

Простое объяснение принципов передачи параметров в Java.

Многие программисты часто путают, какие параметры в Java передаются по значению, а какие по ссылке. Давайте визуализируем этот процесс, и тогда вы увидите насколько все просто.

Данные передаются между методами через параметры. Есть два способа передачи параметров:

Передача по значению (by value). Значения фактических параметров копируются. Вызываемый метод создает свою копию значений аргументов и затем ее использует. Поскольку работа ведется с копией, на исходный параметр это никак не влияет.

Передача по ссылке (by reference). Параметры передаются как ссылка (адрес) на исходную переменную. Вызываемый метод не создает свою копию, а ссылается на исходное значение. Следовательно, изменения, сделанные в вызываемом методе, также будут отражены в исходном значении.

В Java переменные хранятся следующим образом:

Локальные переменные, такие как примитивы и ссылки на объекты, создаются в стеке.

Объекты — в куче (heap).

Теперь вернемся к основному вопросу: переменные передаются по значению или по ссылке?

Java всегда передает параметры по значению

Чтобы разобраться с этим, давайте посмотрим на пример.

Пример передачи примитивов по значению

Поскольку Java передает параметры по значению, метод processData работает с копией данных. Следовательно, в исходных данных (в методе main ) не произошло никаких изменений.

Теперь рассмотрим другой пример:

Передача объекта

Что здесь происходит? Если Java передает параметры по значению, то почему был изменен исходный список? Похоже, что Java все-таки передает параметры не по значению? Нет, неправильно. Повторяйте за мной: «Java всегда передает параметры по значению».

Чтобы с этим разобраться, давайте посмотрим на следующую диаграмму.

Память стека (stack) и кучи (heap)

В программе, приведенной выше, список fruits передается методу processData . Переменная fruitRef — это копия параметра fruit . И fruits и fruitsRef размещаются в стеке. Это две разные ссылки. Но самое интересное заключается в том, что они указывают на один и тот же объект в куче. То есть, любое изменение, которое вы вносите с помощью любой из этих ссылок, влияет на объект.

Давайте посмотрим на еще один пример:

Передача объекта по ссылке Память стека (stack) и кучи (heap)

В этом случае для изменения ссылки fruitRef мы использовали оператор new . Теперь fruitRef указывает на новый объект, и, следовательно, любые изменения, которые вы вносите в него, не повлияют на исходный объект списка фруктов.

Итак, Java всегда передает параметры по значению. Однако мы должны быть осторожны при передаче ссылок на объекты.

Вышеприведенная концепция очень важна для правильного решения ваших задач.

Например, рассмотрим удаление узла в односвязном списке.

Удаление узла в связанном списке

Это решение работает во всех случаях, кроме одного — когда вы удаляете первый узел ( Position = 1 ). Основываясь на ранее описанной концепции, видите ли вы в чем здесь проблема? Возможно, поможет следующая диаграмма.

Удаление первого узла односвязного списка

Для исправления алгоритма необходимо сделать следующее:

В этой статье мы обсудили одну небольшую, но важную концепцию Java: передачу параметров.

Подробнее о курсе и программе обучения можно узнать на бесплатном вебинаре, который пройдет 15 апреля.

Источник

Как передать функцию в качестве параметра в Java?

Можно ли передать метод в Java-метод в качестве параметра? Если да, может ли кто-нибудь, пожалуйста, направить меня? Это не кажется тривиальным

ОТВЕТЫ

Ответ 1

Java 8 и выше

Используя лямбда-выражения Java 8+, если у вас есть класс или интерфейс только с одним абстрактным методом (иногда называемым типом SAM), например:

затем в любом месте, где используется MyInterface, вы можете заменить лямбда-выражение:

Например, вы можете очень быстро создать новую тему:

И используйте синтаксис ссылки на метод, чтобы сделать его еще чище:

Без лямбда-выражений эти два последних примера выглядят так:

До Java 8

Обычным шаблоном было бы «обернуть» его в интерфейсе, например, в Callable , а затем передать Callable:

Этот образец известен как Образец Команды.

Имейте в виду, что вам лучше всего создать интерфейс для вашего конкретного использования. Если вы решили использовать callable, то вы заменили бы T выше на любой тип возвращаемого значения, например String.

В ответ на ваш комментарий ниже вы можете сказать:

затем назовите его, возможно, используя анонимный внутренний класс:

Имейте в виду, что это не «трюк». Это просто базовый концептуальный эквивалент java для функциональных указателей.

Ответ 2

Вы можете использовать отражение Java для этого. Этот метод будет представлен как экземпляр java.lang.reflect.Method.

Ответ 3

Лямбда-выражения

Чтобы добавить к jk. отличный ответ, теперь вы можете легко пройти метод, используя Lambda Expressions (в Java 8). Во-первых, некоторый фон. Функциональный интерфейс — это интерфейс, который имеет один и только один абстрактный метод, хотя он может содержать любое количество методов по умолчанию (новое в Java 8) и статические методы. Выражение лямбда может быстро реализовать абстрактный метод без всякого ненужного синтаксиса, если вы не используете выражение лямбда.

Синтаксис лямбда-выражений

Лямбда-выражение состоит из следующего:

Список формальных параметров, разделенных запятыми, заключенных в круглые скобки. Метод CheckPerson.test содержит один параметр, p, который представляет экземпляр класса Person.

Примечание: вы может опустить тип данных параметров в лямбда-выражении. В Кроме того, вы можете опустить круглые скобки, если есть только один параметр. Например, справедливо также следующее выражение лямбда:

Тело, состоящее из одного выражения или блока операторов. В этом примере используется следующее выражение:

Если вы укажете одно выражение, то среда выполнения Java оценит выражение и затем вернет его значение. С другой стороны, вы можете использовать оператор return:

Оператор return не является выражением; в выражении лямбда вы должны заключать выражения в фигурные скобки (<>). Однако у вас нет чтобы заключить вызов метода void в фигурные скобки. Например, следующее является действительным лямбда-выражением:

Обратите внимание, что лямбда-выражение очень похоже на объявление метода; вы можете рассматривать лямбда-выражения как анонимные методы-методы без имени.

Вот как вы можете «передать метод» с помощью выражения лямбда:

Примечание: здесь используется новый стандартный функциональный интерфейс, java.util.function.IntConsumer .

Приведенный выше пример можно сократить еще быстрее, используя оператор :: .

Ответ 4

Благодаря Java 8 вам не нужно выполнять следующие шаги, чтобы передать функцию методу, для чего предназначены лямбда, см. Oracle Lambda Expression учебник. Остальная часть этого сообщения описывает, что мы привыкли делать в плохие старые дни, чтобы реализовать эту функциональность.

Обычно вы объявляете свой метод как принятие какого-либо интерфейса с помощью одного метода, затем вы передаете объект, реализующий этот интерфейс. Например, в коллекциях commons, где у вас есть интерфейсы для Closure, Transformer и Predicate и методы, которые вы передаете им. Guava — это новые улучшенные коллективные фонды, вы можете найти там эквивалентные интерфейсы.

Так, например, в коллекциях коллекций есть org.apache.commons.collections.CollectionUtils, который имеет множество статических методов, которые принимают объекты, переданные в, выбирать их случайным образом, там один называется с этой сигнатурой:

Требуется объект, реализующий интерфейс Predicate, что означает, что он должен иметь на нем метод, который принимает некоторый объект и возвращает логическое значение.

Поэтому я могу назвать это следующим образом:

и он возвращает true или false в зависимости от того, содержит ли someCollection объект, для которого предикат возвращает true.

Во всяком случае, это всего лишь пример, и коллективные фонды устарели. Я просто забываю эквивалент в Гуаве.

Ответ 5

Java поддерживает закрытие просто отлично. Он просто не поддерживает функции, поэтому синтаксис, который вы использовали для закрытия, намного более неудобен и громоздки: вы должны обернуть все в классе с помощью метода. Например,

Вернет объект Runnable, метод run() которого «закрывает» переданный x , как и на любом языке, который поддерживает функции и закрытия первого класса.

Ответ 6

Я использовал шаблон команды @jk. упоминается, добавив тип возврата:

Ответ 7

Я знаю, что это довольно старый пост, но у меня есть другое, немного более простое решение. Вы можете создать другой класс внутри и сделать его абстрактным. Затем сделайте абстрактный метод, назовите его как хотите. В исходном классе создайте метод, который принимает новый класс в качестве параметра, в этом методе вызовите абстрактный метод. Это будет выглядеть примерно так.

Теперь вы можете сделать что-то подобное для вызова метода из класса.

Как я уже сказал, я знаю, что он старый, но так я думаю, что это немного проще. Надеюсь, поможет.

Ответ 8

Java не поддерживает (пока) поддержку закрытий. Но есть и другие языки, такие как Scala и Groovy, которые запускаются в JVM и поддерживают закрытие.

Источник

Советы по чистому коду новичкам в Java/Android

Теме чистого кода на одном только habrahabr посвящено тысячи статей. Никогда бы не подумал, что захочу написать свою. Но после проведения компанией курсов для желающих связать карьеру с разработкой ПО, в частности разрабатывать под Android, мое мнение поменялось.

За основу статьи взяты советы из классики “Роберт К. Мартин: Чистый код”. Отобрал из них те, которые наиболее часто встречались в виде проблем у студентов. Приведенные советы написаны с учетом моего опыта разработки коммерческих Android приложений. Поэтому не ко всем Android-проектам приведенные ниже советы подойдут, я уже не говорю про другие системы.

Советы в основном приводил с примерами кода как НЕ НУЖНО делать. Как ни странно, у большинства студентов были одни и те же ошибки. Все примеры кода были придуманы, любые совпадения с реально существующим кодом случайны.

Общие советы

1. Код должен быть легко читаемым, понятным и очевидным

Программисты большую часть времени тратят на чтение и анализ написанного кода, а не на написание нового. Важно чтобы Ваш код был легко читаемым, понятным и с прогнозируемым поведением. Это позволит коллегам и Вам по прошествии времени затратить минимальное время на понимание того, что делает каждый кусок кода. Понятный код с прогнозируемым поведением позволит уменьшить вероятность ошибки при внесении изменений не автором кода.

2. При написании кода нужно придерживаться Java Code Conventions либо других спецификаций, принятых на проекте командой

Спецификацию можно сравнить с правилами оформления текста книги. Думаю, немногие захотят читать книгу, где каждый абзац отличается шрифтом, размером и цветом текста. Так и с кодом, куда легче читать оформленный в едином стиле код.

Наименование

1. Имена классов, функций, переменных и параметров должны передавать закладываемый в них смысл.

Довольно очевидный совет, но не всегда его придерживаются. Тут, в качестве примера, можно привести оглавление книги: если все главы названы просто «Главами», то понять в чем суть нельзя. Наименования классов, функций должны сообщать об их предназначении без погружения в детали реализации.

Наименования классов MyActivity, CustomView, MyAdapter говорит только об одном, что это не часть Android SDK и все. SecondActivity говорит, что это не часть Android SDK и о наличии в проекте еще одного Activity, но не факт =)

Правильно именовать классы: MainActivity, FoodsActivity, FoodCartActivity, PhoneInputView . MainActivity — очевидно, что основной разводящий экран приложения. FoodsActivity — экран с перечнем продуктов. PhoneInputView — компонент ввода номера телефона.

Следующие названия переменных бесполезны и нарушают правила наименования:

как и параметры конструктора:

2. Название публичного класса и файла должно совпадать.

Есть следующий класс

Название файла при этом оказывается “products_Activity.java”.
Это не правильно. Название публичного класса и java-файла должны совпадать.

3. В наименованиях нужно использовать только буквы латинского алфавита, никаких цифр, символов подчеркивания и дефисов. Исключения составляют наименования из стандартов (ГОСТ, ISO), символы подчеркивания для разделения слов в наименованиях констант.

Примеры выше: m_textview_1 . Часто вместо lastName пишут userName2 , что не правильно.

4. Не нужно использовать строчные “L” и “O” в качестве имен локальных переменных, т.к. их трудно отличить от “1” и “0”.

Надуманный пример, но что-то подобное я встречал в своей практике

В этой функции пузырьковой сортировки есть одна ошибка, сможете за секунды ее найти=)?
Такой код труден для чтения и при написании легко сделать ошибку, которую можно очень долго искать.

5. Не нужно указывать тип в суффиксе имен.

Вместо accountList нужно писать просто accounts . Это позволит в любое время изменить тип переменной без переименования самой переменной.
А еще ужаснее выглядит nameString, ageFloat .

Исключение составляют наследники классов Android SDK: Activity, Fragment, View, Uri и т.д. По названию NewsSynsService сразу понятно, что класс является «сервисом» и ответственен за синхронизацию новостей. Использование суффикса view в nameView, photoView позволяет легко отличить переменные, относящиеся к верстки, от остальных. Имена view обычно начинают с существительного. Но имена кнопок лучше начинать с глагола: buyButton

6. Имена могут и должны содержать термины из математики, названия алгоритмов, паттернов проектирования и т.д.

Увидев имя BitmapFactory , не автор кода сразу поймет смысл этого класса.

7. Не нужно указывать никакие префиксы при именовании.

Вместо m_user, mUser просто пишется user . Указывать префикс s для статических полей в современных IDE излишне.

Исходники Android SDK не являются здесь показателем в силу давности создания первых версий и наследования кодовой базы до наших дней.

s_ ни к чему в начале названия статического поля. К тому же название констант должно писаться прописными буквами:

8. В наименование классов нужно использовать существительные.

Классы это как объекты реального мира. Поэтому нужно использовать существительные для их названия: AccountsFragment, User, Car, CarModel .

Не нужно называть классы Manager, Processor, Data, Info , т.к. они имеют слишком общее значение. Лучше название класса длиной в два-четыре слова, чем просто Data .

9. Названия классов должны начинаться с прописной буквы.

Слова НЕ должны отделяться символом подчеркивания. Нужно следовать нотации CamelCase: GoodsFragment, BaseFragment

10. Используйте одно слово для каждой концепции.

Использование fetch, retrieve, get в одном классе сбивает с толку. Если класс назвали Customer , то имена переменных класса и параметров функций этого типа лучше называть customer , а не user .

Функции

1. Функция должна выполнять только одну “операцию”. Она должна выполнять ее хорошо. И ничего другого она делать не должна.

Под “операцией” следует понимать не одну математическую операцию или вызов другой функции, а действия на одном уровне абстракции. Чтобы определить, что функция выполняет более одной операции, следует попробовать извлечь из нее другую функцию. Если извлечение функции не дает ничего кроме простой перестановки кода, то значит разбивать дальше функцию не имеет смысла

К примеру есть функция setProducts класса ProductsAdapter :

Внутри функции происходит три основных операции: 1) фильтрация newProducts , 2) очистка и вставка новых значений в products , 3) обновление адаптера notifyDataSetChanged .

Фильтрация элементов newProducts должна происходить в другом методе и даже в другом в класса (например в presenter-е). В ProductsAdapter должны прийти уже отфильтрованные данные.

Лучше переделать код следующим образом:

Параметр newProducts содержит уже отфильтрованный список продуктов.
Можно еще строчки java products.clear(); products.addAll(newProducts);
вынести в отдельную функцию, но особого смысла я в этом не вижу. Лучше заменить notifyDataSetChanged на DiffUtil, это позволит обновлять ячейки в списке эффективнее

2. Размер функции должен быть 8-10 строк.

Функция размером в 3 экрана это не функция, это *****. У меня тоже не всегда получается ограничить размер функции 8-10 строками кода, но нужно стремится к этому. Пример по понятным причинам приводить не буду.

Функции большого размера трудно читать, модифицировать и тестировать. Разбив большую функцию на малые, легче будет понять смысл основной функции, так как мелкие детали будут скрыты. Выделяя функции можно увидеть и избавиться от дублирования кода в основной функции.

3. В теле функции все должно быть на одном уровне абстракции.

Вычисление значения локальной переменной errorMessage имеет более низкий уровень абстракции, чем остальной код внутри функции. Поэтому код java «Article » + article.getName() + » is incorrect» лучше вынести в отдельную функцию.

4. Наименовании функции и передаваемых параметров должно сообщать о том, что делает функция

Причиной выделения блока кода в отдельную функцию может являться желание в пояснении, что делает код. Для этого нужно дать подходящее название функции и параметрам функции.

Непонятно по какому полю будет происходить поиск, что передается на вход функции.

Лучше переделать в следующий вид:

Название функции говорит, что происходит поиск Product по полю id . На вход функция принимает не “null” значение. Если Product не найдется, то вернется “null”.

Роберт К. Мартин советует использовать параметры в качестве части названия функции:

Вызов функции может выглядеть так:

На проектах я такой способ не встречал. Лучше данный способ не использовать и писать полностью название:

5. Имена функций должны начинаться с глагола. Лучше длинное имя, чем не содержательное короткое.

Название start не сообщает, что именно стартует функция. Только заглянув в тело становится понятно, что функция открывает Activity.

А должно быть понятно предназначение функции уже по названию.

6. Вместо передачи в аргументы функции флага (boolean) лучше разбить функцию на две функции

Часто этот флаг является причиной увеличение размера функции при ветвлении логики выполнения в зависимости от значения флага. В таких случаях следует подумать о разбиении данной функции на две. Разное поведение функции в зависимости от переданного флага не всегда очевидно.

7. Дублирующий код следует выносить в отдельную функцию.

Код внутри setOnClickListener отличается только стилем. Этот код стоит вынести в отдельный метод:

8. Не передавайте и не возвращайте из функции “null” когда можно вернуть пустой объект.

Это позволит избежать ошибок NullPointerexception и не нужно будет в местах вызова писать проверки на null.

Kotlin поможет отучиться от вредной привычки передавать и возвращать null.)

Форматирование

1. Код в классе должен читаться сверху-вниз как газетная статья в порядке убывания уровня абстракции. Вначале идут публичные функции, затем приватные.

Основная идея совета в том, что при открытии файла программист начинает просматривать его сверху. Если вначале разместить все публичные функции, то легче будет понять основные операции с объектами класса, ответственность класса и где может использоваться. Данный совет подходит, когда проект строится на интерфейсах.

2. Связанные концепции/функции следует размещать рядом, чтобы не было необходимости постоянно перемещаться по файлу вверх-вниз. Если одна функция вызывает другую, то вызываемая функция должна располагаться под вызывающей функцией (если это возможно) и разделяться пустой строкой.

Данный совет может противоречить предыдущему. Выбрав приоритетный совет для команды, стоит придерживаться его на всем проекте.

3. Каждая последовательная группа строк кода должна представлять одну законченную мысль. Мысли отделяются друг от друга в коде с помощью пустых строк, только слишком злоупотреблять пустыми строчками не стоит

Связанная группа строк это как абзацы в статье. Для разделения абзацев используется красная строка или пустая строка. Так и в коде следует разделять разные по смыслу группы строк, используя пустые строки.

4. Переменные экземпляра класса, статические константы должны быть все в начале класса в одном месте.

В начале класса объявляются публичные константы, затем приватные константы и после них идут приватные переменные.

5. Используйте пробелы для повышения читаемости кода

• в математических операциях для отделения символа операции от операндов: int x = a + b;
• отделения параметров функций: private Article createNewArticle(String title, String description)
• передаваемых параметров функции: createNewArticle(title, description)

6. «Магические цифры, строки» должны быть вынесены в константы .
Пожалуй, самый популярный совет, но все равно продолжают его нарушать.

Лишь прочитав постановку задачи я понял, для чего в коде использовалось число “10”. Лучше это число вынести в константу и дать осмысленное имя.

Строки тоже стоит выносить в константы, особенно если используются в более чем одном месте.

Классы

1. Класс должен иметь одну “ответственность”, одну причину для изменения.

К примеру, наследники класса RecyclerView.Adapter должны отвечать за создание и связывание View с данным. В нем не должен находится код сортировки/фильтрации списка элементов.
Часто в файл с Activity добавляют класс RecyclerView.Adapter, что является не правильным.

2. Не нужны пустые методы или просто вызывающий метод из родительского класса

3. Если переопределяете какой-то метод без вызова метода родительского, то проверьте, что так можно делать.

Загляните в исходники родительских классов, документации. Переопределяемые методы жизненного цикла Activity, Fragment, View должны обязательно должны вызывать методы родительского класса.

Есть аннотация @CallSuper , предупреждающая о необходимости вызывать родительский метод при переопределении.

Советы о разном

1. Используйте средства Android Studio для улучшение качества Вашего кода.

Если она подчеркивает или выделяет код, значит что-то может быть не так. В Android Studio есть средства Rearrange, Reformat, Extract Method, Inline Method, анализаторы кода, горячие клавиши и т.д.

2. Не нужно комментировать каждый метод, код должен быть самодокументированным.

Следует отметить, что комментарии должны пояснять намерения и причины, а не поведение кода. Создавая комментарий, необходимо брать на себя ответственность о поддержании комментария в актуальном состоянии.

3. Строки, цвета, размеры должны быть в ресурсах (xml)

Не нужно писать:

Исключения составляют файлы из папок test, mock. Такие файлы не должны попадать в релизную версию

4. Не нужно передавать context в RecyclerView.Adapter. context можно получить из любой view. Элемент по клику в RecyclerView.Adapter должен меняться через notifyItemChanged, а не непосредственным изменением вьюшек в методе обработки нажатия

В методе onClick непосредственно происходит вызов bindViewHolder , что НЕ правильно.

5. В RecyclerView.ViewHolder вместо определения позиции объекта в списке нужно вызывать getAdapterPosition, а не передавать position из метода onBindViewHolder

Правильно писать:

Либо можно вместо позиции передавать ссылку на исходный объект с данными

6. Используйте Quantity Strings (Plurals) для множественного числа. Вместо написания в коде логики по подбору правильного окончания слов.

7. Не сохраняйте большие данные Bitmap в bundle. Размер bundle ограничен

8. Если прописать “id” в xml, то Android сам восстановит состояние стандартных View при повороте.

Источник