النظر في نظام مشروع أندرويد

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

4 مزايا النمذجة

قبل اتخاذ قرار بشأن نظام الوحدات ، من الجيد أن تكون واضحًا بشأن ما ينطوي عليه ذلك بالضبط. تشمل مزايا هيكل مشروع android المعياري ما يلي:

عزل أفضل للكود

يمكن لكل وحدة عرض واجهات API العامة وإخفاء تفاصيل التنفيذ. باستخدام وحدة واحدة ، لا يمكنك التأكد تمامًا من أن تنفيذها مخفي جيدًا (خاصة في Kotlin ، حيث لا يتوفر معدل رؤية الحزمة).

أسهل تقييم للتكنولوجيا الجديدة

عند إنشاء وحدة نمطية ، يمكنك التحقق من نمط العمارة الجديد أو المكتبة الجديدة دون التأثير على الوحدات النمطية الأخرى.

تقليل وقت بناء المشروع

يتطلب تعديل وحدة نمطية إعادة بناء تلك الوحدة والوحدات الأخرى التي تعتمد عليها. شاهد بالضبط كيف يعمل من خلال قراءة هذه الوثائق: مطورو Android. تكوينات التبعية

عمل أكثر ملاءمة

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

تبدو هذه الفوائد كافية لإقناعك ببدء عملية التشكيل المعياري ، ولكن كيف تبدأ؟

# 1: حدد الوحدات النمطية الخاصة بك وعلاقاتها

هناك طريقتان للتعرف على الوحدات النمطية الخاصة بك: حسب الميزة والطبقة.

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

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

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

مع الأخذ في الاعتبار التعريفات المذكورة أعلاه ، يمكن أن يبدو التسلسل الهرمي للوحدات كما يلي:

رقم 2: إعداد حقن التبعية

على الرغم من التبعيات بين وحدات المشروع ، يجب عليك أيضًا إعداد تبعيات الخنجر. يقدم Dagger طريقتين للإعلان عن التبعية: المكونات الفرعية والاعتماد على المكون .

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

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

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

يتم عرض إعداد تبعية وحدة المشروع لإدارة التبعية الأفقية في الصورة أدناه:

يتم توفير رمز مثال لمثل هذه العلاقات في مشروع في نهاية المقال.

# 3: إعداد Gradle

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

تم العثور على مقتطف الشفرة لهذا الإعداد الشائع هنا:

 afterEvaluate { project -> def isAndroid = project.plugins.hasPlugin('com.android.library') || project.plugins.hasPlugin('com.android.application') setupModule(isAndroid) setupCommonTestDependencies(isAndroid) setupCommonTasks(isAndroid) } def setupModule(isAndroid) { if (isAndroid) { android { compileSdkVersion projectCompileSdk defaultConfig { minSdkVersion projectMinSdk targetSdkVersion projectTargetSdk } compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } lintOptions { abortOnError true checkReleaseBuilds false checkAllWarnings true warningsAsErrors true def lintBaseline = file("quality/lint-baseline.xml") if (lintBaseline.exists()) baseline lintBaseline } } } else { sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } } def setupCommonTestDependencies(isAndroid) { dependencies { testImplementation "junit:junit:${junitVersion}" testImplementation "org.assertj:assertj-core:${assertJVersion}" testImplementation "org.mockito:mockito-core:${mockitoVersion}" testImplementation "com.nhaarman.mockitokotlin2:mockito-kotlin:${mockitoKotlinVersion}" if (isAndroid) { androidTestImplementation "androidx.test.ext:junit:${axTestJUnitVersion}" androidTestImplementation "androidx.test.espresso:espresso-core:${axEspressoLibVersion}" } } } def setupCommonTasks(isAndroid) { if (isAndroid) { tasks.register("unitTest") { task -> task.dependsOn(testDebugUnitTest) } } else { tasks.register("unitTest") { task -> task.dependsOn(test) } } }

استنتاج

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

تم العثور على جزء من التعليمات البرمجية لعرض التبعية الأفقية على الرابط.

هل تريد إنشاء تطبيق أصلي لنظام Android؟ اختر M Liquido!