Android Studio Iguana | 2023.2.1 (شباط/فبراير 2024)

في ما يلي الميزات الجديدة في "استوديو Android" Iguana.

إصدارات رموز التصحيح

في ما يلي قائمة بإصدارات رموز التصحيح في إصدار Iguana من "استوديو Android" والمكوّن الإضافي لنظام Gradle المتوافق مع Android 8.3.

‫استوديو Android Iguana | 2023.2.1 Patch 2 وAGP 8.3.2 (أبريل 2024)

يتضمّن هذا التحديث البسيط إصلاحات الأخطاء التالية.

‫استوديو Android Iguana | 2023.2.1 Patch 1 وAGP 8.3.1 (مارس 2024)

يتضمّن هذا التحديث البسيط إصلاحات الأخطاء التالية.

تحديث منصة IntelliJ IDEA 2023.2

يتضمّن "استوديو Android" Iguana تحديثات IntelliJ IDEA 2023.2، ما يحسّن تجربة بيئة التطوير المتكاملة (IDE) في "استوديو Android". للاطّلاع على تفاصيل التغييرات، يُرجى مراجعة ملاحظات إصدار IntelliJ IDEA 2023.2.

دمج نظام التحكّم في الإصدارات في أداة "تحليل جودة التطبيق"

تتيح لك أداة تحليل جودة التطبيق الآن الانتقال من تتبُّع تسلسل استدعاءات Crashlytics إلى الرمز البرمجي ذي الصلة في الوقت الذي حدث فيه العطل. يرفق المكوّن الإضافي لنظام Gradle المتوافق مع Android بيانات تجزئة عملية الإرسال في Git بتقارير الأعطال، ما يساعد "استوديو Android" في الانتقال إلى الرمز البرمجي وعرض شكله في الإصدار الذي حدثت فيه المشكلة. عند عرض تقرير عطل في أداة "تحليل جودة التطبيق"، يمكنك اختيار الانتقال إلى سطر الرمز البرمجي في عملية السحب الحالية في Git أو عرض الفرق بين عملية السحب الحالية وإصدار قاعدة الرموز البرمجية الذي أدّى إلى حدوث العطل.

لدمج نظام التحكّم في الإصدارات مع أداة "تحليل جودة التطبيق"، يجب استيفاء الحد الأدنى من المتطلبات التالية:

• أحدث إصدار Canary من "استوديو Android" Iguana
• أحدث إصدار Alpha من المكوّن الإضافي لنظام Gradle المتوافق مع Android 8.3
• Crashlytics SDK الإصدار 18.3.7 (أو قائمة مواد منصة Firebase لأجهزة Android الإصدار 32.0.0)

لاستخدام ميزة دمج التحكم في الإصدارات لنوع التصميم القابل للتصحيح، فعِّل العلامة vcsInfo في ملف الإصدار على مستوى الوحدة. بالنسبة إلى عمليات الإنشاء الخاصة بالإصدار (غير القابلة لتصحيح الأخطاء)، تكون العلامة مفعّلة تلقائيًا.

android {
  buildTypes {
    getByName("debug") {
      vcsInfo {
        include = true
      }
    }
  }
}

android {
  buildTypes {
    debug {
      vcsInfo {
        include true
      }
    }
  }
}

عند إنشاء تطبيقك ونشره على Google Play، تتضمّن تقارير الأعطال الآن البيانات اللازمة لربط بيئة التطوير المتكاملة (IDE) بالإصدارات السابقة من تطبيقك من تتبع تسلسل استدعاء الدوال البرمجية.

عرض أشكال الأعطال في Crashlytics في أداة "تحليل جودة التطبيق"

لمساعدتك في تحليل الأسباب الجذرية للعطل، يمكنك الآن استخدام أداة "تحليل جودة التطبيق" لعرض الأحداث حسب أشكال المشكلة، أو مجموعات الأحداث التي تتضمّن تتبُّع تسلسل استدعاءات مشابهة. لعرض الأحداث في كل شكل من أشكال تقرير العطل، اختَر شكلاً من القائمة المنسدلة. لتجميع المعلومات لجميع الأشكال، اختَر الكل.

ميزة "التحقّق من واجهة مستخدم Compose"

لمساعدة المطوّرين في إنشاء واجهات مستخدم أكثر تكيفًا وسهولة في الوصول إليها في Jetpack Compose، قدّم "استوديو Android" Iguana Canary 5 وضعًا جديدًا لميزة "التحقّق من واجهة مستخدم Compose" في "معاينة Compose". تعمل هذه الميزة بشكل مشابه لعمليات دمج ميزتَي "التدقيق المرئي وعمليات التحقّق من إمكانية الوصول " للعروض. عند تفعيل وضع "التحقّق من واجهة مستخدم Compose"، يراجع "استوديو Android" تلقائيًا واجهة مستخدم Compose ويتحقّق من المشاكل المتعلّقة بالتكيّف وتسهيل الاستخدام على أحجام الشاشات المختلفة، مثل النص الممدود على الشاشات الكبيرة أو التباين المنخفض للألوان. يُبرز الوضع المشاكل التي تم العثور عليها في إعدادات المعاينة المختلفة ويدرجها في لوحة المشاكل.

يمكنك تجربة هذه الميزة اليوم من خلال النقر على الزر "التحقّق من واجهة مستخدم Compose" في "معاينة Compose" وإرسال ملاحظاتك:

المشاكل المعروفة في "وضع التحقّق من واجهة مستخدم Compose":

• قد يفقد العنصر المحدّد في لوحة المشاكل التركيز
• لا تعمل ميزة "إيقاف القاعدة مؤقتًا"

ميزة "العرض التدريجي" في "معاينة Compose"

يقدّم "استوديو Android" Iguana Canary 3 ميزة "العرض التدريجي" في "معاينة Compose". في إطار الجهود المستمرة لتحسين أداء المعاينات، نعمل الآن على تقليل جودة عرض أي معاينة خارج نطاق العرض بشكل متعمّد لتوفير الذاكرة المستخدَمة.

تم تطوير هذه الميزة بهدف تحسين سهولة استخدام المعاينات بشكل أكبر من خلال إمكانية التعامل مع المزيد من المعاينات في الوقت نفسه في ملف واحد. ننصحك بتجربتها اليوم وإرسال ملاحظاتك.

معالج وحدة "الملفات الشخصية للمرجع"

بدءًا من "استوديو Android" Iguana، يمكنك إنشاء ملفات شخصية للمرجع لتطبيقك باستخدام نموذج أداة إنشاء الملفات الشخصية للمرجع في معالج الوحدة الجديد (ملف > جديد > وحدة جديدة).

يضبط هذا النموذج مشروعك بحيث يمكنه دعم "الملفات الشخصية للمرجع". يستخدم النموذج المكوّن الإضافي الجديد لنظام Gradle الخاص بـ "الملفات الشخصية للمرجع"، والذي يعمل على أتمتة عملية إعداد مشروعك بالطريقة المطلوبة باستخدام مهمة Gradle واحدة.

ينشئ النموذج أيضًا إعداد تشغيل يتيح لك إنشاء "ملف شخصي للمرجع" بنقرة واحدة من القائمة المنسدلة اختيار إعداد التشغيل/تصحيح الأخطاء.

الاختبار في مقابل تغييرات الإعدادات باستخدام Espresso Device API

استخدِم Espresso Device API لاختبار تطبيقك عندما يخضع الجهاز لتغييرات شائعة في الإعدادات، مثل تدوير الشاشة وفتحها. تتيح لك Espresso Device API محاكاة تغييرات الإعدادات هذه على جهاز افتراضي وتنفيذ اختباراتك بشكل متزامن، لذا لا يحدث سوى إجراء واحد على واجهة المستخدم أو تأكيد واحد في كل مرة، وتكون نتائج الاختبار أكثر موثوقية. مزيد من المعلومات عن كيفية كتابة اختبارات واجهة المستخدم باستخدام Espresso.

لاستخدام Espresso Device API، يجب استيفاء المتطلبات التالية:

• "استوديو Android" Iguana أو إصدار أحدث
• المكوّن الإضافي لنظام Gradle المتوافق مع Android 8.3 أو إصدار أحدث
• المحاكي Android Emulator 33.1.10 أو إصدار أحدث
• جهاز Android افتراضي يعمل بمستوى واجهة برمجة التطبيقات 24 أو إصدار أحدث

إعداد مشروعك لاستخدام Espresso Device API

لإعداد مشروعك بحيث يتوافق مع Espresso Device API، اتّبِع الخطوات التالية:

1. للسماح للاختبار بتمرير الأوامر إلى الجهاز الاختباري، أضِف الإذنَين INTERNET و ACCESS_NETWORK_STATE إلى ملف البيان في مجموعة رموز المصدر androidTest:

     <uses-permission android:name="android.permission.INTERNET" />
     <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />

2. فعِّل العلامة التجريبية enableEmulatorControl في الملف gradle.properties:

     android.experimental.androidTest.enableEmulatorControl=true

3. فعِّل الخيار emulatorControl في نص برمجة الإنشاء على مستوى الوحدة:

   Kotlin

     testOptions {
       emulatorControl {
         enable = true
       }
     }

   أنيق

     testOptions {
       emulatorControl {
         enable = true
       }
     }

4. في نص برمجة الإنشاء على مستوى الوحدة، استورِد مكتبة Espresso Device إلى مشروعك:

   Kotlin

     dependencies {
       androidTestImplementation("androidx.test.espresso:espresso-device:3.6.1")
     }

   أنيق

     dependencies {
       androidTestImplementation 'androidx.test.espresso:espresso-device:3.6.1'
     }

الاختبار في مقابل تغييرات الإعدادات الشائعة

تتضمّن Espresso Device API حالات متعددة لاتجاه الشاشة وحالات الأجهزة القابلة للطي يمكنك استخدامها لمحاكاة تغييرات إعدادات الجهاز.

الاختبار في مقابل تدوير الشاشة

في ما يلي مثال على كيفية اختبار ما يحدث لتطبيقك عند تدوير شاشة الجهاز:

1. أولاً، اضبط الجهاز على الوضع العمودي للحصول على حالة بدء متّسقة:

     import androidx.test.espresso.device.action.ScreenOrientation
     import androidx.test.espresso.device.rules.ScreenOrientationRule
     ...
     @get:Rule
     val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)

2. أنشئ اختبارًا يضبط الجهاز على الوضع الأفقي أثناء تنفيذ الاختبار:

     @Test
     fun myRotationTest() {
       ...
       // Sets the device to landscape orientation during test execution.
       onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
       ...
     }

3. بعد تدوير الشاشة، تأكَّد من أنّ واجهة المستخدم تتكيّف مع التنسيق الجديد على النحو المتوقّع:

     @Test
     fun myRotationTest() {
       ...
       // Sets the device to landscape orientation during test execution.
       onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
       composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
       composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist()
     }

الاختبار في مقابل فتح الشاشة

في ما يلي مثال على كيفية اختبار ما يحدث لتطبيقك إذا كان على جهاز قابل للطي وتم فتح الشاشة:

1. أولاً، اختبِر الجهاز في الحالة المطوية من خلال استدعاء onDevice().setClosedMode(). تأكَّد من أنّ تنسيق تطبيقك يتكيّف مع عرض الشاشة الصغير:

     @Test
     fun myUnfoldedTest() {
       onDevice().setClosedMode()
       composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
       composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
       ...
     }

2. للانتقال إلى حالة الفتح الكامل، استدعِ onDevice().setFlatMode(). تأكَّد من أنّ تنسيق التطبيق يتكيّف مع فئة الحجم الموسّعة:

     @Test
     fun myUnfoldedTest() {
       onDevice().setClosedMode()
       ...
       onDevice().setFlatMode()
       composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
       composeTestRule.onNodeWithTag("BottomBar").assetDoesNotExist()
     }

تحديد الأجهزة التي تحتاج إليها اختباراتك

إذا كنت تُجري اختبارًا ينفّذ إجراءات الطي على جهاز غير قابل للطي، يفشل الاختبار عادةً. لتنفيذ الاختبارات ذات الصلة بالجهاز الذي يتم تشغيله فقط، استخدِم التعليق التوضيحي @RequiresDeviceMode. يتخطّى برنامج تشغيل الاختبار تلقائيًا تشغيل الاختبارات على الأجهزة التي لا تتوافق مع الإعدادات التي يتم اختبارها. يمكنك إضافة قاعدة متطلبات الجهاز إلى كل اختبار أو إلى فئة اختبار كاملة.

على سبيل المثال، لتحديد أنّه يجب تشغيل الاختبار على الأجهزة التي تتيح الفتح إلى إعدادات مسطّحة فقط، أضِف رمز @RequiresDeviceMode التالي إلى اختبارك:

@Test
@RequiresDeviceMode(mode = FLAT)
fun myUnfoldedTest() {
  ...
}