Kotlin/Python fun hobby
В статье описан путь преобразования предложенного экспертами Google способа отображения страничных данных с использованием библиотеки Paging3 и Compose от развесистого сборника if'ов и when'ов, вероломно нарушающего все границы архитектурных слоев, до чистого, лаконичного и затягивающего в себя DSL.
С тех пор, как команда Google AndroidX представила на замену библиотеки SharedPreferences новую библиотеку DataStore, прошел почти год, однако популяризация новой либы явно не стоит в активных задачах. Иначе я не могу объяснить 1) неполноценный гайд, следуя лишь по которому, у вас вообще не соберется проект из-за отсутствия всех необходимых зависимостей и дополнительных build-задач для системы сборки, и 2) отсутствие не hello-world подобных примеров в CodeLabs, кроме одного, и то, заточенного не под пример использования библиотеки с нуля, а под миграцию с SharedPreferences на Preferences DataStore. Аналогично все статьи на Medium буквально или другими словами повторяют все то же, что написано в гайде Google, либо используют неправильные подходы для работы с DataStore, предлагая заворачивать асинхронный io-код в runBlocking прямо на ui-потоке.
А еще неплохо бы соединить "тыл" с "фронтом", так сказать: у Google имеется библиотека AndroidX Preferences, которая позволяет в два клика накидать готовый material-design фрагмент для управления настройками приложения, чтобы излюбленным способом кодогенерации освободить разработчика от написания boilerplate. Однако эта библиотека в качестве хранилища предлагает использовать устаревшие нынче SharedPreferences, а официального гайда по соединению с DataStore нет. В этой заметке я хотел бы своим способом устранить два описанных недостатка.
Прошло полгода, как я с паскаля перекатился на kotlin и влюбился в android-разработку, и вот уже разрешаю себе публично лезть со своими идеями в чужой монастырь. Но причина на то есть. Понаблюдав в профильных чатах за тем, какие чаще всего возникают вопросы у android-разработчиков, и не только у новичков, я понял, что в большинстве случаев, когда человек сталкивается с ошибкой, которую не может понять, как не может понять объяснение коллег из чата или их наводящие вопросы, причиной является бездумное использование готовых кусков кода или библиотек. Однако, полагаясь на готовые примеры кода, которые у них не работают (а в этой сфере код, написанный больше года назад, по умолчанию требует обновления или вообще переработки, и это касается кода со stack overflow, библиотечных гайдов и даже гайдов от самого Google), они не понимают причин возникающих ошибок или же отличающегося поведения, поскольку полагаются на библиотеку как китайскую комнату, не пытаясь разобраться в её архитектуре и принципах работы.
Поскольку очень часто всплывают вопросы, связанные с recycler view, я бы хотел немного разобраться в том, как самостоятельно сделать расширяемый и чистый код для отображения мульти-элементного списка в приложении.
Добрый, предновогодний день всем! В этой статье я бы хотел рассказать, как мне пришлось вернуться в legacy-проект на паскале, причем буквально перед тем, как навсегда распрощаться и с ним, и с лазарусом, и с отсутствием темной темы из коробки.
В прошлый раз я объяснял, что не являюсь программистом по роду профессиональной деятельности, но использую любимое хобби для автоматизации всего, что попадается под руку в работе юриста. Я уверен, что 90% всей юридической волокиты может быть успешно автоматизировано: ведение разнообразных баз и карточек, составление документов по шаблонам, контроль сроков выполнения задач, использование любых вспомогательных сервисов, уже имеющих свои api, для прикручивания автоматизации на конкретном рабочем месте и т.д. К этому нужно стремиться, чтобы по заветам Айзека Азимова высвободить время юриста для реализации основной задачи - размышлять над условиями договора и разводить демагогию в суде.
В своей работе (юридической) я готов автоматизировать всё, что только поддаётся этому. Но пока прокачанные нейросетями роботы из утопии Германа Грефа не появились и не отняли всю работу у рядовых юристов, рутина надолго останется нашим главным спутником. Автоматизация этой рутины — то, чем я периодически занимаюсь на протяжении последних лет, будь то многочисленные таблицы в excel с кучей формул, позволяющих быстро распечатать сотню однотипных документов-рассылок в word'е, ну или автоматически генерируемые отчеты. Но есть и такие вещи, которые простыми формулами и подстановками не сделаешь. Здесь на помощь приходит программирование, которым я увлекаюсь с детства, и так уж вышло, что началось это с delphi. Сейчас мне проще, чем в C# или python, осваивать которые начал недавно, сделать быстро какой-то проект в среде Lazarus, используя freepascal. И да, я на полном серьёзе считаю, что возможностей этой среды более, чем достаточно. Поэтому автоматизировать ЕГРЮЛ, как вы догадались, предстоит с помощью паскаля.
Изучать ООП (объектно-ориентированное программирование) можно двумя способами: или прочитать сотню книжек, в которых дается голая теория об устройстве классов и принципах наследования, полиморфизма, инкапсуляции, но так ничему и не научиться, или перестать беспокоиться и попытаться на практике освоить новые приемы, переработав, к примеру, готовые коды, а лучше с нуля изготовив что-то простое, но красивое.
Во всех книгах, посвященных паскалю, delphi и lazarus (я нашел аж целых две о последнем), очень схожая часть, посвященная ООП. По этим книгам можно много узнать о том, насколько круче ООП устаревшего структурного подхода, но так и не получить достаточных навыков применения этого на практике. Конечно, любой программист, использующий визуальные IDE, уже по умолчанию использует ООП, так как все компоненты и структурные элементы визуального приложения представляют собой объекты, однако свои собственные структуры и абстракции перенести в парадигму ООП бывает очень сложно. Чтобы понять всю прелесть и оценить открывающиеся перспективы, я решил сделать небольшое приложение, которое в конечном итоге превратилось в простенький screensaver. Заодно вспомнил о существовании тригонометрии.
Приложение будет рисовать на экране в случайных местах пятьдесят полярных роз с разными характеристиками: размер, цвет, количество лепестков. Потом их же затирать и рисовать новые, и т.д. Используя принципы структурного программирования, можно, конечно, сделать обычный многомерный массив объемом на 50 и в нем сохранять все уникальные характеристики. Однако стоит вспомнить, что паскаль подразумевает строгую типизацию данных, а, следовательно, массив не может состоять их элементов с разными типами. Можно сделать массив из записей (record), но чего уж мелочиться, от записи до класса — один шаг. Вот его мы и сделаем.