Мы рады представить вам Kotlin 1.1, новую версию языка программирования Kotlin.
Наша цель — сделать выразительный статически типизированный язык, на котором можно эффективно писать все компоненты современного приложения. Сегодняшний релиз делает два важных шага в этом направлении.
DSL (Domain-specific language) — язык, специализированный для конкретной области применения (Википедия)
На написание этого поста меня натолкнула статья "Почему Kotlin отстой", в которой автор сетует на то, что в Kotlin "нет синтаксиса для описания структур". За некоторое время программирования на Kotlin у меня сложилось впечатление, что в нём если нельзя, но очень хочется, то можно. И я решил попробовать написать свой DSL для описания структуры данных. Вот что из этого получилось.
Эта статья родилась по мотивам вот этой статьи в виде полу-шутки. В той статье большая часть "проблем" является либо синтетическими и крайне редко используемыми, либо притянутыми за уши из-за ожидания соответствия языка теоретической парадигме которой, по мнению автора, язык должен соответствовать. С другой стороны не упомянуты вещи, которые мне лично действительно усложняют жизнь.
Предупреждения и ошибки, которые генерирует компилятор Kotlin часто нужно замаскировать, либо для того, чтобы они не мозолили глаза, либо просто потому, что логика программы нуждается именно в таком коде, который приводит к сообщению об ошибке или предупреждению.
Статья основана на версии Kotlin «1.1-М04».
Эта статья посвящена описанию механизма генерации автоматических классов компилятором Kotlin для анонимного блока пользовательского кода. Описано в каких случаях создаются автоматические классы, где они располагаются, как реализованы и используются.
В Java существует только один способ создания элемента кода – это лямбда-выражение, которое может реализовывать только функциональный интерфейс (подробнее см. в документации на Java). В Kotlin существует несколько различных способов описать объект, содержащий пользовательский код.
Всем хорошо известна особенность Kotlin очень легко реализовывать код, позволяющий писать такие конструкции:
fun Action( cb:()->Unit ) { cb() }
fun Test() {
Action{
// Этот блок кода будет выполнен в функции
}
}Как это реализовано и чем чревато использование такого кода в программе?
ПС: Первоначальный вариант статьи содержал логическую ошибку и неправильные выводы. Приношу всем свои извинения за этот факт. Эта статья переработана и дополнена дополнительными данными.
Сериализация (Serialize, в последующем «сохранение») – это процесс сохранения данных объекта во внешнем хранилище.
Эта операция работает в паре с обратной – восстановлением данных, называемой десереализацией (Deserealize, в последующем «восстановление»).
Операции сохранения и восстановления данных применяются очень часто. В классических языках программирования готовых механизмов для сохранения и восстановления данных объектов нет и, при возникновении такой необходимости, приходится создавать их самостоятельно.
В Java такие готовые механизмы существуют и, даже, в количестве более одного. Давайте разберемся, какие механизмы есть и какие возможности они предоставляют для программ на Kotlin.
Само понятие сериализации никак не привязано к формату данных, в который будут сохранены данные, поэтому вне зависимости от того, какой результат будет получен – бинарный файл с собственной структурой, формат XML, JSON или даже текстовый файл – все это будет сериализацией.
Контекстные действия с элементами списка широко используются с Android-приложениях. Довольно удобно выделить несколько элементов или все элементы списка и применить какое-то действие ко всем выбранным элементам сразу. Удалить, например.
В Android-приложениях для этого может использоваться ActionMode, который позволяет отобразить доступные действия над выделенными элементами поверх Toolbar. Там же можно показывать пользователю сколько элементов выделено в текущий момент или другую полезную информацию. Это удобно и хорошо смотрится, но в некоторых случаях информация, отображаемая на самом Toolbar, может быть важна и скрывать ее не хотелось бы. К примеру, там может быть имя и фото пользователя, список сообщений с которым отображается в списке. При выделении некоторых сообщений полезно было бы видеть имя пользователя, которому эти сообщения адресованы.
В этом случае можно отображать панель контекстных действий с элементами списка поверх самого списка, не загораживая Toolbar. О создании такой панели контекстных действий я и расскажу в этой статье.
Разрабатываемый CustomView — панель контекстных действий я назвал FloatingActionMode или просто FAM.
FloatingActionMode во время работы (Зафиксирован снизу)
В предыдущей статье я сделал беглый обзор async-await в Android. Теперь пришло время погрузиться немного глубже в грядущий функционал kotlin версии 1.1.
Когда мы сталкиваемся с длительными операциями, такими как сетевые запросы или транзакции в базу данных, то надо быть уверенным, что запуск происходит в фоновом потоке. Если же забыть об этом, то можно получить блокировку UI потока еще до того, как задача закончится. А во время блокировки UI пользователь не сможет взаимодействовать с приложением.
Это мой первый перевод, поэтому прошу прощения за неточности. Если вы найдете ошибки в переводе, пожалуйста, сообщите об этом. Я не нашел лучшего перевода слова сoroutine, чем сопрограмма, поэтому решил использовать оригинал. Если у вас появятся идеи по этому поводу, буду рад узнать.
Kotlin версии 1.1 принесет в язык coroutin'ы, которые позволяют приостанавливать вычисления в какой-то точке, а затем продолжить их позднее. Очевидный пример этой возможности — async-await, который был добавлен в C# несколько лет назад.
Каждый android разработчик знает, что когда мы имеем дело с сетевыми запросами или другими I/O задачами, то нам необходимо удостовериться, что не происходит блокировка основного потока, а так же, что мы не трогаем UI из фонового потока. На протяжении многих лет приходят и уходят десятки приемов. В этой статье перечислены наиболее популярные, и показаны примеры удобства, которое несет с собой async-await.
Всем привет!
Эта статья про реализацию одного конкретного DSL (domain specific language, предметно-ориентированный язык) для регулярных выражений средствами Kotlin, но при этом она вполне может дать общее представление, о том, как написать свой DSL на Kotlin и что обычно будет делать "под капотом" любой другой DSL, использующий те же возможности языка.
Многие уже используют Kotlin или хотя бы пробовали это делать, да и остальные вполне могли слышать о том, что Kotlin располагает к написанию изящных DSL, чему есть блестящие примеры — Anko и kotlinx.html.
Конечно же, для регулярных выражений подобное уже делали (и ещё: на Java, на Scala, на C# — реализаций много, похоже, это распространённое развлечение). Но если хочется попрактиковаться или попробовать DSL-ориентированные языковые возможности Kotlin, то добро пожаловать под кат.
variable("hello") + variable("habr") * 2016 where ("hello" to 1) and ("habr" to 2)
name?.length
Наша команда, аналогично с автором статьи, уже почти как год перешла со Scala на Kotlin в качестве основного языка. Мое мнение во многом совпадает с автором, поэтому предлагаю вам перевод его интересной статьи.
Прошло прилично времени с того момента как я не обновлял блог. Вот уже как год я перешел со Scala, моего основного языка, на Kotlin. Язык позаимствовал много хороших вещей, которые мне нравились в Scala, сумев при этом избежать многих подводных камней и неоднозначности, которая есть в Scala.
Ниже я хочу привести примеры, которые мне нравятся в Scala и Kotlin, а также их сравнение в том, как они реализованы в обоих языках.
public interface List<E> extends Collection<E> {
//...
}List<String> list = new ArrayList<>();