Kotlin *

Вторая статья из цикла о функциональном программировании на Kotlin с разбором принципа работы, концепции и способов применения каррирования на практике.

С 2016 года, после того, как я начал использовать Kotlin в Android-разработке, то ни разу не скучал по Java. В целом, Kotlin дал мне большее удовлетворение от разработки, чем Java для Android.

Тем не менее, время от времени я натыкаюсь на такие вещи, которых мне очень не хватает; того, как они были реализованы в Java. Ниже представлены 5 из них.

Меня зовут Аксёнов Вячеслав, я старший бэкенд Java/Kotlin разработчик в крупном энтерпрайзе. Однажды я попал на проект, полный микросервисов, в котором за конфигурацию отвечала такая штука как Spring Cloud. Чтобы разобраться как именно это работает я исследовал и прикрутил этот диковенный элемент к одному своему пет проекту. И в этой статье я пошагово покажу как я это сделал

Представьте, что команда инженеров всю ночь перетаскивала в продакшен новую систему, запускала ее, утром сделала свои первые заказы и даже получила их. Они еще не знают, что случится через 10 минут, поэтому полны радости и надежд. Но потом приходит пользовательский трафик — и взрываются чаты и мониторинги…

Но давайте по порядку. Меня зовут Александр Клюшкин. Я работаю в Самокате и на нашем примере расскажу о сложностях перехода на новый стек. Зачем и кому это может понадобиться?

Очень часто при проектировании высоконагруженных систем, основанных на микросервисной архитектуре, обнаруживается что «узким» местом, ограничивающим производительность системы и возможности ее масштабирования, становится передача сообщений и временные затраты на сериализацию-десериализацию сообщений и дополнительные расходы на установку соединения и начальные согласования. Решением может стать использование протокола gRPC с кодированием сообщений с применением Protocol Buffers (protobuf).

В этой статье рассмотрены подходы к реализации gRPC клиента и сервера для бэкэнда на Kotlin, разобран пример создания проекта для взаимодействия микросервисов через протокол gRPC с использованием возможностей Kotlin DSL и корутин.

Android 12. Splash Screen API. Делаем анимированный экран загрузки (кручение). Боли и подводные камни, с которыми я столкнулся при реализации нового сплеш-скрина для Android 12.

Долго я искал в сети способ сделать так, чтобы данные при построении списка RecyclerView не загружались целиком, а подгружались по мере его пролистывания пользователем. Несколько совершенно разных решений находил на StackOverflow. Пробовал применить - работало, но каждый раз, как-то криво и не надежно. После нескольких месяцев работы над проектом в режиме "Когда все дела сделаны и дети слезли с шеи", я наконец достиг, как мне кажется, идеального решения, чем и хочу поделиться в этой статье.

Привет Хабр!

Во время локдауна я решил поупражняться в разработке под Android. Начать решил с простой гиперказуальной игры с элементами дуэли. Взаимодействие игроков решил реализовать через отдельный сервер и websocket'ы, но пока читал про все это дело, понял, что простого туториала на русско-язычных ресурсах почему-то нет. Поэтому, решил восполнить этот пробел.

В этой статье я постараюсь описать как настроить WebSocket'ы на примере чата с сервером на SpringBoot и клиенте под Android.

Сейчас существует широкий спектр кроссплатформенных технологий, среди которых Flutter, React Native и, конечно же, Kotlin Multiplatform Mobile (KMP). Какую технологию стоит выбрать и почему именно ее? Давайте попробуем разобраться!

В работе над своим проектом больше всего времени я убил на то, чтобы разобраться, как правильно сохранить файл в общедоступную папку, например, Download. Мне не удалось найти четкого и ясного объяснения в интернете. Собирал информацию по частям и доходил до результата методом проб и ошибок.

Виной всей этой сложности - множество факторов. Языковой барьер: русский - английский, Kotlin - Java. Различия в способах копирования в разных версиях Android. Разобраться было не просто. В итоге - пишу этот гайд, чтобы облегчить жизнь тем, кто пойдет за мной следом...

Здравствуйте дорогие хабрчане. Это статья основана на статье https://blog.iamsuleiman.com/recyclerview-adapter-android-made-fast-easy/#clicklistener написанной в 2017 году на Java. А статью которую вы читаете, уже на Kotlin.

Каждый раз, когда мы думаем о создании RecyclerView, нас пугает объем кода, который должен войти в адаптер. Кроме того, если у этого адаптера много ViewHolder-ов, то спаси нас Бог!

Конечно, все мы знакомы с шаблонным кодом RecyclerView.Adapter. Но писать один и тот же код снова и снова — пустая трата времени.

Наверняка должен быть лучший способ?

Поздоровайтесь с FastAdapter!

Будучи поклонником здорового питания, увлёкся методом приготовления пищи с помощью горячего ферментирования. Смысл приготовления - щадящее нагревание в диапазонах 40-80 градусов в течение нескольких часов. Похоже на процесс "томления" из народных традиций. Для разных продуктов существуют свои температурные диапазоны работы естественных ферментов – природных катализаторов, которые преобразуют плохоперевариваемые вещества в пище в легкоусвояемые. Для приготовления нужно поддерживать температуру с нужной точностью и очередностью.

Привет, Хабр. Хочу поделиться своим решением одной из проблем использования корутин в Kotlin.

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

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

1. Опубликовал версию n в plugins.gradle.org
2. Проверил опубликованный плагин вручную на тестовом проекте
3. Нашел ошибку/доработал, увеличил версию n=n+1, затем снова пункт 1

Такой вот PDD (Publish Driven Development). Сегодня поговорим о том, как писать эффективные тесты на собственные gradle плагины.

Всем привет!. Многие знают что такое Redis, а если вы не знаете, то официальный сайт может ввести вас в курс дела. Большинство знают Redis как кэш и иногда как очередь сообщений. Но что если немножко сойти с ума и попытаться спроектировать целое приложение, используя в качестве хранилища данных только лишь Redis? Какие задачи можно решить с использованием Redis'а?

В этой статье мы и попытаемся ответить на эти вопросы.

Не переключайтесь.

Всем доброго времени суток! С вами Анна Жаркова, ведущий разработчик компании Usetech. Продолжаем говорить про Kotlin Multiplatform и работу с асинхронными функциями. В этой статье мы будем рассматривать, как можно удобно подключать Kotlin общий код на стороне iOS, используя возможности Swift. А именно, как работать с Combine Publishers и новым async/await.

_{* Примеры кода доступны в полной версии статьи, и к сожалению, не доступны в предпросмотре}

Концепция Kotlin Multiplatform позволяет нам сделать код максимально общим, т.е вынести практически все в общую часть.

Если на стороне common, мы оперируем корутинами и suspend функциями, то на стороне iOS проекта нативного благодаря поддержке interop Kotlin/Obj-C с версии Kotlin 1.4 suspend функции преобразуются в функции с completion handler.

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

Однако, не все любят простой синтаксис completion handler. А еще мы прекрасно знаем, что если ими злоупотреблять, можно легко попасть в ситуацию callback hell и потерять читабельность и чистоту кода.

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

Попробуем сделать наш Kotlin код совместимым с Combine Publishers. Для этого превратим вызов нашей suspend функции в AnyPublisher с использованием Future Deferred и Promise.

Всем привет! Меня зовут Базикалов Илья, я являюсь Андроид разработчиком в компании Broniboy. В нашем клиентском приложении мы используем библиотеку Koin для внедрения зависимостей. В своей статье я хочу вам показать, с какими проблемами мы столкнулись при работе с данной библиотекой и каким образом их решили (хоть и не полностью).

Привет, Хабр! На связи Александр Попко и Игнат Старшов, и сегодня мы расскажем про наш продукт ЭКОНС – систему визуализации, которая приносит СИБУРу миллиарды рублей в год.

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

Во-вторых, экономический эффект. Он тоже сильно зависит от выбранного инженерами и оператором нужного технологического режима. И вот здесь иногда сталкиваются две точки зрения, ведь оператор обычно мыслит в тоннах, а менеджер — сразу в рублях.

Поэтому мы создали конструктор под названием ЭКОНС. Если вкратце, то он помогает оператору наглядно (и что важно — в реальном времени) оценивать, как выбранный им режим технологического процесса прямо сейчас влияет на экономическую эффективность.

Общий экономический эффект от внедрения ЭКОНС на наших предприятиях —  уже около 2,7 млрд рублей. В статье рассказываем, как устроен продукт.

В одном из моих личных проектов я решил использовать Jetpack Compose в качестве основной технологии. Это означало, что моё приложение будет иметь одну Activity, а вся навигация будет выполняться с помощью Compose. Когда я начал планировать проект, библиотеки Compose Navigation ещё не было, как не было и способа внедрить ViewModel в Composable без использования компонентов Activity, Fragment или View. 

Но примерно за полгода до публикации этой статьи появилась библиотека Jetpack Compose Navigation, и Dagger-Hilt стал поддерживать Compose. Сегодня я расскажу о моём пути: поделюсь видением проблемы масштабируемости навигации на примерах Google и предложу её возможное решение.

Привет, Хабр! Меня зовут Сергей Велеско, я Android разработчик в настоящее время и инженер-конструктор печатных плат в прошлой жизни. В этой статье я расскажу, как мне удалось применить знания, полученные в прошлой профессии, и написать простое Android приложение для просмотра Gerber-файлов.