Я пропал на две недели, потому что у меня началась ноябрьская депрессия. Депрессия вызванная необходимостью найти новую квартиру в Питере. Появилась эта необходимость из-за арендодателя, который решил выселить меня в лучших традициях крупных компаний – без объяснения причины.
И толи мне везло в предыдущие года, толи рынок и правда ебанулся на фоне повышения курса и ставки, но цены на нормальные квартиры неожиданно улетели в космос. Ну да ладно, разумеется я бы не стал делать пост, в котором я только жалуюсь на рынок недвижимости, я буду жаловаться и на либы от гугла.
Пока я искал квартиру, я понял четкую разницу: есть квартиры которые изначально делались для сдачи и есть квартиры которые делались для себя, но затем по тем или иным причинам начали сдаваться. И вот в обоих случаях может быть крутой ремонт все аккуратно, но в некоторых мелочах ты начинаешь замечать что ну вот не то, видно что сделано на похер.
Аналогичная ситуация с библиотеками. Я искренне считаю, что нельзя вот так взять и сделать крутое решение, просто потому что "вот было бы неплохо сделать новый OkHttp". Действительно крутые либы всегда рождаются, когда на каком-то рабочем проекте возникает геморройная задача, которую не решить существующими решениями. Ты делаешь свое, для решения проблемы и вуяля.
И вот взять Paging Library. Вот смотришь на API и документацию и думаешь, ну ведь круто сделали! Довольно удобно, просто, можно читать из БД и из сети, все про красоте прям. Даже учли мега редкие кейсы вроде пагинации в верх и вниз. Вероятнее всего это нигде кроме Твиттера не понадобится, тем не менее.
Однако когда начинаешь ее затаскивать, понимаешь что, они конечно красиво решили проблемы, правда не те, которые нужно было решать. Простой пример, мне нужно было обновлять список из ViewModel по наступлению события. Ну например, я перехожу в другой экран, там пользователь может что-то такое сделать, чтобы когда он вернулся назад, экран обновился, т.е сделать PullToRefresh на стороне ViewModel.
Дефолтная вроде бы задача, но для Paging Library это настоящий Big Deal. API либы не позволяет это сделать на уровне логики, обновить данные может только пользователь. Другими словами, из UI нужно дернуть специальный метод, чтобы список обновился. Если ты хочешь обновить данные сам, то нужно отправлять событие на UI, чтобы из UI дернуть этот метод. Это какой-то абсурд, они же сами дают рекомендацию по разделению приложения на слои, но вынуждают делать вот такие приколы.
Если заглянуть внутрь, то там прям кладезь крутых примеров как делать не стоит. Как часто у вас возникает идея запихать Flow, в data класс и отправить куда-то? Создатели либы в этом не видят ничего дурного. И вот я думаю, толи я тупой, чтобы понять грандиозный замысел, толи они херней страдают…
Я пропал на две недели, потому что у меня началась ноябрьская депрессия. Депрессия вызванная необходимостью найти новую квартиру в Питере. Появилась эта необходимость из-за арендодателя, который решил выселить меня в лучших традициях крупных компаний – без объяснения причины.
И толи мне везло в предыдущие года, толи рынок и правда ебанулся на фоне повышения курса и ставки, но цены на нормальные квартиры неожиданно улетели в космос. Ну да ладно, разумеется я бы не стал делать пост, в котором я только жалуюсь на рынок недвижимости, я буду жаловаться и на либы от гугла.
Пока я искал квартиру, я понял четкую разницу: есть квартиры которые изначально делались для сдачи и есть квартиры которые делались для себя, но затем по тем или иным причинам начали сдаваться. И вот в обоих случаях может быть крутой ремонт все аккуратно, но в некоторых мелочах ты начинаешь замечать что ну вот не то, видно что сделано на похер.
Аналогичная ситуация с библиотеками. Я искренне считаю, что нельзя вот так взять и сделать крутое решение, просто потому что "вот было бы неплохо сделать новый OkHttp". Действительно крутые либы всегда рождаются, когда на каком-то рабочем проекте возникает геморройная задача, которую не решить существующими решениями. Ты делаешь свое, для решения проблемы и вуяля.
И вот взять Paging Library. Вот смотришь на API и документацию и думаешь, ну ведь круто сделали! Довольно удобно, просто, можно читать из БД и из сети, все про красоте прям. Даже учли мега редкие кейсы вроде пагинации в верх и вниз. Вероятнее всего это нигде кроме Твиттера не понадобится, тем не менее.
Однако когда начинаешь ее затаскивать, понимаешь что, они конечно красиво решили проблемы, правда не те, которые нужно было решать. Простой пример, мне нужно было обновлять список из ViewModel по наступлению события. Ну например, я перехожу в другой экран, там пользователь может что-то такое сделать, чтобы когда он вернулся назад, экран обновился, т.е сделать PullToRefresh на стороне ViewModel.
Дефолтная вроде бы задача, но для Paging Library это настоящий Big Deal. API либы не позволяет это сделать на уровне логики, обновить данные может только пользователь. Другими словами, из UI нужно дернуть специальный метод, чтобы список обновился. Если ты хочешь обновить данные сам, то нужно отправлять событие на UI, чтобы из UI дернуть этот метод. Это какой-то абсурд, они же сами дают рекомендацию по разделению приложения на слои, но вынуждают делать вот такие приколы.
Если заглянуть внутрь, то там прям кладезь крутых примеров как делать не стоит. Как часто у вас возникает идея запихать Flow, в data класс и отправить куда-то? Создатели либы в этом не видят ничего дурного. И вот я думаю, толи я тупой, чтобы понять грандиозный замысел, толи они херней страдают…
When choosing the right name for your Telegram channel, use the language of your target audience. The name must sum up the essence of your channel in 1-3 words. If you’re planning to expand your Telegram audience, it makes sense to incorporate keywords into your name. Invite up to 200 users from your contacts to join your channel Select “New Channel” Today, we will address Telegram channels and how to use them for maximum benefit.
from us
