თქვენ მუშაობდით Kotlin Multiplatform-თან?

დიახ, მუშაობდა. შექმნილი იყო საერთო ლოგიკა iOS და Android-ისთვის Kotlin Multiplatform Mobile-ზე (ახლა Kotlin Multiplatform-ის ნაწილი).

გამოყენებული იყო Ktor ქსელური მოთხოვნებისთვის, SQLDelight მონაცემთა ბაზასთან მუშაობისთვის და Koin დამოკიდებულებების მართვისთვის.

განვითარებული იყო შემდეგი ფენები:

• Data Layer: ადგილობრივი მონაცემებისა და ქსელის მუშაობა.
• Domain Layer: ბიზნეს ლოგიკა.

UI ფენა რჩებოდა პლატფორმაზე დამოკიდებული.

მთავარი უპირატესობები, რომლებიც გამოვყავი:

• კოდის გადამეორება: ლოგიკის დუბლირების მნიშვნელოვანი შემცირება.
• ერთიანი ენა: Kotlin ორივე პლატფორმისთვის.
• ინტერპერაბილობა: ნატიური ურთიერთქმედება პლატფორმის კოდთან (Swift/Objective-C და Java/Kotlin).

ასევე გამოვყავი სირთულეები:

• ეკოსისტემის სიყალიბე: ზოგიერთი ბიბლიოთეკა შეიძლება იყოს ნაკლებად სიყალიბე, ვიდრე პლატფორმის სპეციფიკურ სტეკებში.
• დაფიქსირება: კროს-პლატფორმული კოდის დეფექტირება შეიძლება იყოს ნაკლებად მარტივი.
• CI/CD: CI/CD pipeline-ის კონფიგურაცია საჭიროებს ყურადღებას KMP-ის სპეციფიკას.

მოდელი მარტივი კლასის მაგალითით:

// commonMain
expect class Platform() {
    val name: String
}

// androidMain
actual class Platform actual constructor() {
    actual val name: String = "Android ${android.os.Build.VERSION.SDK_INT}"
}

// iosMain
actual class Platform actual constructor() {
    actual val name: String =
        UIDevice.currentDevice.systemName() + " " + UIDevice.currentDevice.systemVersion
}

// commonMain
class Greeting {
    private val platform: Platform = Platform()

    fun greet(): String {
        return "Hello, ${platform.name}!"
    }
}

ამ მაგალითში Platform არის მოსალოდნელი (expect) კლასი, რომლის რეალიზაცია ხდება თითოეულ პლატფორმაზე (actual). Greeting იყენებს ამ კლასს გამარჯობის ფორმირებისთვის.

KMP-ის გამოცდილება, მიუხედავად იმისა, რომ არ იყო მთავარი ფოკუსი, აჩვენა განვითარების და ლოგიკის ერთიანების პოტენციალი კროს-პლატფორმულ პროექტებში.