اندروید استودیو ایگوانا | 2023.2.1 (فوریه 2024)

موارد زیر ویژگی های جدید اندروید استودیو ایگوانا هستند.

پچ منتشر می شود

در زیر لیستی از پچ های منتشر شده در Android Studio Iguana و Android Gradle پلاگین 8.3 است.

اندروید استودیو ایگوانا | پچ 2 2023.2.1 و AGP 8.3.2 (آوریل 2024)

این به روز رسانی جزئی شامل این رفع اشکال است.

اندروید استودیو ایگوانا | پچ 1 2023.2.1 و AGP 8.3.1 (مارس 2024)

این به روز رسانی جزئی شامل این رفع اشکال است.

به روز رسانی پلتفرم IntelliJ IDEA 2023.2

Android Studio Iguana شامل به روز رسانی IntelliJ IDEA 2023.2 است که تجربه Studio IDE را بهبود می بخشد. برای جزئیات تغییرات، به یادداشت‌های انتشار IntelliJ IDEA 2023.2 مراجعه کنید.

ادغام سیستم کنترل نسخه در App Quality Insights

App Quality Insights اکنون به شما امکان می‌دهد از ردیابی پشته Crashlytics به کد مربوطه پیمایش کنید—در نقطه‌ای از زمان وقوع خرابی. AGP داده‌های هش git commit را به گزارش‌های خرابی پیوست می‌کند، که به Android Studio کمک می‌کند به کد شما پیمایش کند و نشان دهد که در نسخه‌ای که مشکل در آن رخ داده است، چگونه بوده است. وقتی گزارش خرابی را در App Quality Insights مشاهده می‌کنید، می‌توانید انتخاب کنید که به خط کد موجود در تسویه‌حساب git فعلی خود بروید یا تفاوت بین پرداخت فعلی و نسخه پایگاه کد خود را که خرابی را ایجاد کرده است مشاهده کنید.

برای ادغام سیستم کنترل نسخه خود با App Quality Insights ، به حداقل شرایط زیر نیاز دارید:

• آخرین نسخه قناری اندروید استودیو ایگوانا
• آخرین نسخه آلفا پلاگین اندروید Gradle 8.3
• Crashlytics SDK v18.3.7 (یا Firebase Android Bill of Materials v32.0.0 )

برای استفاده از ادغام کنترل نسخه برای نوع ساخت قابل اشکال زدایی، پرچم vcsInfo را در فایل ساخت سطح ماژول فعال کنید. برای ساخت های انتشار (غیر اشکال زدایی)، پرچم به طور پیش فرض فعال است.

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

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

اکنون، هنگامی که برنامه خود را می‌سازید و در Google Play منتشر می‌کنید، گزارش‌های خرابی شامل داده‌های لازم برای پیوند IDE به نسخه‌های قبلی برنامه شما از ردیابی پشته است.

انواع خرابی Crashlytics را در App Quality Insights مشاهده کنید

برای کمک به تجزیه و تحلیل دلایل اصلی خرابی، اکنون می‌توانید از App Quality Insights برای مشاهده رویدادها بر اساس انواع مشکل یا گروه‌هایی از رویدادها استفاده کنید که دارای ردیابی پشته مشابه هستند. برای مشاهده رویدادها در هر گونه گزارش خرابی، یک نوع را از منوی کشویی انتخاب کنید. برای جمع آوری اطلاعات برای همه انواع، همه را انتخاب کنید.

نوشتن بررسی رابط کاربری

Android Studio Iguana Canary 5 برای کمک به توسعه‌دهندگان در ساخت رابط‌های کاربری سازگارتر و در دسترس‌تر در Jetpack Compose، حالت بررسی رابط کاربری جدیدی را در Compose Preview معرفی کرد. این ویژگی شبیه به Visual linting کار می‌کند و قابلیت دسترسی ادغام‌ها را برای نماها بررسی می‌کند . وقتی حالت بررسی رابط کاربری Compose را فعال می‌کنید، Android Studio به‌طور خودکار رابط کاربری Compose شما را بررسی می‌کند و مشکلات تطبیقی ​​و دسترسی را در اندازه‌های مختلف صفحه، مانند متن کشیده شده در صفحه‌های بزرگ یا کنتراست کم رنگ بررسی می‌کند. این حالت، مشکلات موجود در تنظیمات پیش‌نمایش مختلف را برجسته می‌کند و آنها را در پانل مشکلات فهرست می‌کند.

امروز با کلیک بر روی دکمه UI Check این ویژگی را امتحان کنید در Compose Preview و ارسال بازخورد خود:

مشکلات شناخته شده UI Check Mode:

• مشکل انتخاب شده در پانل مشکل ممکن است تمرکز خود را از دست بدهد
• "قانون سرکوب" کار نمی کند

رندر پیشرو برای پیش نمایش نوشتن

اندروید استودیو Iguana Canary 3 رندر پیشرو در پیش نمایش Compose را معرفی می کند. به عنوان بخشی از تلاش مستمر برای عملکرد بیشتر پیش‌نمایش‌ها، اکنون برای هر پیش‌نمایش غیرقابل مشاهده، ما عمداً کیفیت رندر آن‌ها را کاهش می‌دهیم تا حافظه استفاده شده ذخیره شود.

این ویژگی با هدف بهبود بیشتر قابلیت استفاده پیش‌نمایش‌ها با امکان مدیریت پیش‌نمایش‌های بیشتر به طور همزمان در یک فایل ایجاد شده است. امروز آن را امتحان کنید و بازخورد خود را ارسال کنید .

جادوگر ماژول پروفایل های پایه

با شروع Android Studio Iguana، می‌توانید با استفاده از الگوی Baseline Profile Generator در جادوگر جدید ماژول ( File > New > New Module ) ، پروفایل‌های پایه را برای برنامه خود ایجاد کنید.

این الگو پروژه شما را طوری تنظیم می کند که بتواند از نمایه های پایه پشتیبانی کند. از افزونه جدید Baseline Profiles Gradle استفاده می کند که فرآیند تنظیم پروژه شما را به روش مورد نیاز با یک کار Gradle خودکار می کند.

این الگو همچنین یک پیکربندی اجرا ایجاد می کند که به شما امکان می دهد با یک کلیک از لیست کشویی Select Run/Debug Configuration یک نمایه پایه ایجاد کنید.

در برابر تغییرات پیکربندی با API دستگاه اسپرسو تست کنید

از API دستگاه اسپرسو برای آزمایش برنامه خود در زمانی که دستگاه دچار تغییرات پیکربندی رایجی مانند چرخش و باز شدن صفحه می شود، استفاده کنید. Espresso Device API به شما امکان می‌دهد این تغییرات پیکربندی را در یک دستگاه مجازی شبیه‌سازی کنید و آزمایش‌های شما را به صورت همزمان اجرا کند، بنابراین تنها یک اقدام یا ادعای UI در یک زمان اتفاق می‌افتد و نتایج آزمایش شما قابل اعتمادتر است. درباره نحوه نوشتن تست های رابط کاربری با اسپرسو بیشتر بیاموزید.

برای استفاده از API دستگاه اسپرسو، به موارد زیر نیاز دارید:

• Android Studio Iguana یا بالاتر
• پلاگین اندروید Gradle 8.3 یا بالاتر
• شبیه ساز اندروید 33.1.10 یا بالاتر
• دستگاه مجازی Android که API سطح 24 یا بالاتر را اجرا می کند

پروژه خود را برای API دستگاه اسپرسو تنظیم کنید

برای تنظیم پروژه خود به گونه ای که از 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 را در اسکریپت ساخت سطح ماژول فعال کنید:

   کاتلین

     testOptions {
       emulatorControl {
         enable = true
       }
     }

   شیار

     testOptions {
       emulatorControl {
         enable = true
       }
     }

4. در اسکریپت ساخت سطح ماژول، کتابخانه دستگاه اسپرسو را به پروژه خود وارد کنید:

   کاتلین

     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 استفاده کنید. دونده آزمایشی به طور خودکار از آزمایش‌های در حال اجرا روی دستگاه‌هایی که پیکربندی مورد آزمایش را پشتیبانی نمی‌کنند، صرفنظر می‌کند. می‌توانید قانون نیاز دستگاه را به هر آزمون یا کل کلاس آزمایشی اضافه کنید.

به عنوان مثال، برای تعیین اینکه یک آزمایش فقط باید در دستگاه‌هایی اجرا شود که از unfolding به یک پیکربندی مسطح پشتیبانی می‌کنند، کد @RequiresDeviceMode زیر را به تست خود اضافه کنید:

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