نقل إعدادات تصميمك من Groovy إلى Kotlin

تسمح لك Groovy بحذف الأقواس في استدعاءات الطرق، بينما تتطلبها Kotlin. لنقل إعداداتك، أضِف أقواسًا إلى هذه الأنواع من استدعاءات الطرق. يوضّح هذا الرمز البرمجي كيفية ضبط إعداد في Groovy:

compileSdkVersion 30

هذا هو الرمز البرمجي نفسه مكتوبًا بلغة Kotlin:

compileSdkVersion(30)

إضافة = إلى استدعاءات التعيين

يسمح لك Groovy DSL بحذف عامل التعيين = عند تعيين الخصائص، بينما تتطلبه Kotlin. يوضّح هذا الرمز البرمجي كيفية تعيين الخصائص في Groovy:

java {
    sourceCompatibility JavaVersion.VERSION_17
    targetCompatibility JavaVersion.VERSION_17
}

يوضّح هذا الرمز البرمجي كيفية تعيين الخصائص في Kotlin:

java {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
}

تحويل السلاسل

في ما يلي الاختلافات في السلاسل بين Groovy وKotlin:

• علامات الاقتباس المزدوجة للسلاسل: على الرغم من أنّ Groovy تسمح بتحديد السلاسل باستخدام علامات الاقتباس المفردة، فإنّ Kotlin تتطلب علامات الاقتباس المزدوجة.

• تضمين السلاسل في التعبيرات المنقّطة: في Groovy، يمكنك استخدام البادئة $ فقط لـ تضمين السلاسل في التعبيرات المنقّطة، ولكن تتطلب Kotlin وضع التعبيرات المنقّطة بين أقواس معقوفة. على سبيل المثال، في Groovy، يمكنك استخدام $project.rootDir كما هو موضّح في المقتطف التالي:

      myRootDirectory = "$project.rootDir/tools/proguard-rules-debug.pro"
      

  في Kotlin، يستدعي الرمز البرمجي السابق toString() على project، وليس على project.rootDir. للحصول على قيمة دليل الجذر، ضَع التعبير ${project.rootDir} بين أقواس معقوفة:

      myRootDirectory = "${project.rootDir}/tools/proguard-rules-debug.pro"
      

  لمزيد من المعلومات، يُرجى الاطّلاع على String templates في مستندات Kotlin.

إعادة تسمية امتدادات الملفات

أضِف .kts إلى كل ملف تصميم أثناء نقل محتواه. على سبيل المثال، اختَر ملف تصميم، مثل الملف settings.gradle. أعِد تسمية الملف إلى settings.gradle.kts وحوِّل محتواه إلى Kotlin. تأكَّد من أنّ مشروعك لا يزال يتم تجميعه بعد نقل كل ملف تصميم.

ابدأ بنقل أصغر الملفات أولاً، واكتسِب الخبرة، ثم انتقِل إلى الملفات الأكبر. يمكن أن يحتوي المشروع على مزيج من ملفات تصميم Kotlin وGroovy، لذا خذ وقتك لإجراء عملية النقل بعناية.

استبدال def بـ val أو var

استبدِل def بـ val أو var، وهما الطريقتان اللتان يمكنك من خلالهما تحديد المتغيّرات في Kotlin. في ما يلي إعلان عن متغيّر في Groovy:

def building64Bit = false

هذا هو الرمز البرمجي نفسه مكتوبًا بلغة Kotlin:

val building64Bit = false

إضافة is كبادئة للخصائص المنطقية

تستخدم Groovy منطق استنتاج الخصائص استنادًا إلى أسماء الخصائص. بالنسبة إلى الخاصية المنطقية foo، يمكن أن تكون الطرق المستنتَجة هي getFoo أو setFoo أو isFoo. وبالتالي، بعد التحويل إلى Kotlin، عليك تغيير أسماء الخصائص إلى الطرق المستنتَجة التي لا تتوافق مع Kotlin. على سبيل المثال، بالنسبة إلى العناصر المنطقية في buildTypes DSL، عليك إضافة is كبادئة لها. يوضّح هذا الرمز البرمجي كيفية ضبط الخصائص المنطقية في Groovy:

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            ...
        }
        debug {
            debuggable true
            ...
        }
    ...

في ما يلي الرمز البرمجي نفسه في Kotlin. يُرجى العِلم أنّ الخصائص مسبوقة بـ is.

android {
    buildTypes {
        getByName("release") {
            isMinifyEnabled = true
            isShrinkResources = true
            ...
        }
        getByName("debug") {
            isDebuggable = true
            ...
        }
    ...

تحويل القوائم والخرائط

يتم تحديد القوائم والخرائط في Groovy وKotlin باستخدام بنية مختلفة. تستخدم Groovy []، بينما تستدعي Kotlin طرق إنشاء المجموعة بشكل صريح باستخدام listOf أو mapOf. تأكَّد من استبدال [] بـ listOf أو mapOf عند نقل البيانات.

في ما يلي كيفية تحديد قائمة في Groovy مقابل Kotlin:

jvmOptions += ["-Xms4000m", "-Xmx4000m", "-XX:+HeapDumpOnOutOfMemoryError</code>"]

هذا هو الرمز البرمجي نفسه مكتوبًا بلغة Kotlin:

jvmOptions += listOf("-Xms4000m", "-Xmx4000m", "-XX:+HeapDumpOnOutOfMemoryError")

في ما يلي كيفية تحديد خريطة في Groovy مقابل Kotlin:

def myMap = [key1: 'value1', key2: 'value2']

هذا هو الرمز البرمجي نفسه مكتوبًا بلغة Kotlin:

val myMap = mapOf("key1" to "value1", "key2" to "value2")

إعداد أنواع التصميم

في Kotlin DSL، لا يتوفّر بشكل ضمني سوى نوعَي التصميم debug وrelease. يجب إنشاء جميع أنواع التصميم المخصّصة الأخرى يدويًا.

في Groovy، يمكنك استخدام أنواع التصميم debug وrelease وبعض أنواع التصميم الأخرى بدون إنشائها أولاً. يوضّح مقتطف الرمز البرمجي التالي إعدادًا يتضمّن أنواع التصميم debug وrelease و benchmark في Groovy.

buildTypes {
 debug {
   ...
 }
 release {
   ...
 }
 benchmark {
   ...
 }
}

لإنشاء الإعداد المكافئ في Kotlin، عليك إنشاء نوع التصميم benchmark بشكل صريح.

buildTypes {
 debug {
   ...
 }

 release {
   ...
 }
 register("benchmark") {
    ...
 }
}

نقل البيانات من buildscript إلى كتلة plugins

إذا كان تصميمك يستخدم كتلة buildscript {} لإضافة مكوّنات إضافية إلى مسار فئة التصميم، عليك إعادة هيكلة الرمز البرمجي لاستخدام كتلة plugins {} بدلاً من ذلك. تسهّل كتلة plugins {} تطبيق المكوّنات الإضافية، وتعمل بشكل جيد مع فهارس الإصدارات.

بالإضافة إلى ذلك، عند استخدام كتلة plugins {} في ملفات التصميم، يكون "استوديو Android" على دراية بالسياق حتى عند فشل التصميم. يساعد هذا السياق في إجراء إصلاحات على ملفات Kotlin DSL لأنّه يسمح لبيئة التطوير المتكاملة في "استوديو Android" بإكمال الرموز البرمجية وتقديم اقتراحات مفيدة أخرى.

العثور على أرقام تعريف المكوّنات الإضافية

بينما تضيف كتلة buildscript {} المكوّنات الإضافية إلى مسار فئة التصميم باستخدام إحداثيات Maven الخاصة بالمكوّن الإضافي، على سبيل المثال com.android.tools.build:gradle:7.4.0, تستخدم كتلة plugins {} أرقام تعريف المكوّن الإضافي بدلاً من ذلك.

بالنسبة إلى معظم المكوّنات الإضافية، يكون رقم تعريف المكوّن الإضافي هو السلسلة المستخدَمة عند تطبيقها باستخدام apply plugin. على سبيل المثال، تشكّل أرقام تعريف المكوّنات الإضافية التالية جزءًا من المكوّن الإضافي لنظام Gradle المتوافق مع Android:

• com.android.application
• com.android.library
• com.android.lint
• com.android.test

يمكنك العثور على قائمة المكوّنات الإضافية الكاملة في مستودع Maven من Google.

يمكن الإشارة إلى مكوّنات Kotlin الإضافية باستخدام أرقام تعريف مكوّنات إضافية متعددة. ننصحك باستخدام رقم تعريف المكوّن الإضافي المستند إلى مساحة الاسم، وإعادة هيكلة الرمز البرمجي من رقم تعريف المكوّن الإضافي المختصر إلى رقم تعريف المكوّن الإضافي المستند إلى مساحة الاسم باستخدام الجدول التالي:

يمكنك أيضًا البحث عن مكوّنات إضافية على الـ Gradle Plugin Portal، والـ Maven Central Repository، والـ ـ Google Maven repository. يُرجى قراءة مقالة Developing Custom Gradle Plugins لمزيد من المعلومات حول طريقة عمل أرقام تعريف المكوّنات الإضافية.

إجراء عملية إعادة الهيكلة

بعد معرفة أرقام تعريف المكوّنات الإضافية التي تستخدمها، اتّبِع الخطوات التالية:

1. إذا كان لا يزال لديك مستودعات للمكوّنات الإضافية المُعلَنة في الـ buildscript {} كتلة، انقلها إلى الـ settings.gradle ملف بدلاً من ذلك.

2. أضِف المكوّنات الإضافية إلى كتلة plugins {} في الملف build.gradle على المستوى الأعلى. عليك تحديد رقم تعريف المكوّن الإضافي وإصداره هنا. إذا لم يكن من الضروري تطبيق المكوّن الإضافي على المشروع الجذر، استخدِم apply false.

3. أزِل إدخالات classpath من الملف build.gradle.kts على المستوى الأعلى.

4. طبِّق المكوّنات الإضافية عن طريق إضافتها إلى كتلة plugins {} في الملف build.gradle على مستوى الوحدة. عليك تحديد رقم تعريف المكوّن الإضافي هنا فقط لأنّ الإصدار موروث من المشروع الجذر.

5. أزِل استدعاء apply plugin للمكوّن الإضافي من الملف build.gradle على مستوى الوحدة.

على سبيل المثال، يستخدم هذا الإعداد كتلة buildscript {}:

// Top-level build.gradle file
buildscript {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
    dependencies {
        classpath("com.android.tools.build:gradle:7.4.0")
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0")
        ...
    }
}

// Module-level build.gradle file
apply(plugin: "com.android.application")
apply(plugin: "kotlin-android")

في ما يلي إعداد مكافئ يستخدم كتلة plugins {}:

// Top-level build.gradle file
plugins {
   id 'com.android.application' version '7.4.0' apply false
   id 'org.jetbrains.kotlin.android' version '1.8.0' apply false
   ...
}

// Module-level build.gradle file
plugins {
   id 'com.android.application'
   id 'org.jetbrains.kotlin.android'
   ...
}

// settings.gradle
pluginManagement {
    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

تحويل كتلة المكوّنات الإضافية

إنّ تطبيق المكوّنات الإضافية من كتلة plugins {} مشابه في Groovy وKotlin. يوضّح الرمز البرمجي التالي كيفية تطبيق المكوّنات الإضافية في Groovy عند استخدام فهارس الإصدارات:

// Top-level build.gradle file
plugins {
   alias libs.plugins.android.application apply false
   ...
}

// Module-level build.gradle file
plugins {
   alias libs.plugins.android.application
   ...
}

يوضّح الرمز البرمجي التالي كيفية إجراء ذلك في Kotlin:

// Top-level build.gradle.kts file
plugins {
   alias(libs.plugins.android.application) apply false
   ...
}

// Module-level build.gradle.kts file
plugins {
   alias(libs.plugins.android.application)
   ...
}

يوضّح الرمز البرمجي التالي كيفية تطبيق المكوّنات الإضافية في Groovy عندما لا تستخدم فهارس الإصدارات:

// Top-level build.gradle file
plugins {
   id 'com.android.application' version '7.3.0' apply false
   ...
}

// Module-level build.gradle file
plugins {
   id 'com.android.application'
   ...
}

يوضّح الرمز البرمجي التالي كيفية إجراء ذلك في Kotlin:

// Top-level build.gradle.kts file
plugins {
   id("com.android.application") version "7.3.0" apply false
   ...
}

// Module-level build.gradle.kts file
plugins {
   id("com.android.application")
   ...
}

لمزيد من التفاصيل حول كتلة plugins {}، يُرجى الاطّلاع على Applying plugins في مستندات Gradle.

متنوعة

للاطّلاع على نماذج رموز Kotlin البرمجية للوظائف الأخرى، يُرجى الرجوع إلى صفحات المستندات التالية:

• إذا كان لديك إعداد ProGuard، يُرجى الرجوع إلى مقالة تفعيل ميزات تقليل حجم الرمز البرمجي وإخفائه وتحسينه.
• إذا كان لديك كتلة signingConfig {}، يُرجى الرجوع إلى مقالة إزالة معلومات التوقيع من ملفات التصميم.
• إذا كنت تستخدم خصائص على مستوى المشروع، يُرجى الرجوع إلى إعداد خصائص على مستوى المشروع.

المشاكل المعروفة

في الوقت الحالي، هناك مشكلة معروفة تتمثل في أنّ سرعة التصميم قد تكون أبطأ باستخدام Kotlin مقارنةً باستخدام Groovy.

كيفية الإبلاغ عن المشاكل

للحصول على تعليمات حول كيفية تقديم المعلومات التي نحتاج إليها لتصنيف مشكلتك، يُرجى الاطّلاع على مقالة Details for build tools and Gradle bugs. بعد ذلك، أبلِغ عن خطأ باستخدام أداة تتبّع المشاكل العامة من Google .

مزيد من المراجع

للاطّلاع على مثال عملي لملفات تصميم Gradle مكتوبة بلغة Kotlin، يُرجى الرجوع إلى نموذج تطبيق Now In Android على GitHub.