Kotlin уже давно стал основным языком программирования на Android. Одна из причин, почему мне нравится этот язык, это то, что функции в нем являются объектами первого класса. То есть функцию можно передать как параметр, использовать как возвращаемое значение и присвоить переменной. Также вместо функции можно передать так называемую лямбду. И недавно у меня возникла интересная проблема, связанная с заменой лямбды ссылкой на функцию.
«Корутины - это легковесные потоки», сколько раз вы слышали эту формулировку? Она что-нибудь вам говорит? Скорее всего не очень много. Если вы хотите узнать больше о том, как на самом деле корутины выполняются в рантайме Android, как они связаны с потоками, а также о проблемах параллелизма, которые неизбежны при использовании потоковой модели языка программирования Java, то эта статья для вас.
Каждый, кто использовал Чистую архитектуру в разработке, сталкивался с проблемой передачи данных между слоями. Суть проблемы всегда одинакова: необходимо вернуть либо результат, либо ошибку.
Вдруг вам надо листать фрагменты через ViewPager2 и при этом подменять их динамически. Например, чтобы уйти "глубже" - пользователь из фрагмента "Главные настройки" переходит во фрагмент "Выбор языка".
При этом новый фрагмент должен отобразиться на месте предыдущего фрагмента. А потом пользователь еще и захочет вернуться обратно...
Kotlin имеет много классных особенностей: null safety, smart casts, интерполяция строк и другие. Но одной из самых любимых разработчиками, по моим наблюдениям, являются data-классы. Настолько любимой, что их часто используют даже там, где никакой функциональности data-класса не требуется.
В этой статье я с помощью эксперимента постараюсь понять, какова реальная цена использования большого количества data-классов в приложении. Я попробую удалить все data-классы, не сломав компиляцию, но сломав приложение, а потом расскажу о результатах и выводах этого эксперимента.
Совсем недавно, 24 февраля, мы анонсировали запуск бета-версии Jetpack Compose. Этот новый набор инструментов для разработки пользовательского интерфейса позволит легко и быстро создавать оригинальные приложения для всех платформ Android. Jetpack Compose предоставляет современные и декларативные API для языка Kotlin для создания привлекательных и быстрых приложений с меньшим объемом кода. Набор совместим с существующими приложениями для Android и библиотеками Jetpack. Кроме того, его можно использовать вместе с Android Views.
Бета-версия Compose – это уже готовый API со всеми основными функциями, необходимыми для комфортной работы. Версия стабильная, поэтому мы не будем изменять или удалять API. Финальная версия 1.0 станет доступна уже в этом году. Сейчас самое время начать знакомство с Compose и запланировать применение новых инструментов в следующих проектах и компонентах.
Я работаю Java/Kotlin-разработчиком в компании EPAM.
В этой статье хочу поделиться опытом настройки плагина ktlint для Kotlin проекта.
Данный плагин помогает обеспечивать единый code style на проекте. Он построен на официальных рекомендациях по форматированию кода для Kotlin от JetBrains. С помощью данного инструмента можно не только проверить код, но и отформатировать его.
Для разработчиков не секрет, что создание нового сервиса влечет за собой немало рутиной настройки: билд скрипты, зависимости, тесты, docker, k8s дескрипторы. Раз мы выполняем эту работу, значит текущих шаблонов IDE недосточно. Под катом мои попытки автоматизировать все до одной кроссплатформенной кнопки "сделать хорошо" сопровождаемые кодом, примерами и финальным результатом.
Если перспективы создания сервисов в один клик с последующим автоматическим деплоем в Digital Ocean звучат заманчиво, значит эта статья для вас.
Работая над одним проектом продолжительное время, я заметил как приходится переписывать код, который еще три месяца назад казался хорошим. Инженерам поступают новые требования, когда они не пересекаются с предыдущими - все отлично, добавили пару новых классов и побежали дальше. Иногда они касаются уже выпущенной части - взмах синей изолентой и все работает. Но наступает тот самый момент, когда цена внесения изменений катастрофически дорога и единственной рациональное решение - переписать все... А можно ли писать код, не переписывая его в будущем или хотя бы отложить этот момент на более долгий срок?
Я хочу рассказать про практики, которые не один раз уже выручали нас в проекте. Подборка примеров получилась не на пустом месте, все реальные примеры PullRequest-ов.
Все примеры НЕ выдуманные и тестировались на живых людях. В процессе сбора данных несколько людей пострадало.
Продолжение цикла публикаций про автоматизацию функционального тестирования на Kotlin
с использованием фреймворка Kotest совместно с наиболее полезными дополнительными библиотеками, существенно облегчающими и ускоряющими создание тестов.
В этой части мы углубимся в возможности Kotest:
Все части руководства:
В своих проектах мы стараемся по мере необходимости покрывать код тестами и придерживаться принципов SOLID и чистой архитектуры. Хотим поделиться с читателями Хабра переводом статьи Hannes Dorfman – автора серии публикаций об Android-разработке. В этой статье описан способ, который помогает абстрагировать работу со строками, чтобы скрыть детали взаимодействия с разными типами строковых ресурсов и облегчить написание юнит-тестов.
Если вы работаете над большим Android-приложением и предполагаете, что в коде может появиться путаница в работе с ресурсами из разных источников, или если хотите упростить написание тестов в отношении строк, то эта статья может быть вам полезна. Переводим с разрешения автора.
Всем привет! Идея для этой статьи пришла еще месяц назад, но в силу занятости на работе времени катастрофически не хватало. Однажды вечером в YouTube я наткнулся на ролик о создании игры-платформера в стиле пиксельной графики. И тут мне вспомнились мои первые уроки информатики в школе, где мы "рисовали на Бейсике" и играли в "ворона ест буквы".
Всем привет! В своей работе я часто использую Kotlin для автоматизации. Деятельность не связана напрямую с программированием, но Котлин здорово упрощает рабочие задачи.
Недавно нужно было собрать данные немаленького размера, дабы сделать анализ, поэтому решено было написать небольшой скрипт, который бы работал быстро и сохранял данные в Excel. С последним пунктом проблем не возникло - почитал про Apache POI, взял пару примеров из официальной документации, доработав под себя. Чего не скажешь про запросы в Сеть.
Источник отдавал пачками json и надо было как-то быстро эти "пачки" собирать, преобразовывая в текст и записывая в файл таблицу.
Когда мы начинаем изучать корутины, то «идём» и пробуем что-то простое с билдером runBlocking, поэтому многим он хорошо знаком. runBlocking запускает новую корутину, блокирует текущий поток и ждёт, пока выполнится блок кода — кажется, всё просто и понятно. Но что, если я скажу, что в runBlocking есть одна любопытная вещь, которая может заблокировать не только текущий поток, а вообще всё ваше приложение навсегда?
Привет! Хочу поделиться своими мыслями по, казалось бы, простой теме — типизации. В частности, поговорить о тайпчекинге в JavaScript.
Часто люди воспринимают типизацию как эдакую серебряную пулю, которая защищает от всех проблем. Но это не так, часто ожидания от типизации неоправданны, а простота таких инструментов, как TypeScript, обманчива и слишком переоценена.
Это не типичная статья из серии «Изучаем TypeScript», а, как мне кажется, фундаментальная история. Мы начнем с основ, поговорим о данных, о способе их хранения, а затем перейдем к типизации и посмотрим, как она влияет на работу программы.
На первый взгляд, такой вопрос как выбор свойства или метода кажется простым. Но это до тех пор, пока вы не столкнётесь с непониманием в своей команде. Хотя есть устоявшиеся практики, их формулировки достаточно расплывчаты. В такого рода вопросах есть некоторая степень свободы, которая затрудняет наш выбор, а кажущаяся простота даёт плодородную почву для споров.
В этой статье я подведу итоги 2020 года и расскажу о планах команды CUBA на 2021. Несмотря на внешние потрясения, прошедший год был очень продуктивным для нашей команды, а новый обещает быть еще интереснее.
TL;DR
Для тех, кто не знаком с Jmix: это новое поколение CUBA Platform, open source платформы для разработки широкого спектра корпоративных приложений. Jmix включает в себя фреймворк на основе Spring Boot, специализированные инструменты разработки, встроенные в IntelliJ IDEA и набор высокоуровневых компонентов. Такая комбинация значительно ускоряет и упрощает разработку приложений.
С выпуском Jmix в конце года мы фактически переписали бэкенд CUBA Platform, перенеся архитектуру на Spring Boot и сделав его модульным. На этом фундаменте в текущем году мы планируем:
- создать полнофункциональный UI клиент на React, с поддержкой визуальных конструкторов
- интегрировать GraphQL для взаимодействия между клиентом и сервером
- максимально упростить и автоматизировать DevOps
- поддержать возможность создания cloud native приложений
- предоставить больше визуальных инструментов разработчика в Studio, смещая фокус из runtime в design time.
Чтобы реализовать задуманное, мы хотим удвоить команду разработки и активно ищем единомышленников. Подробности - под катом.
