منذ أن أعلنت Google عن دعم رسمي لـ Kotlin على Android ، يرغب المزيد والمزيد من المطورين في استخدامه في مشاريعهم الجديدة والحالية. نظرًا لأنني من كبار المعجبين بـ Kotlin ، لم أستطع الانتظار حتى أتمكن من استخدام Kotlin في مشروع عملي. في النهاية ، Kotlin متوافق تمامًا مع Java ، وجميع المطورين سعداء به. إذن ما الذي يمكن أن يحدث خطأ؟
حسنًا ، في الواقع يمكن أن يحدث الكثير من الخطأ. أخشى للتو أن صفحة توثيق Android الرسمية "الشروع في العمل مع Kotlin" تقول أنه إذا كنت ترغب في نقل تطبيق موجود إلى Kotlin ، فعليك فقط البدء في كتابة اختبارات الوحدة ، وبعد ذلك ، بعد تجربة بسيطة مع هذه اللغة ، يجب عليك كتابة كود جديد في Kotlin ، ويسهل تحويل كود Java الحالي.
في هذه المقالة ، سأخبرك بما سيحدث إذا قررت اتباع هذه الاستراتيجية على الفور في حث المنتج ، وعدم تجربتها في مشروعي الصغير.
تلبية مشروعي الصغير
كان لدي مشروع أنشأته قبل أكثر من عام في جافا ، وكنت بحاجة إلى تغييره قليلاً وإضافة شاشة جديدة واحدة. اعتقدت أن هذه كانت فرصة رائعة للتحقق مما إذا كانت عملية نقل مشروع موجود إلى Kotlin بسيطة للغاية حقًا ، كما يقول الجميع. بناءً على توصيات الوثائق الرسمية ، بدأت بكتابة اختبارات الوحدة على Kotlin. كتبت أيضًا دروسًا جديدة في Kotlin وقمت بتحويل بعض الفصول الموجودة. بدا كل شيء رائعًا ، ولكن بعد فترة اكتشفت مشكلة واحدة غير سارة.
كوتلن + لومبوك = :(
في تطبيقي ، استخدمت مكتبة لومبوك لإنشاء الرسائل والمستوطنين. لومبوك هو معالج تعليقات جافا سكريبت. لسوء الحظ ، يستخدم مترجم kotlin javac دون معالجة التعليقات التوضيحية [المصدر] . هذا يعني أن الطرق التي تم إنشاؤها باستخدام Lombok لن تكون متاحة في Kotlin:
ولكن يمكنك أن تقول: "حسنًا ، لن يكون الأمر رائعًا جدًا ، ولكن من حيث المبدأ ، يمكنك إنشاء حروف ومستوطنين يدويًا لتلك الحقول التي ستكون مطلوبة في كود Kotlin. في النهاية ، لا تحتاج إلى القيام بذلك في المشروع بأكمله على الفور ".
فكرت بنفس الطريقة. لكني واجهت مشكلة حقيقية عندما أردت إضافة شاشة جديدة إلى التطبيق.
Kotlin + Lombok + Dagger 2 =: (((
يستخدم تطبيقي Dagger 2 لإدخال التبعيات. عند إنشاء شاشة جديدة ، أقوم عادةً بإنشاء بنية MVP: النشاط والمقدم والمكون والوحدة والعقد. يتم تنفيذ جميع التبعيات للمقدم باستخدام Dagger. يستدعي النشاط DaggerSomeComponent.builder().(...).build().inject(this) لحقن المقدِّم DaggerSomeComponent.builder().(...).build().inject(this) اللازمة.
لا يعد استخدام Dagger 2 مع Kotlin مشكلة. قبل ذلك مباشرةً ، تحتاج إلى تطبيق المكوّن الإضافي kapt ، الذي ينشئ الفئات الضرورية التي تم إنشاؤها ذاتيًا لـ Dagger.
وهنا يبدأ كل شيء بالانهيار
بدون المكوّن الإضافي kapt ، لم أتمكن من استخدام فئات Dagger التي تم إنشاؤها في ملفات Kotlin. ولكن بعد أن أضفت هذا البرنامج المساعد ، اختفت جميع الطرق التي أنشأها لومبوك!
قبل تطبيق البرنامج المساعد kapt :
بعد تطبيق البرنامج المساعد kapt :
وللأسف ، لا يوجد حل لهذه المشكلة. يمكنك استخدام إما kapt-plugin أو فقط Lombok . لحسن الحظ ، نظرًا لأنه كان مجرد مشروعي الصغير ، فقد قمت ببساطة بحذف لومبوك وكتبت الرسائل والمستوطنين بنفسي. ولكن في هذا المشروع لم يكن هناك سوى حوالي 50 طريقة ولدت. في المشروع الذي ندعمه في العمل ، لدينا حوالي ألف منهم . إزالة لومبوك من هذا التطبيق ببساطة غير ممكن.
من الواضح أيضًا أن التخلي عن المكوّن الإضافي kapt ليس هو المخرج. بدونها ، لا يمكنك استخدام Kotlin في الفصول حيث يتم استخدام Dagger. في حالتي ، سيتعين علي تنفيذ النشاط والمكون والوحدة في Java ، ويمكن كتابة العقد والعرض فقط في Kotlin. من المؤكد أن خلط ملفات Java و Kotlin ليس رائعًا. بدلاً من الانتقال السلس من Java إلى Kotlin ، يمكنك ببساطة إنشاء فوضى كبيرة.
هذا ما سيبدو عليه هيكل MVP متعدد اللغات الرهيب بدون مكون إضافي:
ولكن ما زلت أريد التحول إلى Kotlin. ماذا افعل؟
طريقة واحدة هي استخدام وحدات مختلفة . لن يرى Kotlin الطرق التي سيولدها لومبوك في شفرة المصدر ، ولكنه سيراها في الرمز الثانوي.
شخصيا ، يبدو لي أن هذه هي الطريقة المفضلة. إذا وضعت Kotlin في وحدات تابعة منفصلة لكل ميزة ، فإنك تقلل من خطر مشكلات التوافق التي واجهتها ، أو تلك الأكثر تعقيدًا المدرجة في الدليل الرسمي .
وهذا ليس كل شيء. هناك العديد من العيوب الأخرى لخلط ملفات Kotlin و Java بدون فصل واضح. وهذا يجعل جميع المطورين الذين يعملون معك في المشروع يعرفون اللغتين. كما أنه يقلل من إمكانية قراءة التعليمات البرمجية ويمكن أن يؤدي إلى زيادة وقت البناء [المصدر] .
باختصار
- الأساليب التي تم إنشاؤها بواسطة Lombok غير مرئية في Kotlin ؛
- باستخدام البرنامج المساعد kapt يكسر لومبوك ؛
- بدون مكون إضافي kapt ، لا يمكنك استخدام فئات ذاتية الإنشاء لـ Dagger في Kotlin ، مما يعني أنه لا يزال عليك كتابة رمز Java جديد ؛
- طريقة لحل هذه المشكلة هي إدخال Kotlin في وحدات منفصلة ؛
- يمكن أن يؤدي خلط ملفات Kotlin و Java في المشاريع الكبيرة دون فصل واضح إلى مشكلات توافق غير متوقعة.