Як перевести Android-застосунок з Java на Kotlin

Kotlin і Java спокійно живуть в одному проєкті — і це найкорисніший факт про цю міграцію: її не обов'язково робити одразу і не обов'язково скрізь. Застосунок можна випускати після кожного кроку, саме це й робить роботу безпечною.

Спершу підготуйте ґрунт. Свіжий Android Gradle Plugin, підключений плагін Kotlin у файлах збірки і зелена збірка на тій машині, що збирає релізи, а не лише на ноутбуці. Якщо тестів у проєкті немає зовсім, напишіть кілька навколо того, що відповідає за гроші чи дані, ще до того, як торкатися коду: на них ви спиратиметеся всю міграцію.

Далі переводьте в порядку, що тримає ризик низьким:
— почніть з класів даних і дрібних утиліт, де перетворення механічне, а різницю легко читати;
— потім репозиторії та мережевий шар;
— потім view-моделі та презентери;
— екрани і все, що зав'язане на життєвий цикл фреймворка, лишіть наостанок.

«Convert Java File to Kotlin File» в Android Studio робить механічну частину, але його результат ніколи не можна вважати остаточним. Він позначає всі типи, що приходять із Java, як платформні — і тим самим тихо вимикає ту саму null-безпеку, заради якої все затівалося. Пройдіться конвертованим файлом і вирішіть для кожного поля, що справді може бути null, — і запишіть це в тип. Саме в цьому проході й полягає більша частина користі від міграції.

Кілька речей конвертер робить синтаксично правильно, а по суті — ні: `lateinit` там, де краще був би параметр конструктора; nullable-типи «про всяк випадок»; `!!` там, де належить перевірка; companion object замість того, що було статичними хелперами, а тепер могло б стати функціями верхнього рівня.

Коли шар уже на Kotlin, користуйтеся тим, що дає мова, а не пишіть Java синтаксисом Kotlin: корутини замість ланцюжків колбеків і `AsyncTask`, класи даних замість написаних руками `equals`, sealed-класи для станів екрана, функції-розширення замість смітника зі статичних методів у `Utils`.

До кінця тримайтеся двох правил. Кожен коміт лишає застосунок таким, що збирається і випускається, — жодних наполовину переведених гілок, які живуть тижнями. І змішаний проєкт — цілком нормальний кінцевий стан: якщо модуль на Java стабільний, зрозумілий і його рідко чіпають, переведення не дасть нічого, крім ризику. Сенс міграції — безпечніший код там, де його змінюють, а не зелений значок Kotlin у репозиторії.