1 kotlin 2 android 3 scala тинькофф

Почему следует полностью переходить на Kotlin

Хочу рассказать вам о новом языке программирования, который называется Kotlin, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я предпочитал Java, но в последний год пишу на Kotlin везде, где только можно. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java.

Kotlin разработан в JetBrains, и участие тех же людей в создании наборов IDE, таких как IntelliJ и ReSharper, хорошо заметно по самому языку. Он прагматичен и краток, благодаря чему написание кода превращается в приятный и эффективный процесс.

Хотя Kotlin компилируется в JavaScript и скоро будет компилироваться в машинный код, я сконцентрируюсь на его первичной среде — JVM.

Итак, несколько причин, почему вам следует полностью переходить на Kotlin (порядок случаен):

0# Совместимость с Java

Kotlin на 100 % совместим с Java. Вы можете в буквальном смысле продолжать работать над своим старым Java-проектом, но уже используя Kotlin. Все ваши любимые Java-фреймворки также будут доступны, и, в каком бы фреймворке вы ни писали, Kotlin будет легко принят упрямым любителем Java.

1# Знакомый синтаксис

Kotlin — не какой-то там странный язык, рождённый в академических кругах. Его синтаксис знаком любому программисту, воспитанному на парадигме ООП, и с самого начала может быть более-менее понятным. Конечно, есть некоторые отличия от Java вроде переработанного конструктора или объявлений переменных val var . В этом коде отражена большая часть базового синтаксиса:

2# Интерполяция строк

Это как бы более умная и читабельная версия String.format() из Java, встроенная в язык:

3# Выведение типа

Kotlin будет выводить ваши типы, если вы посчитаете, что это улучшит читабельность:

4# Умные приведения типов (Smart Casts)

Компилятор Kotlin отслеживает вашу логику и по мере возможности автоматически выполняет приведение типов, т. е. вам больше не нужны проверки instanceof после явных приведений:

5# Интуитивные равенства (Intuitive Equals)

Можно больше не вызывать явно equals() , потому что оператор == теперь проверяет структурное равенство:

6# Аргументы по умолчанию

Больше не нужно определять несколько одинаковых методов с разными аргументами:

7# Именованные аргументы

В сочетании с аргументами по умолчанию именованные аргументы избавляют от необходимости использовать Строителей:

8# Выражение When

Оператор ветвления заменён гораздо более читабельным и гибким в применении выражением when:

Оно работает и как выражение (expression), и как описание (statement), с аргументом или без него:

9# Свойства

Можно добавить публичным полям кастомное поведение set & get, т. е. перестать набивать код безумными геттерами и сеттерами.

10# Data Class

Он наполнен POJO-объектами toString() , equals() , hashCode() и copy() , но, в отличие от Java, не занимает 100 строк кода:

11# Перегрузка оператора (Operator Overloading)

Заранее определённый набор операторов, которые можно перегружать для улучшения читабельности:

12# Деструктурирующие объявления (Destructuring Declarations)

Некоторые объекты могут быть деструктурированы, что бывает полезно, к примеру, для итерирования map:

13# Диапазоны (Ranges)

Для улучшения читабельности:

14# Функции-расширения (Extension Functions)

Помните свой первый раз, когда пришлось сортировать List в Java? Вам не удалось найти функцию sort() , и пришлось изучать Collections.sort() . Позднее, когда нужно было в строковом значении заменить все буквы строчными, вам пришлось писать собственную вспомогательную функцию, потому что вы не знали о StringUtils.capitalize() .

Если бы существовал способ добавления новых функций в старые классы, тогда ваш IDE помог бы найти правильную функцию при завершении кода. Именно это можно делать в Kotlin:

Стандартная библиотека расширяет функциональность оригинальных Java-типов, что особенно полезно для String :

15# Безопасность Null

Java следует называть почти статично типизированным языком. Внутри него переменная типа String не гарантированно ссылается на String — она может ссылаться на null . И хотя мы к этому привыкли, это снижает безопасность проверки на статичное типизирование, и в результате Java-разработчики вынуждены жить в постоянном страхе перед NPE.

В Kotlin эта проблема решена посредством разделения на типы, допускающие и не допускающие значение null. По умолчанию типы не допускают null, но их можно преобразовать в допускающие, если добавить ? :

Kotlin заставляет вас бороться с NPE, когда вы обращаетесь к типу, допускающему null:

Возможно, выглядит громоздко, но благодаря нескольким своим возможностям действительно полезно. У нас всё ещё есть умные приведения типов, когда типы, допускающие null, преобразуются в не допускающие:

Также можно использовать безопасный вызов ?. , он возвращает значение null вместо бросания NPE:

Можно объединять безопасные вызовы в цепочки, чтобы избегать вложенных проверок если-не-null, которые иногда мы пишем в других языках. А если нам по умолчанию нужно не null-значение, то воспользуемся elvis-оператором ?: :

Если всё это вам не подходит и вам совершенно точно нужны NPE, то скажите об этом явно:

16# Улучшенные лямбды

Это хорошая система лямбд — идеальный баланс между читабельностью и лаконичностью благодаря нескольким толковым решениям. Синтаксис прост:

А вот и толковые решения:

1. Можно переместить или опустить круглые скобки в методе, если лямбда идёт последней либо является единственным аргументом метода.
2. Если вы решили не объявлять аргумент одноаргументной лямбды, то он будет неявно объявлен под именем it .

Комбинация этих факторов делает эквивалентными эти три строки:

Это позволяет нам писать лаконичный функциональный код, вы только посмотрите на эту красоту:

Система лямбд, объединённая с функциями-расширениями, делает Kotlin идеальным инструментом для создания DSL. Anko — пример DSL, предназначенного для расширения возможностей Android-разработки:

17# Поддержка IDE

У вас есть целый ряд вариантов, как можно начать работать с Kotlin, но я крайне рекомендую использовать IntelliJ, идущий в комплекте поставки Kotlin — его возможности демонстрируют преимущество ситуации, когда одни и те же люди разрабатывают как язык, так и IDE.
Небольшой пример: это сообщение всплыло, когда я впервые попытался скопипастить Java-код со Stack Overflow:

IntelliJ заметит, что вы вставляете Java-код в файл Kotlin

На этом всё, спасибо за чтение! Если мне пока не удалось убедить вас насчёт Kotlin, то рекомендую почитать дополнительные материалы:

Источник

1 kotlin 2 android 3 scala тинькофф

Kotlin язык разработки под Android

Обсуждения языка Kotlin и обмена полезными ссылками.
Так же можно задавать любые вопросы по языку.

P.S. @Zyomich дал согласие на создание темы

Сообщение отредактировал derak1129 — 28.12.19, 05:18

Заранее сорян, если кого обижу постом.

Вот и зря, что разрешил.

Был как-то в этом году яндексе на конфе.
Никто из тех(в основном это были программеры из яндекса из питерского офиса), кто пропагандировал начать использование этого недоразумения,
внятно не смог объяснить, задающим этот вопрос из зала, в чем же его преимущества перед java и зачем же его начинать использование.

Конвертации проектов Kotlin -> Java нет(на тот момент), только из Java -> Kotlin.
По ощущениям, язык просто надстройка над java, которую решили написать, т.к. в java создатели Kotlin внезапно нашли «фатальный недостаток».

Может топикстартер доступно объяснит, в чем же преимущества перехода с java на Kotlin?

как всегда — синтетический сахар в основном, меньше писать кода, больше возможностей выразить мысль в код. Многие возможности языка я бы безусловно хотел использовать и использовались бы они не из принципа, там такое есть, значит надо, а реально так удобнее, лаконичнее ..

Вообще, ваши инсинуации несколько странны, не думаю, что в самом деле прям так никто не мог сказать , зачем этот язык.

К слову, насчет недоразумения вы тоже как то погорячились, язык изначально разрабатывался для внутренних нужд Jet Brains (на нем написаны все их продукты, включая IDEA) — я вот прямо сейчас так и представляю себе — сидят на брифинге и такие: слишком просто код писать стало, нужно придумать какое-то недоразумение и писать на нем, да еще так придумать , чтоб никто объяснить не мог, зачем это надо, но пользовались все больше и больше. :rofl:

Я вообще пробовал на нем писать, очень даже быстро привыкаешь к «маленьким радостям».. в итоге оставил только из за null safety — весь код усеян этими вопросами, меня это почему то раздражает. В целом впечатление довольно положительное.

Насчет надстройки, тогда все JVM-based языки в той или иной степени надстройки друг над другом ..

Немного добавлю ресурсов:

Antonio Leiva активно продвигает этот язык, даже книгу написал.
Раздел Kotlin на Java Help
Раздел Kotlin и раздел Android Kotlin на Devcolibri

Сообщение отредактировал pavlofff — 02.11.16, 07:18

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

А вот что пишут в самом Jet Brains в описании вакансии программиста для разработки IntelliJ IDEA.

Хм, это что-то уровня «конвертер Scala/Groovy/Clojure -> Java» — это просто не имеет смысла.
Идиоматичный (а НЕ java style) код на «совместимых» языка часто содержит непереводимые конструкции.

Не хочется скатываться в холивар, ведь уже много раз это объясняли.
Вот Илья из JB рассказывает: https://www.youtube.com/watch?v=DQqOCx2UJ10 и https://www.youtube.com/watch?v=FftQuCe626A
или Jake Wharton (тоже большой фанат Kotlin): https://www.youtube.com/watch?v=A2LukgT2mKc

Лично для меня это null safety + DSL + async/await + extension function (тот же Stream-like апи в Kotlin)

Источник

Современная Android разработка на Kotlin. Часть 1

Данная статья является перевом статьи от Mladen Rakonjac

Очень сложно найти один проект, который охватывал бы всё новое в разработке под Android в Android Studio 3.0, поэтому я решил написать его. В этой статье мы разберём следующее:

1. Android Studio 3
2. Язык программирования Kotlin
3. Варианты сборки
4. ConstraintLayout
5. Библиотека привязки данных Data Binding
6. Архитектура MVVM + паттерн repository (с mapper’ами) + Android Manager Wrappers
7. RxJava2 и как это помогает нам в архитектуре
8. Dagger 2.11, что такое внедрение зависимости, почему вы должны использовать это.
9. Retrofit (Rx Java2)
10. Room (Rx Java2)

Каким будет наше приложение?

Наше приложение будет самым простым, которое охватывает все перечисленные выше вещи: у него будет только одна функция, которая извлекает все репозитории пользователя googlesamples из GitHub, сохраняет эти данные в локальной базе данных и показывает их пользователю.

Я попытаюсь объяснить как можно больше строк кода. Вы всегда можете посмотреть код, который я опубликовал на GitHub.

Android Studio

Чтобы установить Android Studio 3, перейдите на эту страницу

Android Studio 3 поддерживает Kotlin. Откройте Create Android Project. Там вы увидите новый флажок с меткой Include Kotlin support. Он выбран по умолчанию. Дважды нажмите кнопку Далее и выберите Empty Activity, затем нажмите Finish.

Поздравляю! Вы сделали первое приложение для Android на Котлине 🙂

Kotlin

Вы можете видеть MainActivity.kt:

Расширение .kt означает, что файл является файлом Kotlin.

MainActivity: AppCompatActivity() означает, что мы расширяем AppCompatActivity.

Кроме того, все методы должны иметь ключевое слово fun и в Котлине вам не нужно использовать ;, но вы можете, если хотите. Вы должны использовать ключевое слово override, а не аннотацию, как в Java.

Так что же означает ? в savedInstanceState: Bundle?? Это означает, что savedInstanceState может быть типа Bundle или типа null. Kotlin null безопасный язык. Если у вас есть:

вы получите ошибку компиляции, потому что a должна быть инициализированна и это не может быть null. Это означает, что вы должны написать:

Кроме того, вы получите ошибку компиляции, если вы это сделаете:

Чтобы сделать a nullable, вы должны написать:

Почему эта важная особенность языка Котлина? Это помогает нам избежать NPE. Разработчики Android уже устали от NPE. Даже создатель null, сэр Тони Хоар, извинился за изобретение. Предположим, что мы имеем nullable nameTextView. Если переменная равна null, то в следующем коде мы получим NPE:

Но Котлин, на самом деле, хорош, он не позволят нам делать даже такое. Он заставляет нас использовать оператор ? или оператор !!. Если мы используем оператор ?:

Строка будет исполнена только если nameTextView не null. В ином случае, если вы используете оператор !!:

Мы получим NPE если nameTextView null. Это для авантюристов :).
Это было небольшое введение в Kotlin. Когда мы продолжим, я остановлюсь, чтобы описать другой специфический код на Котлине.

2. Build Variants

В разработке часто вы имеете различные окружения. Наиболее стандартным является тестовое и производственное окружение. Эти среды могут отличаться в URL-адресах сервера, иконке, имени, целевом API и т.д. На fleka в каждом проекте у вас есть:

• finalProduction, который отправляется в Google Play Store.
• demoProduction, то есть версия с URL-адресом production сервера с новыми функциями, которые всё ещё не находятся в Google Play Store. Наши клиенты могут установить эту версию рядом с Google Play, чтобы они могли протестировать ее и дать нам обратную связь.
• demoTesting, то же самое, что и demoProduction с тестовым URL-адресом сервера.
• mock, полезен для меня как для разработчика и дизайнера. Иногда у нас есть готовый дизайн, и наш API ещё не готов. Ожидание API, чтобы быть начать разработку — не решение. Этот вариант сборки снабжён поддельными данными, поэтому команда дизайнеров может проверить его и дать нам обратную связь. Очень полезно это не откладывать. Когда API уже готов, мы перемещаем нашу разработку в окружение demoTesting.

В этом приложении мы будем использовать всех их. У них будут отличаться applicationId и имена. В gradle 3.0.0 есть новый API flavorDimension, который позволяет смешивать разновидности продукта, так, например, вы можете смешать разновидности demo и minApi23. В нашем приложении мы будем использовать только «default» flavorDimension. Перейдите в build.gradle для приложения и вставьте этот код внутри android <>

Перейдите в strings.xml и удалите строку app_name, чтобы у нас не было конфликтов. Затем нажмите Sync Now. Если вы перейдете в Build Variants, расположенным слева от экрана, вы увидите 4 варианта сборки, каждый из которых имеет два типа сборки: Debug и Release. Перейдите к варианту сборки demoProduction и запустите его. Затем переключитесь на другой и запустите его. Вы должны увидеть два приложения с разными именами.

3. ConstraintLayout

Если вы откроете activity_main.xml, вы увидите, что этот layout — ConstrainLayout. Если вы когда-либо писали приложение под iOS, вы знаете об AutoLayout. ConstraintLayout действительно похож на него. Они даже используют один и тот же алгоритм Cassowary.

Constraint помогает нам описать связи между View. Для каждого View у вас должно быть 4 Constraint, один для каждой стороны. В данном случае наш View ограничен родителем с каждой стороны.

Если вы передвинете TextView «Hello World» немного вверх во вкладке Design, во вкладке Text появится новая линия:

Вкладки Design и Text синхронизируются. Наши изменения во вкладке Design влияют на xml во вкладке Text и наоборот. Vertical_bias описывает вертикальную тенденцию view его Constraint. Если вы хотите центровать вертикально, используйте:

Давайте сделаем чтобы наш Activity показал только один репозиторий. В нём будут имя репозитория, количество звезд, владелец, и он будет показывать, есть ли у репозитория issues, или нет.

Чтобы получить такой layout, xml должен выглядеть так:

Пусть tools:text вас не смущает. Он просто помогает нам видеть хороший предварительный просмотр макета (layout’а).

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

и мне кажется, что я могу добиться желаемого результата очень быстро.
Это было небольшое введение в ConstraintLayout. Вы можете найти Google code lab здесь, и документацию о ConstraintLayout на GitHub.

4. Библиотека привязки данных Data Binding

Когда я услышал о библиотеке привязки данных, первое вопрос, который я задал себе: «ButterKnife работает очень хорошо для меня. Кроме того, я использую плагин, который помогает мне получать View из xml. Зачем мне это менять?». Как только я узнал больше о привязке данных, у меня было такое же чувство, какое у меня было, когда я впервые использовал ButterKnife.

Как ButterKnife помогает нам?

ButterKnife помогает нам избавиться от скучного findViewById. Итак, если у вас 5 View, без Butterknife у вас есть 5 + 5 строк, чтобы привязать ваши View. С ButterKnife у вас есть 5 строк. Вот и всё.

Что плохо в ButterKnife?

ButterKnife по-прежнему не решает проблему поддержки кода. Когда я использовал ButterKnife, я часто получал исключение во время выполнения, потому что я удалял View в xml, и не удалял код привязки в классе Activity / Fragment. Кроме того, если вы хотите добавить View в xml, вам нужно снова сделать привязку. Это очень скучно. Вы теряете время на поддерживание связей.

Что насчёт библиотеки привязки данных?

Есть много преимуществ! С помощью библиотеки привязки данных вы можете привязать свои View всего одной строкой кода! Позвольте мне показать вам, как это работает. Давайте добавим библиотеку Data Binding в наш проект:

Обратите внимание, что версия компилятора Data Binding должна совпадать с версией gradle в файле build.gradle проекта:

Нажмите Sync Now. Перейдите в activity_main.xml и оберните ConstraintLayout тегом layout:

Обратите внимание, что вам нужно переместить все xmlns в тег layout. Затем нажмите иконку Build или используйте сочетание клавиш Ctrl + F9 (Cmd + F9 на Mac). Нам нужно собрать проект, чтобы библиотека Data Binding могла сгенерировать класс ActivityMainBinding, который мы будем использовать в нашем классе MainActivity.

Если вы не выполните сборку проекта, вы не увидите класс ActivityMainBinding, потому что он генерируется во время компиляции. Мы все еще не закончили связывание, мы просто сказали, что у нас есть ненулевая переменная типа ActivityMainBinding. Кроме того, как вы можете заметить, я не указал ? в конце типа ActivityMainBinding, и я не инициализировал его. Как это возможно? Модификатор lateinit позволяет нам иметь ненулевые переменные, ожидающие инициализации. Подобно ButterKnife, инициализация привязки должна выполняться в методе onCreate, когда ваш Activity будет готов. Кроме того, вы не должны объявлять привязку в методе onCreate, потому что вы, вероятно, используете его вне области видимости метода onCreate. Наша привязка не должна быть нулевой, поэтому мы используем lateinit. Используя модификатор lateinit, нам не нужно проверять привязку переменной каждый раз, когда мы обращаемся к ней.

Давайте инициализируем нашу переменную binding. Вы должны заменить:

Вот и всё! Вы успешно привязали свои View. Теперь вы можете получить к ним доступ и применить изменения. Например, давайте изменим имя репозитория на «Modern Android Habrahabr Article»:

Как вы можете видеть, мы можем получить доступ ко всем View (у которых есть id, конечно) из activity_main.xml через переменную binding. Вот почему Data Binding лучше, чем ButterKnife.

Getter’ы и Setter’ы в Котлине

Возможно, вы уже заметили, что у нас нет метода .setText (), как в Java. Я хотел бы остановиться здесь, чтобы объяснить, как геттеры и сеттеры работают в Kotlin по сравнению с Java.

Во-первых, вы должны знать, почему мы используем сеттеры и геттеры. Мы используем их, чтобы скрыть переменные класса и разрешить доступ только с помощью методов, чтобы мы могли скрыть элементы класса от клиентов класса и запретить тем же клиентам напрямую изменять наш класс. Предположим, что у нас есть класс Square в Java:

Используя метод setA (), мы запрещаем клиентам класса устанавливать отрицательное значение стороне квадрата, оно не должно быть отрицательным. Используя этот подход, мы должны сделать a приватным, поэтому его нельзя установить напрямую. Это также означает, что клиент нашего класса не может получить a напрямую, поэтому мы должны предоставить getter. Этот getter возвращает a. Если у вас есть 10 переменных с аналогичными требованиями, вам необходимо предоставить 10 геттеров. Написание таких строк — это скучная вещь, в которой мы обычно не используем наш разум.

Kotlin облегчает жизнь нашего разработчика. Если вы вызываете

это не означает, что вы получаете доступ к a непосредственно. Это то же самое, что

в Java. Причина заключается в том, что Kotlin автоматически генерирует геттеры и сеттеры по умолчанию. В Котлине, вы должны указать специальный сеттер или геттер, только если он у вас есть. В противном случае, Kotlin автогенерирует его для вас:

field? Что это? Чтобы было ясно, давайте посмотрим на этот код:

Это означает, что вы вызываете метод set внутри метода set, потому что нет прямого доступа к свойству в мире Kotlin. Это создаст бесконечную рекурсию. Когда вы вызываете a = что-то, он автоматически вызывает метод set.
Надеюсь, теперь понятно, почему вы должны использовать ключевое слово field и как работают сеттеры и геттеры.

Вернемся к нашему коду. Я хотел бы показать вам ещё одну замечательную особенность языка Kotlin, apply:

apply позволяет вам вызывать несколько методов на одном экземпляре.

Мы все еще не закончили привязку данных, есть ещё много дел. Давайте создадим класс модели пользовательского интерфейса для репозитория (этот класс модели пользовательского интерфейса для репозитория GitHub хранит данные, которые должны отображаться, не путайте их с паттерном Repository). Чтобы сделать класс Kotlin, вы должны перейти в New -> Kotlin File / Class:

В Kotlin первичный конструктор является частью заголовка класса. Если вы не хотите предоставлять второй конструктор, это всё! Ваша работа по созданию класса завершена здесь. Нет параметров конструктора для назначений полей, нет геттеров и сеттеров. Целый класс в одной строке!

Вернитесь в класс MainActivity.kt и создайте экземпляр класса Repository:

Как вы можете заметить, для построения объекта не нужно ключевого слова new.

Теперь перейдем к activity_main.xml и добавим тег data:

Мы можем получить доступ к переменной repository, которая является типом Repository в нашем макете. Например, мы можем сделать следующее в TextView с идентификатором repository_name:

В TextView repository_name будет отображаться текст, полученный из свойства repositoryName переменной repository. Остается только связать переменную репозитория от xml до repository из MainActivity.kt.
Нажмите Build, чтобы сгенерировать библиотеку привязки данных для создания необходимых классов, вернитесь в MainActivity и добавить две строки:

Если вы запустите приложение, вы увидите, что в TextView появится «Habrahabr Android Repository Article». Хорошая функция, да? 🙂

Но что произойдёт, если мы сделаем следующее:

Отобразится ли новый текст через 2 секунды? Нет, не отобразится. Вы должны заново установить значение repository. Что-то вроде этого будет работать:

Но это скучно, если нужно будет делать это каждый раз, когда мы меняем какое-то свойство. Существует лучшее решение, называемое Property Observer.
Давайте сначала опишем, что такое паттерн Observer, нам понадобится это в разделе rxJava:

Возможно, вы уже слышали об androidweekly.net. Это еженедельный информационный бюллетень об Android разработке. Если вы хотите его получить, вам необходимо подписаться на него, указав свой адрес электронной почты. Позже, если вы захотите, вы можете остановить отказаться от подписки на своем сайте.

Это один из примеров паттерна Observer / Observable. В данном случае, Android Weekly — наблюдаемый (Observable), он выпускает информационные бюллетени каждую неделю. Читатели — это наблюдатели (Observers), они подписываются на него, ждут новых выпусков, и, как только они получают её, они читают её, и если некоторые из них решат, что им это не нравится, он / она может прекратить следить.

Property Observer, в нашем случае, представляет собой XML-макет, который будет прослушивать изменения в экземпляре Repository. Таким образом, Repository является наблюдаемым. Например, как только свойство name класса Repository изменяется в экземпляре класса, xml должен обновится без вызова:

Как сделать это с помощью библиотеки привязки данных? Библиотека привязки данных предоставляет нам класс BaseObservable, который должен быть реализован в классе Repository:

BR — это класс, который автоматически генерируется один раз, когда используется аннотация Bindable. Как вы можете видеть, как только новое значение установлено, мы узнаём об этом. Теперь вы можете запустить приложение, и вы увидите, что имя репозитория будет изменено через 2 секунды без повторного вызова функции executePendingBindings ().

Для этой части это всё. В следующей части я напишу о паттерне MVVM, паттерне Repository и об Android Wrapper Managers. Вы можете найти весь код здесь. Эта статья охватывает код до этого коммита.

Источник