إنشاء إصدارات Android تعريفية وجاهزة للوكلاء باستخدام Lightbuild

مرحبًا،

اسمي "خوان سيباستيان أوفييدو".

أنا مدير منتجات في فريق تجربة مطوّري برامج Android.

أنا و"سكوت" متحمّسان اليوم لمشاركة نظرة أولية على Lightbuild، وهي تجربة جديدة تجريبية لإنشاء تطبيقات Android.

سأستعرض سياق هذا المشروع والفلسفة الكامنة وراءه وسبب اعتقادنا بأنّ الوقت الحالي هو الوقت المناسب لإعادة التفكير في كيفية ضبط مشاريع Android.

سأشرح أيضًا كيف يمهّد هذا النهج الجديد الطريق لمستقبل تطوير تطبيقات Android.

لنبدأ ببعض المعلومات حول كيفية عمل الأمور اليوم.

تتيح أداة Gradle ونصوص الإنشاء البرمجية للمطوّرين تحديد كل ما يتعلق بعمليات الإنشاء برمجيًا.

على سبيل المثال، يمكنك استخدام منطق يحسب رموز الإصدارات ديناميكيًا استنادًا إلى سجلّ Git، أو تحديد مهمة مخصّصة تحوّل مواد العرض.

// build.gradle.kts
android {

  compileSdk = 37

  buildTypes {

    debug {

      // Custom logic in build script
      val commit = providers.exec {
        commandLine("git", "rev-parse",
                    "--short", "HEAD")
      }.standardOutput.asText.get()
       .trim()

      versionNameSuffix = "-$commit"

    }

  }

}

إلى جانب Gradle، هناك AGP أو المكوّن الإضافي لنظام Gradle المتوافق مع Android، والذي يأخذ محرّك Gradle للأغراض العامة ويُكيّفه مع سلسلة أدوات Android.

يشكّل Gradle وAGP معًا نظامًا ديناميكيًا يتيح إعدادات التصميم لملايين التطبيقات الإنتاجية اليوم.

بسبب هذه المرونة، تعمل أدوات التطوير لدينا ضمن دورة حياة معمارية محدّدة.

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

بما أنّ ملفات الإصدار مكتوبة بلغة حتمية كاملة من Turing، فإنّ الطريقة العامة الوحيدة التي تتيح لبيئة التطوير المتكاملة معرفة الإعدادات هي تشغيل النصوص البرمجية للإصدار.

أثناء مزامنة IDE، يمرّ نظام التصميم بمرحلة ضبط الإعدادات.

ويقيّم نصوص الإنشاء البرمجية، وينفّذ منطق المكوّنات الإضافية، وينشئ نموذج المشروع.

يؤدي ذلك إلى مواءمة طريقة عرض "استوديو Android" لمشروعك مع إعدادات مشروعك الفعلية.

بصفتكم مطوّرين، فإنّ أهم ما يشغلكم هو تقديم تطبيق Android رائع وإتاحته للمستخدمين.

ومع ذلك، فإنّ إدارة نصوص الإنشاء البرمجية، وإبقاء "المكوّن الإضافي لنظام Gradle المتوافق مع Android" محدّثًا، ومزامنة المشروع مع بيئة التطوير المتكاملة (IDE) يستغرق وقتًا وجهدًا.

هناك العديد من المبادرات في Google والمنظومة المتكاملة الأوسع نطاقًا التي تعمل على تحسين تجربة المطوّرين في هذا المجال.

تهدف المبادرات، مثل Declarative Gradle وسلسلة أدوات Kotlin، إلى استبدال نصوص التصميم البرمجية القابلة للتنفيذ بإعدادات تصميم توضيحية.

في "استوديو Android"، يتوفّر "مساعد ترقية المكوّن الإضافي لنظام Gradle المتوافق مع Android" الذي يوجّهك خلال التغييرات اللازمة للانتقال من إصدار إلى آخر من المكوّن الإضافي لنظام Gradle المتوافق مع Android.

نوفّر أيضًا مهارة ترقية يمكن للوكلاء تثبيتها واتّباعها لترقية AGP.

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

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

إلى جانب هذه الجهود، طرحنا على أنفسنا سؤالاً أوسع.

ماذا لو أعدنا تصوّر طريقة ضبط المشاريع من البداية؟

عندما ننظر إلى طريقة تصميم تطبيقات Android الحديثة اليوم، نرى تحولاً كبيرًا نحو الوحدات النمطية الثقيلة.

غالبًا ما تحتوي قواعد الرموز البرمجية الكبيرة على عشرات أو حتى مئات الوحدات: وحدات واجهة المستخدم ووحدات الميزات ووحدات النطاق ووحدات البيانات.

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

ولا يحتاجون فعليًا إلى تضمين رمز برمجي عشوائي قابل للتنفيذ في ملفات الإصدارات.

كل ما يحتاجون إليه هو طريقة واضحة لتحديد بنيتها وعلاقاتها.

وقد دفعتنا هذه الملاحظة إلى إنشاء Lightbuild.

تستند Lightbuild إلى ركيزتَين أساسيتَين.

أولاً، تستخدم هذه الأداة بنية تعريفية للإعدادات، ما يوفّر فصلاً واضحًا بين إعدادات التصميم والمنطق.

ثانيًا، يوفّر تجربة مزامنة سريعة لبيئة التطوير المتكاملة من خلال حلّ التبعيات مسبقًا.

سأشرح كل ركيزة من هذه الركائز بالتفصيل ليتّضح لك تأثيرها في سير عملك اليومي.

لنبدأ بالركيزة الأساسية لإعدادات التصميم التعريفية.

ألقِ نظرة على الملف الموجود على الجانب الأيسر من الشاشة.

يمثّل هذا الإعدادات الحالية للوحدة.

// build.gradle.kts

plugins {
   alias(libs.plugins.android.library)
   alias(libs.plugins.kotlin.compose)
}

val gitCommit = providers.exec {
   commandLine("git", "rev-parse", "--short", "HEAD")
}.standardOutput.asText.get().trim()

android {
   namespace = "com.example.app"
   compileSdk = 37

   defaultConfig {
       minSdk = 24
       buildConfigField("String", "GIT_COMMIT",
                        "\"$gitCommit\"")
   }
   buildFeatures {
        compose = true
        buildConfig = true
   }
}

dependencies {
  implementation(platform(libs.androidx.compose.bom))
  implementation(libs.androidx.compose.ui)
  implementation(libs.androidx.compose.ui.graphics)
  ...

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

لكي تعرف بيئة التطوير المتكاملة ما تؤول إليه هذه الإعدادات، يجب أن تشغّل النص البرمجي.

الآن، ألقِ نظرة على الملف على الجانب الأيسر من الشاشة.

هذه هي إعدادات Lightbuild لوحدة مشابهة.

# lightbuild.yaml

group: "com.example"
version: "1.0.0"

platform: android
type: library

android:
 namespace: "com.example.app"
 compileSdk:
   version:
     release:
       apiLevel: 37
 minSdk:
   version:
     release:
       apiLevel: 24
 dependencies:
   maven:
     - androidx.core:core-ktx:1.10.1
     - androidx.lifecycle:lifecycle-runtime-ktx:2.6.1
     - androidx.activity:activity-compose:1.8.0

هذا الملف هو بيانات تعريفية بحتة.

لا توجد تعريفات للمتغيرات المحلية، ولا توجد استدعاءات لدوال مساعدة مخصصة ولا توجد عبارات شرطية أو تعريفات مهام مضمنة.

ويوضّح بوضوح نوع الوحدة وأهداف حزمة SDK والتبعيات الخاصة بها.

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

مع أنّ الفصل بين الإعدادات والمنطق يُعدّ رائعًا لقابلية القراءة من قِبل المستخدمين، إلا أنّه أكثر تحوّلاً في سير العمل بمساعدة الوكلاء.

عندما يستخدم المطوّرون الوكلاء كجزء من سير العمل، يجب أن يتمكّن هؤلاء الوكلاء من قراءة إعدادات التصميم وتعديلها.

ومع ذلك، ليس لديهم طريقة لتوقّع الآثار الجانبية لتغيير الإعدادات إلا من خلال إنشاء المشروع فعليًا.

قد تتعارض إضافة سطر واحد إلى ملف إعداد مع متغيّر يتم احتسابه ديناميكيًا في مكان آخر في المشروع أو مع مكوّن إضافي تقليدي.

في Lightbuild، تكون إعدادات مشروعك عبارة عن رسم بياني ثابت للبيانات.

هذا يعني أنّ الوكلاء يمكنهم فحص هذا الرسم البياني وفهم بنية الوحدة وتعديلها باستخدام مخطط معروف.

يمكن للوكيل الاطّلاع على قائمة الوحدات وقائمة التبعيات وإصداراتها، وتعديل التبعيات أو حتى إضافة وحدة ميزات جديدة كليًا من خلال قراءة البيانات المنظَّمة وكتابتها.

فهي تجعل إعدادات مشروعك من الدرجة الأولى في ما يتعلّق بمهام سير العمل التي تتم بمساعدة الوكيل.

هناك تفصيل آخر أريد تسليط الضوء عليه في هذه المرحلة، وهو أنّ Lightbuild ليس مكوّنًا إضافيًا لنظام إنشاء، بل هو واجهة لمحرك الإنشاء.

يستخدم إصدار Lightbuild، وهو النسخة الحصرية التي نطلقها اليوم، Gradle في الخلفية كمحرّك تنفيذ.

ومع ذلك، فإنّ النهج البنيوي الذي اتبعناه مع Lightbuild يجعل "استوديو Android"، وهو بيئة التطوير المتكاملة (IDE)، يرى المشروع ويتعامل معه كمشروع Lightbuild.

لننتقل الآن إلى الركيزة الثانية، وهي إنتاجية المطوّرين وسير العمل: المزامنة السريعة لبيئة التطوير المتكاملة (IDE).

حتى مع استخدام المطوّرين للوكلاء كجزء من سير العمل، يظل Android Studio أداة أساسية للمهام التفاعلية، مثل مراجعة معاينات واجهة مستخدم Compose أو تتبُّع الرموز البرمجية في برنامج تصحيح الأخطاء كجزء من التحقيق في مشكلة، أو تحليل الأداء باستخدام أداة تحليل الأداء.

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

سواء كنت تفتح مشروعًا أو تعدّل ملف إصدار أو تبدّل الفروع، يمكن لبيئة التطوير المتكاملة معالجة هذه المعلومات بسرعة وتوجيهك مباشرةً إلى أدواتك.

ومن بين الأسباب التي تجعل هذه السرعة والموثوقية ممكنة هي الطريقة التي يتعامل بها Lightbuild مع التبعيات.

عادةً، عند الإعلان عن تبعية، يحتاج نظام الإصدار إلى المرور عبر شجرة من التبعيات الانتقالية لجمع معلومات الإصدار وحل التعارضات.

في Lightbuild، كلما تغيّرت التبعيات، تحسب الأداة تلقائيًا معلومات التبعية الانتقالية وتكتبها في ملف resolved.deps داخل كل دليل وحدة.

يؤدي ذلك إلى أنّه عند فتح المشروع مرة أخرى في المستقبل أو إعادة إنشائه، لن تحتاج بيئة التطوير المتكاملة (IDE) أو أداة الإنشاء إلى إعادة احتساب معلومات التبعية الانتقالية هذه.

ننصحك بإضافة هذه الملفات إلى نظام التحكّم بالمصادر، لكي يتمكّن زملاؤك في الفريق من الاطّلاع على أي تغييرات في معلومات التبعية الانتقالية عند إرسال التغييرات إليهم لمراجعتها، بالإضافة إلى أنّ أجهزتهم لن تحتاج إلى إعادة احتساب معلومات التبعية الانتقالية هذه.

بالإضافة إلى ذلك، من خلال التحقّق من هذه المعلومات في نظام التحكّم في المصدر، يمكنك أنت وأعضاء فريقك ومسارات CI/CD إنشاء إصدارات باستخدام إصدارات التبعيات نفسها في كل مرة.

يسرّنا الإعلان عن توفّر Lightbuild كنسخة مبكرة حصرية في إصدار Canary من "استوديو Android" وأيضًا من خلال أدوات CLI المستقلة.

يُرجى العِلم أنّ هذا الإصدار من Lightbuild تجريبي، لذا لا يتضمّن جميع الميزات التي تحتاج إليها لإنشاء تطبيق إنتاج وصيانته.

يُرجى مواصلة استخدام AGP وGradle في تطبيقات الإنتاج أثناء تجربة Lightbuild في المشاريع التجريبية والاختبارية.

يمكنك البدء اليوم من خلال الانتقال إلى goo.gle/lightbuild، ونتطلّع إلى تلقّي ملاحظاتك لمساعدتنا في تحسين المنتج أثناء تطويره.

والآن، سأترك الكلمة لـ "سكوت" ليعرض لكم Lightbuild أثناء العمل.

شكرًا لك يا خالد.

اسمي "سكوت مايرز".

أنا مهندس علاقات مطوّري برامج Android، وقد عملنا على Lightbuild لفترة من الوقت، ويسرّنا أن نوضّح لك كيف يمكنك استخدامها اليوم وتجربتها.

لذا، أول ما عليك فعله هو الانتقال إلى الرابط الذي ذكره خوان، goo.gle/lightbuild أو البحث عن Lightbuild.

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

وهناك أيضًا واجهة سطر أوامر Lightbuild التي يمكنك تثبيتها للاستفادة من تجربة الوكيل الكاملة مع Lightbuild.

بعد إعداد ذلك، كما فعلتُ هنا على جهازي، سأشغّل أحدث إصدار من Canary من "استوديو Android".

والآن، سأشرح لكم كيفية إنشاء مشروع Lightbuild تجريبي، وسأوضّح لكم كيف يمكنكم القيام بذلك اليوم.

لذا، سأنتقل أولاً إلى معالج "مشروع جديد" (New Project).

سأختار "نشاط فارغ" (Empty Activity)، ثم أنقر على "التالي" (Next).

والآن، ستظهر لك شاشة تفاصيل المشروع العادية، ولكن في أسفلها، هناك خيار جديد.

ضمن لغة إعدادات التصميم، يمكنك اختيار Lightbuild.

وستذكّرك بأنّ هذه الميزة تجريبية قبل النقر على "إنهاء".

وستلاحظون على الفور أنّ مشروعنا قد تمت مزامنته مع بيئة التطوير المتكاملة وأصبح جاهزًا للعمل.

لنلقِ نظرة الآن على بنية مشروع Lightbuild نموذجي.

هذا هو نموذج Android التلقائي الذي تحصل عليه عند إنشاء تطبيق جديد.

يقول فقط، "مرحبًا، أيها العالم!"

لذا، إنّها طريقة بسيطة للبدء.

وستلاحظون أنّه في المستوى الجذري لمشروعنا هنا، لدينا ملف باسم project.lightbuild.yaml.

يمنحنا هذا الإعدادات العامة لمشروعنا بأكمله.

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

لذا، نرى أنّ لدينا وحدتَين هنا، وهما app وapp-core.

وذلك لأنّ جميع مشاريع Lightbuild تحتوي على وحدتَين على الأقل.

وذلك لأنّه يجب أن تتضمّن وحدة تطبيق واحدة على الأقل ووحدة مكتبة واحدة على الأقل.

وسأشرح السبب بعد قليل.

لذا، لنلقِ نظرة أولاً على وحدة التطبيق هذه.

إذا وسّعتُه هنا، سيظهر لكم ملف lightbuild.yaml على مستوى الجذر للوحدة، وهو ملف ستحتوي عليه كل وحدة.

هنا، يحتوي على بعض المعلومات الأساسية.

نحن نعمل على نظام Android الأساسي، بالطبع.

وهذه الوحدة من نوع التطبيق.

يمكنك إدراج إصدارات حزمة SDK المستهدَفة ومعرّف التطبيق وما إلى ذلك، ثم إدراج جميع الوحدات التي تعتمد عليها وحدة التطبيق هذه.

الآن، ما يثير الاهتمام في وحدة التطبيق هذه والتي تختلف قليلاً عن قالب Android العادي هو أنه لا يوجد شيء في مجلد المصدر.

لذلك، في Lightbuild، لا تحتوي وحدات التطبيق على أي رمز مصدر.

والسبب في ذلك هو أنّ وحدة التطبيق هذه لن تتغيّر كثيرًا، ولكنّها تستغرق بعض الوقت لإنشائها.

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

بعد ذلك، لنلقِ نظرة على وحدة app-core، وهي وحدة المكتبة التي تعتمد عليها وحدة التطبيق هذه.

ويمكنك أن ترى أن هذه الوحدة تحتوي بالفعل على رمز مصدر فيها.

يحتوي على المنطق الرئيسي هنا.

يقول فقط، "مرحبًا، أيها العالم!"

وإذا ألقيتُ نظرة على ملف lightbuild.yaml في هذه الوحدة، يمكنني ملاحظة أنّه من نوع المكتبة.

وهنا أيضًا يتم ضبط بعض أرقام إصدارات حزمة SDK، ولكن يتم إدراج جميع الملحقات الخارجية التي لدينا ضمن هذه الوحدة.

ويتم أيضًا تحديد اختبارات الوحدات واختبارات قياس حالة التطبيق.

بعد ذلك، لنلقِ نظرة على ملف آخر ربما لاحظته هنا، وقد تحدث "خوان" قليلاً عن هذا، هناك ملف resolved.deps داخل كل وحدة.

وهذا ملف يتم إنشاؤه تلقائيًا بواسطة Lightbuild.

هذا يعني أنّه لا يجب تعديله يدويًا، ولكنّه سيحتوي على قائمة بجميع التبعيات التي تم حلّها ضمن هذه الوحدة.

وبالتالي، ستكون جميع التبعيات والتبعيات الانتقالية متوفّرة هنا.

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

لنلقِ نظرة الآن على مثال يوضّح كيف يحسّن Lightbuild تجربة المطوّرين من خلال مزامنة المشاريع.

الآن، عدت إلى مستوى الجذر project.lightbuild.yaml، والإعدادات العامة هنا التي تسرد جميع الوحدات في تطبيقي.

وعادةً، عند تعديل ملفات الإعدادات أو إعدادات التصميم، سيظهر زر مزامنة يستغرق بعض الوقت لمعالجة كل هذه الملفات بسبب العمليات التي كان يصفها "خوان"، حيث يتعيّن عليه إجراء تصميم جزئي من خلال تنفيذ جميع نصوص التصميم البرمجية ثم مزامنة هذا النموذج مع بيئة التطوير المتكاملة.

لذلك، لنجرِ تغييرًا كبيرًا إلى حد ما في هذا المشروع الصغير.

سنحذف إحدى الوحدات فقط.

ويمكنك أن ترى أن هذه الوحدة، قبل أن أضغط على زر الحفظ، يتم التعرف عليها بواسطة IDE لأنه يمكنك معرفة أنها غامقة هنا.

لقد تعرّف على دليل ملفات المصدر وأدلة الاختبار.

وبمجرد أن أضغط على حفظ، بعد أن أجريت هذا التغيير، يمكنك أن ترى أن هذه الوحدة قد اختفت على الفور من المشروع.

وإذا تراجعتُ عن هذا التغيير مرة أخرى وضغطتُ على "حفظ"، سيعود النص كما كان بالسرعة نفسها.

هذا مثال على المزامنة السريعة لـ IDE التي يوفّرها Lightbuild لمشاريعك.

بالإضافة إلى ذلك، يمكنك تنفيذ جميع الأوامر العادية التي اعتدت عليها في "استوديو Android".

يمكنك الضغط على زر التشغيل.

سيتم تجميع تطبيقك وتشغيله هنا.

هذا التطبيق التجريبي ليس كبيرًا جدًا، ولكنني سأقوم بالتكبير لإظهار أنه يقول مرحبًا Android.

يمكنك إجراء اختباراتك كالمعتاد من خلال الانتقال إلى ملف الاختبار وتشغيله من الهامش على النحو التالي.

ويتم استدعاء Lightbuild هنا وراء الكواليس لإجراء هذه الاختبارات.

وبالتالي، يعمل كل هذا على النحو المتوقّع.

بعد ذلك، أريد أن أوضّح كيفية استخدام Lightbuild إذا لم تكن تستخدم استوديو Android، أو إذا كنت تستخدم سير عمل آخر يستند إلى الذكاء الاصطناعي الوكيل.

ولهذا، لدينا سطر الأوامر.

لذا، في واجهة سطر الأوامر في Lightbuild، سأشغّل أمر المساعدة الأساسي.

ونعم، كل الأخطاء الإملائية التي تراها في هذا المشروع اليوم هي أخطائي.

لذا، سيتضمّن Lightbuild عدة أوامر مختلفة مضمّنة فيه، مثل "عذرًا، أنا أشغّل هذا الأمر خارج المشروع".

يستمر في إخباري بذلك.

نعم، عرض توضيحي مباشر.

لذا، قبل تشغيل أي أوامر في Lightbuild، سأقوم بإنشاء مشروع Lightbuild.

لذلك، سأستخدم android create، وهي أداة سطر الأوامر العادية لإنشاء نماذج مشاريع جديدة.

سأستخدم نموذج empty-activity-lightbuild وأسمّي تطبيقي Lightbuild Demo، وأضعه في دليل مخرجات العرض التوضيحي.

حسنًا، إذا دخلتُ الآن إلى هذا الدليل وكتبتُ lightbuild -h، ستظهر لي جميع الأوامر المختلفة المتاحة في Lightbuild.

لدينا الكثير من المهام التي تتوقعها: الإنشاء والتنظيف والاختبار.

ولكن هناك بعض الميزات الجديدة.

هناك أمر resolve، الذي ينفّذ فعليًا تبعيات مشروعك وينشئ ملفات resolved.deps التي عرضتها سابقًا.

وهناك أمر طلب يتيح لك وللوكلاء فهم بنية مشروعك بشكل أفضل.

لذا، أولاً، لماذا لا أستعرض أمر الاستعلام الجديد هذا؟

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

ولكن هذا لا يخبرني كثيرًا عن كيفية تخطيط مشروعي.

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

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

لذلك، يحتوي على حِزم APK وAAB لكل من ملفات تصحيح الأخطاء والإصدارات الثنائية.

وإذا قمت بتشغيل هدف التطبيق فقط، فسيتم إنشاء كل شيء.

ويمكن أيضًا تحديد الناتج بتنسيق JSON.

وبهذه الطريقة، عذرًا.

مرة أخرى، كل أخطائي الإملائية حقيقية اليوم.

سأستخدم المساعدة التفاعلية في Lightbuild للتأكّد من أنّني أنفّذ هذه الخطوات بشكل صحيح.

همم…

نعم، من المفترض أن يعمل.

حسنًا.

إذا كان بإمكان أي شخص إخباري بما أفعله بشكل خاطئ، فتحدث معي بعد هذا الحديث.

بدلاً من هذا الجدول، يمكنك أيضًا إخراج أوامر Lightbuild بتنسيق JSON، وهو أسهل لوكلائك.

‫--format json…

أقصد التنسيق.

عذرًا.

شكرًا لك.

هذه ملاحظات مباشرة من المطوّرين.

شكرًا لك.

حسنًا، نعم، وهناك أيضًا أمر الإخراج الذي يمكنني أيضًا عرضه، ربما بمساعدتك.

لذا، إذا أخرجت الملفات بدلاً من الأهداف، فسيظهر لي مواقع جميع الملفات الثنائية المختلفة داخل الإصدار.

هذه طريقة تتيح لك وللوكلاء استكشاف مشروعك وفهمه بشكل أفضل من سطر الأوامر باستخدام Lightbuild.

بعد ذلك، هناك أمر lightbuild resolve الذي ذكرته سابقًا، والذي سينشئ جميع ملفات resolved.deps.

يحتوي هذا أيضًا على بعض الميزات الإضافية فيه.

على سبيل المثال، هناك مَعلمة التبعيات المقفلة، وبذلك، بدلاً من إنشاء هذه الملفات فقط، ستقارن في الواقع محتوى الملفات بالتبعيات التي أعلنت عنها في إعدادات التصميم.

وإذا كانت هناك أي اختلافات، فسيتم إعلامك بذلك، وستفشل عملية الإنشاء.

بهذه الطريقة، يمكن أن تعمل ملفات التبعيات التي تم حلّها كملفات قفل، على سبيل المثال، إذا كنت تنشئ تطبيقك في نظام CI/CD للإنتاج، فستحتاج إلى معرفة ما إذا كانت أي تبعيات تتغير أثناء هذا الإصدار.

لنتعرّف أيضًا على ميزة الاختبار المضمّنة في Lightbuild، ويمكنك أيضًا تشغيل جميع الاختبارات ضمن وحدة المكتبة هذه، على سبيل المثال، مباشرةً من سطر الأوامر.

وهناك أمر آخر أريد عرضه.

بل إنّها توفّر أيضًا المساعدة التي ستمنحك قائمة كاملة بجميع المعلمات والأوامر الفرعية التي يمكنك استخدامها.

هذا متاح لوكيلك، لذا فهذه هي النتيجة للوكيل.

حسنًا.

بعد أن رأينا بعض المشاريع البسيطة باستخدام Lightbuild، أريد أن أعرض لكم مشروعًا أكثر طموحًا.

لدينا نموذج تطبيق يوفّره فريق Android باسم Now in Android، ويقدّم لك بعضًا من أحدث ميزات Android، ويوضّح لك كيفية استخدامها، ويعرض بعض أفضل الممارسات.

وهو تطبيق معياري للغاية.

وهي مقسّمة إلى 32 وحدة مختلفة تقريبًا.

هذا هو الشكل الذي يظهر به في GitHub.

سأعود إلى استوديو Android، حيث استخدمت الوكيل مسبقًا.

كنت أستخدم Gemini Argon لتحويل مشروع Android Now in Android إلى Lightbuild.

هذا ليس شيئًا نشرناه، هذا مجرد شيء فعلته بمفردي.

ويمكنكم ملاحظة أنّه على الرغم من أنّ هذا المشروع في project.lightbuild.yaml يحتوي على كل هذه الوحدات المختلفة، إلا أنّه لا يزال يفتح بسرعة مذهلة، وتتم مزامنته مع بيئة التطوير المتكاملة هذه بطريقة سريعة جدًا.

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

سيستخدم الإصدار التجريبي مصادر بيانات مدمجة، بينما يتصل الإصدار الإنتاجي بالشبكة ويسحب البيانات.

ولتنفيذ ذلك باستخدام Lightbuild، فإنّ الطريقة التي يتعامل بها مع أشياء مثل إعدادات التصميم المختلفة أو صيغ المنتجات، هي الانتقال إلى وحدة التطبيق وتحديد أنّ هذه الوحدة هي، على سبيل المثال، التطبيق التجريبي.

وبالتالي، سيعتمد على جميع المكوّنات الأساسية، ولكنّه سيستعين أيضًا بإعدادات خاصة لإصدار التطبيق التجريبي فقط.

بهذه الطريقة، يمكنك الحصول على وحدات تطبيق متعددة.

ويمكن أن يمثّل كل منها، على سبيل المثال، إصدارًا مدفوعًا أو مجانيًا من تطبيقك.

وستظل تستفيد من وحدة التطبيق باعتبارها غلافًا فارغًا لا يحتوي على رمز برمجي يتم إنشاؤه بشكل أسرع، وكلما تغيرت مكتباتك، يجب إعادة تجميعها فقط من أجل إنشاء تطبيقك مرة أخرى.

لنلقِ نظرة على ما إذا كان تطبيق Android Now in Android يتم إنشاؤه بنجاح باستخدام Lightbuild مع جميع وحداته المختلفة البالغ عددها 32 وحدة.

نعم، ها هو ذا.

أودّ الإشارة إلى أنّنا تعلّمنا من إجراء تجارب كهذه أنّ Lightbuild لا يتيح دائمًا كل ميزات الإنشاء التي قد تحتاج إليها.

على سبيل المثال، يعتمد تطبيق Now in Android على مكوّن Hilt الإضافي لاستخدام Hilt، ولا يتيح Lightbuild هذا النوع من الميزات بعد.

لذلك، تمكّن الوكيل من إيجاد حل بديل، والحصول على دعم Hilt بدون تغيير الكثير من الرموز البرمجية في المشروع نفسه.

مثلاً، كل الرموز البرمجية في كل هذه الوحدات هي نفسها الموجودة في المستودع الأصلي.

ولكن هذا أمر يجب وضعه في الاعتبار بالتأكيد عند تجربة Lightbuild وعرضه بنفسك، وهو أنّه لن يتم توفير كل شيء في مشروعك الحالي من حيث إعدادات التصميم.

لهذا السبب، لا يزال Lightbuild في مرحلة المعاينة، ولا يزال في إصدار Canary من "استوديو Android".

والآن، أودّ العودة إلى الشرائح.

ولتلخيص كل ما تحدّثنا عنه هنا، تذكَّروا أنّ Lightbuild هي منصة جديدة لإنشاء تطبيقات Android، وهي تجريبية في الوقت الحالي.

وتتضمّن إعدادات تصميم توضيحية، لذا لن يتم تشغيل أي رمز برمجي قابل للتنفيذ في إعدادات التصميم، ما يتيح لك الاستفادة من الكثير من الميزات الرائعة، مثل المزامنة السريعة مع IDE وعمليات التصميم الأكثر كفاءة.

فهو يوفّر دعمًا من الدرجة الأولى لوكلاء الذكاء الاصطناعي، وفي سطر الأوامر، يتضمّن كل الميزات التي ساعدتني في عرضها اليوم.

لذلك، ندعوك إلى تجربته واستخدامه في المشاريع التجريبية.

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

شكرًا جزيلاً.