إدارة التبعية في مشروع متعدد الوحدات على البرد

دخول

تمت كتابة المقال مع الانتباه إلى مشاريع android الأصلية ، ولكن نظرًا لأن gradle هو نظام تجميع عالمي ، فمن حيث المبدأ ، سيكون مناسبًا للمشاريع الأخرى التي يمكن لـ gradle جمعها. الفكرة ليست لي ، فأخذتها من مشروع جيثب لجيك وارتون SdkSearch - مجموعة من البرامج للبحث في الوثائق عن android sdk.

المشكلة

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

قرار

مع وجود الكثير من التبعيات ، من المهم جدًا أن تعتمد جميع الوحدات النمطية على إصدار واحد من المكتبة ، وإلا ستظهر المفاجآت في وقت التشغيل في أكثر الأماكن غير المتوقعة.
يستخدم Gradle groovy كلغة نصية ، والتي ، إلى جانب الكتابة الديناميكية ، توفر طريقة ملائمة لتنظيم إدارة التبعية.

في تقدير DSL ، يمكنك إضافة خصائص إلى المشروع باستخدام كائن ext ExtraPropertiesExtension . أيضًا ، داخل البرنامج النصي للوحدة النمطية ، يمكنك الوصول إلى البرنامج النصي للمشروع (الوحدة النمطية للجذر) ، والذي يسمح لك بالإعلان عن جميع إصدارات التبعيات في البرنامج النصي الجذر ، ويمكنك بالفعل الرجوع إليها من أي وحدة بالداخل.

على سبيل المثال ، دع تطبيق android الخاص بنا يستخدم التبعيات: kotlin ، kotlin stdlib ، kotlin junit ، facebook sdk ، androidx ، google material

بناء الجذر.

buildscript { ext { versions = [ 'kotlin': '1.3.50', 'fb': '4.40.0' ] deps = [ 'kotlin': [ 'stdlib': [ 'jdk': "org.jetbrains.kotlin:kotlin-stdlib-jdk7:${versions.kotlin}" ], 'test': [ 'common': "org.jetbrains.kotlin:kotlin-test-common:${versions.kotlin}", 'annotations': "org.jetbrains.kotlin:kotlin-test-annotations-common:${versions.kotlin}", 'jdk': "org.jetbrains.kotlin:kotlin-test-junit:${versions.kotlin}" ] ], 'androidx' : [ 'annotation': "androidx.annotation:annotation:1.1.0", 'appCompat': 'androidx.appcompat:appcompat:1.1.0', 'constraintLayout': 'androidx.constraintlayout:constraintlayout:1.1.3', 'ktx': 'androidx.core:core-ktx:1.1.0', 'dynamicAnimation': 'androidx.dynamicanimation:dynamicanimation:1.0.0', 'gridLayout': 'androidx.gridlayout:gridlayout:1.0.0', 'localBroadcastManager': 'androidx.localbroadcastmanager:localbroadcastmanager:1.0.0', 'multidex': 'androidx.multidex:multidex:2.0.1', 'recyclerView': 'androidx.recyclerview:recyclerview:1.1.0-beta04' ], 'material': 'com.google.android.material:material:1.0.0', 'fb': [ 'core': "com.facebook.android:facebook-core:${versions.fb}", 'login': "com.facebook.android:facebook-login:${versions.fb}", 'share': "com.facebook.android:facebook-share:${versions.fb}" ] ] repositories { google() jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.6.0-alpha11' classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:${versions.kotlin}" } } 

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

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

مثال على قسم تبعيات الوحدة النمطية في build.gradle

 dependencies { implementation deps.kotlin.stdlib.jdk implementation deps.androidx.appCompat implementation deps.androidx.browser implementation deps.androidx.cardView implementation deps.androidx.constraintLayout implementation deps.androidx.ktx implementation deps.androidx.multidex implementation deps.androidx.recyclerView implementation deps.material implementation deps.fb.core implementation deps.fb.login implementation deps.fb.share testImplementation deps.kotlin.test.jdk } 

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

كما ذكرت أعلاه ، مسودة العمل باستخدام مثل هذا المخطط هنا .