Согласен. Подобные меры можно было бы рассматривать как нечто хорошее только в сочетании с мерами, которые нанесут непоправимый ущерб ответственным лицам в случае нарушения правил. На примере пожара — даже если никто не погиб, тут же проверка и колоссальные штрафы за все нарушения. И в случае погибших ещё и реальный срок добавить. И только тогда можно будет говорить, что люди мотивированы соблюдать правила, поэтому проверки можно ослабить.
Только что попробовал с телефона. Как домашний wi-fi, так и мобильный интернет от мегафона дают ту же стабильную скорость. В целом, уже вечер, может успели уже что-нибудь пофиксить.
За весь день не почувствовал тормозов вообще. Ни в "случайных" ресурсах, ни в целевом твиттере. Даже после активного обсуждение с коллегами ничего не заметил — кидал им скриншоты со свободно грузящимися картинками на всех сайтах.
И это добавляет мистики. Ну у меня ведь те же доменные имена используются в адресе, так что и правила ограничений должны работать так же. Вообще не понимаю, что происходит.
Может, это просто не у всех провайдеров? У меня вот домашний интернет от билайна.
По-моему, пункты "Установка обновлений не вызывает ошибок" и "Обновления устанавливаются корректно" дублируют друг друга. Или это разные обновления?
Ещё интересно, почему появилась необходимость проверять установку, то есть, по сути, корректность сборки итогового файла. Вы как-то в процесс сборки вмешиваетесь? Просто со времён эклипса ни разу с подобными проблемами не сталкивался.
Ура, кто-то всё-таки читает мою писанину! Благодарю за Вашу реакцию)
Передать onClick в конструктор холдера — идея хорошая. Видимо, чтобы получить позицию кликнутого элемента, надо будет из холдера доставать adapterPosition (или как он там называется). Я подумаю над этим.
Для работы адаптеру не нужно знать ни про какие Lifecycle или LiveData-источники. Подписка на элементы происходит в активити (откуда Lifecycle и взялся), а метод setCallback добавлен только для более простого создания колбэка на основе этого источника. Наверно, если бы этот метод я сделал расширением (как изначально и хотел), класс адаптера получился бы чище.
Я, конечно, допускал, что писал велосипед, но не похоже, чтобы подход с submitList как-то решал мою задачу — перенос логики с выбором элементов на сторону ViewModel (я писал об этом в предыдущих статьях). Но я обязательно ещё почитаю по этому поводу.
Проблема с рассинхроном списка элементов и выбранными позициями мной ещё подробно не анализировалась. Возможно, это часть общей проблемы потокобезопасности, решение которой я указал в перспективах. Честно говоря, я пока даже не представляю, как корректно должен обработаться описанный Вами случай. Если обновление списка произошло "за мгновение до этого", то пользователь ещё не успел увидеть новые данные. Правильно ли говорить, что было осознанно выбрано то, что ты ещё не увидел? Хотя как минимум проанализировать возможность крашей в таких ситуациях лишним не будет, конечно.
В вопросительных предложениях глагол должен находиться в начале предложения. То есть, "click is locked" = "клик однозначно заблокирован", а в то время как "is click locked" = "а заблокирован ли клик?";
Наличие инкапсулированной, но при этом неочевидной логики (как то изменение положения статичного поля locked и запуск таймера) может привести к непредвиденному поведению нового кода с использованием этого метода, если за него возьмётся другой разработчик или же Вы сами достаточно надолго его забросите и вернётесь позже.
Вот один из тех постов, чьё тело серьёзно уступает скопившимся комментариям.
Не уверен, что смогу дать полезный совет, так как не испытываю проблем с отношением к разработке — мне это дело нравится, останавливаться не собираюсь. Едва ли я способен понять, что Вы ощущаете.
В любом случае, желаю найти дело, которое будет приносить удовольствие. От такого и устаёшь меньше, и охотнее изучаешь новое, чтобы поднимать собственную квалификацию. И неважно, будет ли это совершенно новая область или просто другое направление разработки.
А насчёт пользы… Лично для себя я решил, что если начальство платит мне зарплату (причём, весьма неплохую), значит я ему полезен. Иначе бы уволил. И ведь тот же пример с доставкой еды: Вы сделали сервис для пользователей более приятным/удобных/понятным (нужное подчеркнуть) — как по мне, польза очевидна.
Круто, что можно вынести ещё больше расчётов из главного потока, но мне всегда не нравилось программировать аннотациями, так как в моём понимании здесь проще ошибиться. Может быть, Вы развеете мои опасения: насколько легко ошибиться в описании тех или иных компонентов, что это выявится только на этапе кодогенерации или, ещё хуже, на этапе выполнения? Были ли добавлены линт-правила, чтобы на этапе компиляции некоторые ошибки отлавливать?
А Вы пользуетесь Xamarin.Forms? Или же просто на шарпе пишете нативный (насколько это можно так назвать) код платформы?
Просто я пробовал Xamarin.Forms достаточно давно, когда каждый второй кросс-платформенный компонент на андроиде жутко сбоил. Мне было бы интересно узнать, как сейчас с этим дела.
Любопытная идея с составлением разметки на сервере. Видимо, основная идея была в избежании потребности обновления клиента. Разумеется, интересны моменты "НО":
Часто ли возникают ситуации, когда под новые фичи всё равно приходится обновлять клиент?
Какова политика по поддержке старых версий? Особенно любопытно, как поведёт себя старая версия, которая получит с сервера информацию о новом (неизвестном ей) компоненте.
Насколько это оправданно, если проект по тем или иным причинам предполагается только на Android? То есть, клиент нужно писать только один.
Сравнима ли сложность написания "парсинга" конфигурации с сервера с простым написанием такого же приложения с нуля? Получится ли потом повторно использовать такой же механизм на новом проекте?
Позволю себе небольшое уточнение. Бизнес-логика (ViewModel) отвечает за то, в какой момент и куда необходимо переключить внимание пользователя. Грубо говоря, она просто указывает пальцем на место, которое нужно показать (разумеется, абстрактно, а не указывая конкретные классы активити/фрагментов).
В то время как представление, совершенно не рефлексируя, производит переключение в указанное место. То есть, это исполнитель, которому думать вообще не нужно.
Так что я скорее на стороне Viacheslav01.
1. Во ViewModel вам нужно показать Snackbar
И такую постановку задачи лично я считаю неверной. ViewModel максимум можно поставить задачу "Вывести сообщение пользователю". Реализация через Snackbar — подробности уровня представления.
Согласен. Подобные меры можно было бы рассматривать как нечто хорошее только в сочетании с мерами, которые нанесут непоправимый ущерб ответственным лицам в случае нарушения правил. На примере пожара — даже если никто не погиб, тут же проверка и колоссальные штрафы за все нарушения. И в случае погибших ещё и реальный срок добавить. И только тогда можно будет говорить, что люди мотивированы соблюдать правила, поэтому проверки можно ослабить.
Только что попробовал с телефона. Как домашний wi-fi, так и мобильный интернет от мегафона дают ту же стабильную скорость. В целом, уже вечер, может успели уже что-нибудь пофиксить.
За весь день не почувствовал тормозов вообще. Ни в "случайных" ресурсах, ни в целевом твиттере. Даже после активного обсуждение с коллегами ничего не заметил — кидал им скриншоты со свободно грузящимися картинками на всех сайтах.
И это добавляет мистики. Ну у меня ведь те же доменные имена используются в адресе, так что и правила ограничений должны работать так же. Вообще не понимаю, что происходит.
Может, это просто не у всех провайдеров? У меня вот домашний интернет от билайна.
По-моему, пункты "Установка обновлений не вызывает ошибок" и "Обновления устанавливаются корректно" дублируют друг друга. Или это разные обновления?
Ещё интересно, почему появилась необходимость проверять установку, то есть, по сути, корректность сборки итогового файла. Вы как-то в процесс сборки вмешиваетесь? Просто со времён эклипса ни разу с подобными проблемами не сталкивался.
Думаю, с линейным интерполятором анимация смотрелась бы лучше. Но в любом случае круто, спасибо.
Ура, кто-то всё-таки читает мою писанину! Благодарю за Вашу реакцию)
LifecycleилиLiveData-источники. Подписка на элементы происходит в активити (откудаLifecycleи взялся), а методsetCallbackдобавлен только для более простого создания колбэка на основе этого источника. Наверно, если бы этот метод я сделал расширением (как изначально и хотел), класс адаптера получился бы чище.submitListкак-то решал мою задачу — перенос логики с выбором элементов на сторону ViewModel (я писал об этом в предыдущих статьях). Но я обязательно ещё почитаю по этому поводу.По пункту 2 об именовании хотел бы сказать:
lockedи запуск таймера) может привести к непредвиденному поведению нового кода с использованием этого метода, если за него возьмётся другой разработчик или же Вы сами достаточно надолго его забросите и вернётесь позже.Вот один из тех постов, чьё тело серьёзно уступает скопившимся комментариям.
Не уверен, что смогу дать полезный совет, так как не испытываю проблем с отношением к разработке — мне это дело нравится, останавливаться не собираюсь. Едва ли я способен понять, что Вы ощущаете.
В любом случае, желаю найти дело, которое будет приносить удовольствие. От такого и устаёшь меньше, и охотнее изучаешь новое, чтобы поднимать собственную квалификацию. И неважно, будет ли это совершенно новая область или просто другое направление разработки.
А насчёт пользы… Лично для себя я решил, что если начальство платит мне зарплату (причём, весьма неплохую), значит я ему полезен. Иначе бы уволил. И ведь тот же пример с доставкой еды: Вы сделали сервис для пользователей более приятным/удобных/понятным (нужное подчеркнуть) — как по мне, польза очевидна.
Круто, что можно вынести ещё больше расчётов из главного потока, но мне всегда не нравилось программировать аннотациями, так как в моём понимании здесь проще ошибиться. Может быть, Вы развеете мои опасения: насколько легко ошибиться в описании тех или иных компонентов, что это выявится только на этапе кодогенерации или, ещё хуже, на этапе выполнения? Были ли добавлены линт-правила, чтобы на этапе компиляции некоторые ошибки отлавливать?
А Вы пользуетесь Xamarin.Forms? Или же просто на шарпе пишете нативный (насколько это можно так назвать) код платформы?
Просто я пробовал Xamarin.Forms достаточно давно, когда каждый второй кросс-платформенный компонент на андроиде жутко сбоил. Мне было бы интересно узнать, как сейчас с этим дела.
Любопытная идея с составлением разметки на сервере. Видимо, основная идея была в избежании потребности обновления клиента. Разумеется, интересны моменты "НО":
Позволю себе небольшое уточнение. Бизнес-логика (ViewModel) отвечает за то, в какой момент и куда необходимо переключить внимание пользователя. Грубо говоря, она просто указывает пальцем на место, которое нужно показать (разумеется, абстрактно, а не указывая конкретные классы активити/фрагментов).
В то время как представление, совершенно не рефлексируя, производит переключение в указанное место. То есть, это исполнитель, которому думать вообще не нужно.
Так что я скорее на стороне Viacheslav01.
И такую постановку задачи лично я считаю неверной. ViewModel максимум можно поставить задачу "Вывести сообщение пользователю". Реализация через
Snackbar— подробности уровня представления.