Kotlin Multiplatform Vocabulary: KMP, Compose, and Swift Interop (англійською)

Які слова вживати: лексичні приклади

Kotlin Multiplatform (KMP) швидко розвивається як спосіб спільного використання бізнес-логіки на Android, iOS і настільних платформах. Якщо ви стежите за розробкою KMP, відвідуєте бесіди JetBrains або читаєте офіційну документацію, ви знайдете певний набір термінів, які описують унікальну архітектуру програми. Знання цих мов англійською допоможе вам брати участь у міжнародній спільноті KMP і ефективно спілкуватися з колегами з проектів, що працюють на різних платформах.

Основні терміни архітектури KMP

Список джерел

** Набір джерел ** — це збірка файлів джерел Kotlin і пов’ язаних з ними ресурсів, які призначені для певної платформи або групи платформ. Набори джерел впорядковані у ієрархії.

• ** commonMain ** — набір початкових кодів, що містить код, спільний для всіх платформ. Тут ви можете написати бізнес- логіку, яка не залежить від платформи. « Всі моделі даних і інтерфейси сховищ знаходяться у commonMain. »
• ** androidMain ** — набір джерел, що містить специфічні для Android реалізації.
• ** iosMain ** — набір коду, що містить специфічні для iOS реалізації.
• ** nativeMain ** — покриває всі цілі Kotlin / Native, що включає iOS, macOS, Linux і Windows.

Прогноз/реальні декларації

Механізм expect/actual є однією з найбільш відмінних особливостей KMP. Це дозволяє вам оголосити функцію або клас в commonMain (використовуючи ключове слово expect) і забезпечити реалізацію, специфічну для платформи, в кожному наборі цільових кодів (використовуючи ключове слово actual).

Декларація expect в commonMain визначає контракт API; кожна платформа забезпечує свою реалізацію actual

Таким чином KMP обробляє відмінності платформ — такі як дата/час, доступ до файлової системи або криптографія — без забруднення спільного коду перевірками if (platform == iOS).

Kotlin/Native і Kotlin/JS

Kotlin/Native це ціль компілятора, який виробляє бінарні файли для платформ без JVM — в основному iOS, macOS, і вбудованих систем. Kotlin/JS компілює Kotlin на JavaScript, що дозволяє обмінюватися кодом з веб-цілями.

Композитний мультиплатформний

** Compose Multiplatform ** — це розширення JetBrains для Jetpack Compose, яке надає вам змогу писати код спільного інтерфейсу користувача, а також спільну логіку бізнесу. Вона призначена для Android, iOS, настільних комп’ютерів (JVM) і веб-сайтів.

• ** @Composable function** — функція, яка анонсована для участі у структурі інтерфейсу компонування, незалежно від цільової платформи.
• ** commonUI source set** — шаблон (не вбудована назва) для впорядкування спільного коду інтерфейсу компонування, який виконується на декількох пристроях.
• Material 3 for Compose Multiplatform — спільна реалізація бібліотеки компонентів Google Material Design, яка працює на різних платформах.

Градієнт KMP DSL

Проекти KMP налаштовуються за допомогою DSL Kotlin Gradle. Знання цих термінів є необхідним для читання і запису build.gradle.kts файлів.

** kotlin { } блок** — блок DSL верхнього рівня у скрипту KMP Gradle, де ви декларуєте набори цілей і джерел.

** Призначення** — конкретна платформа, для якої ви бажаєте зібрати програму, наприклад, androidTarget(), iosArm64() або jvm().

** sourceSets { } блок** — де ви визначаєте залежності для кожного набору кодів. « Додати залежність клієнта- ядра Ktor до commonMain і залежність рушія до кожного набору кодів платформи. »

Інтерактивний словник

Коли KMP використовується в iOS-додатку, код Kotlin виставляється на Swift через Objective-C framework (який Swift може споживати безпосередньо через взаємодію Obj-C).

** Заголовок платформи ** — сформований файл .h, який описує, які класи і функції Kotlin доступні з Swift.

** @ObjCName ** — анотація Kotlin, яка керує тим, як декларація Kotlin буде виглядати у створеному API Objective- C, що дозволяє вам надати їй більш ідіоматичну назву Swift.

** suspend function from Swift** — KMP виставляє функції припинення співпрограми Kotlin для Swift як функції, засновані на зворотному виклику або асинхронні функції, залежно від версії і налаштування Kotlin. “Виклик функції suspend зі Swift вимагає використання сформованого асинхронного обгортання або розширення kotlinx-coroutines-core Swift.”

** Інтеграція з CocoaPods ** — метод розповсюдження платформи KMP iOS за допомогою CocoaPods, стандартного менеджера залежностей iOS. « Ми публікуємо спільну платформу як специфікацію CocoaPods, щоб команда iOS могла використовувати її без збирання з початкового коду. »

П’ять прикладів речення

1. «Всі моделі мережі декларуються в commonMain, так що як Android, так і iOS цілі мають один і той же шар даних без дублювання»
2. «Клас expect в загальному коді декларує PlatformDateFormatter ; кожна ціль забезпечує свою реалізацію actual за допомогою API платформи рідної дати»
3. «Після міграції до Compose Multiplatform, ми зменшили нашу базу коду інтерфейсу приблизно на 60% завдяки спільному використанню складових рівня екрана між Android і настільним комп’ютером»
4. «Декларації цільових завдань Gradle KMP DSL визначають, які платформи компілюють під час CI, тому ми тільки створюємо бінарні файли iOS, коли вони працюють на macOS runner»
5. Команда iOS використовує фреймворк KMP через CocoaPods, що означає, що вони можуть оновити версію спільної логіки з однією командою pod update

Summary

Словниковий запас KMP щільний, але логічний. Ключова ментальна модель: * декларувати раз в commonMain, реалізувати на платформі за допомогою expect / actual *. Як тільки ви отримаєте цю модель, решта словника — набори джерел, цілі, спільне використання багатоплатформового інтерфейсу компонування, взаємодія з Swift — увійде на своє місце.

Розширення спектру: розширення спектру

Будьмо чесними – навігація технічних дискусій в професійному середовищі, особливо коли справа доходить до складних концепцій, таких як Kotlin Multiplatform, може відчуватися неймовірно пригнічуючим. Окрім розуміння самого коду, вам потрібно розуміти, * як* інші люди спілкуються про нього. Розглянемо такий сценарій: Сара, старший розробник команди, переглядає запит на витягування, надісланий Давидом, новим інженером, який занурюється у Compose Multiplatform. David’s PR вводить новий компонент екрана, використовуючи Jetpack Compose і використовує Swift interop для доступу до рідної функціональності iOS.

Сара читає повідомлення про перенесення Девіда — «Вреалізований екран входу з інтеграцією Swift» — і відразу бачить потенціал для неоднозначності. Хоча він короткий, він не передає нюанси роботи. Вона може відповісти щось на зразок: “Дейвід, дякую за це! Щоб допомогти мені повністю зрозуміти обсяг, чи можете ви розібратися в « інтеграції Swift »? Зокрема, чи можете ви описати, як декларації expect використовуються для керування потоком даних між Kotlin і Swift? Також, я б був вдячний за дещо більше контексту навколо налаштування набору джерел — чи це повністю нове налаштування, чи це розширення існуючого налаштування KMP?» Це не про вказівку на помилки; це про пояснення очікувань і переконання, що всі на одній сторінці щодо архітектури. Використання таких термінів, як «сподіваюся декларації» і «конфігурація набору джерел» є критичним для обговорення цього конкретного аспекту KMP, підкреслюючи важливість точної термінології, коли йдеться про крос-платформенну розробку. Це також хороший спосіб нагадувати про необхідність чітко документувати рішення — щось, що може запобігти майбутнім непорозумінням і спрощувати співпрацю.

Крім того, розуміння різниці між “expect” і “fact” деклараціями є ключовим тут. “Expect” декларації визначають, що Kotlin * очікує * отримати від Swift, в той час як “fact” декларації визначають, що насправді відсилається назад. Це розрізнення стає ще більш важливим, коли справа доходить до інтероп сценаріїв, де типи даних можуть трохи відрізнятися між платформами. Неправильне розуміння цього може призвести до несподіваних проблем під час виконання або ввести незначні вади, які важко виявити.

Нарешті, розмова часто виходить за межі окремих PR-оглядів. Slack канали, присвячені розробці KMP часто включають обговорення про найкращі практики і архітектурні вибори - такі терміни, як “набір джерел” стають поширеними при обговоренні організації коду і управління залежностями. Це постійний процес навчання, не тільки самої Kotlin, але і мови, що використовується для обговорення її в рамках більш широкого інженерного співтовариства.

// Example: Expect declaration in Kotlin
expect class MySwiftObject {
    var name: String
}

// Corresponding Swift implementation (simplified)
class MySwiftObject {
    var name: String = ""
}