عمل أصلي على أندرويد بنطاق واضح
لا ينبغي أن يتحوّل مسار جديد للحسابات، أو تخطيط للأجهزة اللوحية، أو خطأ في حالة الشاشة تلقائيًا إلى مشروع لإعادة كتابة التطبيق كله.
نبدأ بتحديد مسؤولية الميزة، ومصدر بياناتها، والسلوك القائم الذي يجب الحفاظ عليه. بذلك يصبح للعمل حدّ واضح يمكن اختباره ومراجعته.
إذا كنت تريد بناء منتج كامل لا مهمة تخص إطار عمل بعينه، فراجع تطوير تطبيقات أندرويد المخصّصة.
أين يناسب Kotlin وCompose؟
Jetpack Compose مجموعة أدوات واجهات أندرويد الحديثة الموصى بها، وتستخدم واجهات Kotlin البرمجية. تفيد في بناء الواجهات الأصلية الجديدة، ويمكنها العمل إلى جانب الشاشات المبنية بنظام Views في التطبيق القائم.
استخدام Compose وحده لا يجعل التطبيق منظّمًا. ما زالت حالة الواجهة والعمل غير المتزامن والتعامل مع الأخطاء والتنقل تحتاج إلى تصميم واعٍ. الأداة جزء من الحل، وليست بديلًا عن فهم التطبيق.
أعمال تطوير يمكن تحديد نطاقها
ميزات وشاشات جديدة
تنفيذ مسارات استخدام محدّدة وربط الشاشات بمصادر البيانات القائمة، مع حالات ما قبل العملية وأثناءها وبعدها. ينبغي أن تميّز الاستمارة، مثلًا، بين خطأ الإدخال والطلب الجاري والاستجابة الفاشلة.
اعتماد Compose في التطبيقات القائمة
نختار الشاشات أو المكوّنات المناسبة للانتقال، ونحافظ على الوظائف العاملة، ونحدّد الحد الفاصل بين Compose وViews. غالبًا ما يسهل التحقق من تغيير تدريجي مقارنةً باستبدال الواجهة كلها.
الانتقال من Java إلى Kotlin
نراجع الوحدات التي تستفيد من الانتقال وتلك التي يمكن إبقاؤها مستقرة. الهدف الحفاظ على السلوك وتحسين قابلية الصيانة حيث توجد حاجة فعلية، لا مجرد تبديل صياغة الشيفرة.
الأداء ودورة حياة التطبيق
نفحص بطء الشاشات والعمل الزائد وفقدان الحالة أو تغيّر السلوك بعد انتقال التطبيق إلى الخلفية. نعيد إنتاج المشكلة على نسخة وجهاز محدّدين قبل اختيار التحسين المناسب.
تخطيطات متكيّفة وإمكانية الوصول
نحدّد التخطيطات لأحجام الأجهزة المهمة لمستخدميك، بما يشمل النص المكبّر ولوحة المفاتيح والتقنيات المساعدة عند الحاجة. تمديد الشاشة وحده لا يوفّر بالضرورة تجربة جيدة على الجهاز اللوحي.
ما الذي ينبغي أن يتضمنه التسليم؟
ينبغي أن يصل التغيير المتفق عليه مع سياق يكفي مطوّرًا آخر لفهم ما تغيّر، ولماذا، وكيف يبني التطبيق، وما الذي اختُبر.
قد تشمل المخرجات، بحسب النطاق، تعديلات الشيفرة واختبارات آلية مركّزة ونسخة تجريبية وملاحظات الانتقال وقائمة بالقيود المعروفة. نراعي أعراف مستودع العميل ما لم يُتفق على تعديل محدّد.
لا توضع مفاتيح التوقيع وبيانات الإنتاج السرّية داخل مستودع الشيفرة أو نموذج الطلب الأولي.
كيف نتجنب إعادة كتابة لا لزوم لها؟
نفصل مشكلة التطبيق الفعلية عن عمر أدواته. قد تكون وحدة Java مستقرة أقل إلحاحًا من شاشة Kotlin جديدة تُدار حالتها على نحو غير موثوق. وقد يلزم تحديث البناء من غير نقل الواجهة إلى Compose.
تجيب المراجعة عن ثلاثة أسئلة: ما الذي يمنع التغيير المطلوب؟ وما الذي يمكن إبقاؤه؟ وأي اختبارات تثبت أن المستخدمين الحاليين لم يفقدوا وظائف مهمة؟
إذا كانت المشكلة المباشرة انهيار التطبيق أو فشل البناء، فابدأ بخدمة تصحيح أخطاء تطبيقات أندرويد.
Kotlin وFlutter والشيفرة القائمة
Kotlin خيار طبيعي للعمل المركّز على أندرويد. أما تطوير Flutter فهو خيار آخر عندما تكون مشاركة شيفرة التطبيق بين أندرويد وiOS مطلبًا مهمًا.
قد يحتاج مشروع Flutter أيضًا إلى Kotlin لتنفيذ تكامل خاص بأندرويد. نقيم هذا الحد الفاصل دون افتراض ضرورة نقل التطبيق كله إلى التطوير الأصلي.
أسئلة شائعة
هل تعملون مع تخطيطات XML بدل Compose؟
نعم. يحدّد التطبيق الحالي والتغيير المطلوب النهج المناسب. الانتقال إلى Compose ليس شرطًا للصيانة أو إضافة الميزات.
هل يمكن نقل جزء من التطبيق فقط إلى Compose؟
نعم. يمكن أن تتعايش واجهات Compose وViews. يحتاج الانتقال إلى حدود واضحة وفحوص للتنقل والحالة والمكوّنات المشتركة.
هل تعتمدون أحدث إصدار من كل مكتبة تلقائيًا؟
لا. يعتمد اختيار الإصدارات على التوافق والاستقرار والاحتياجات الأمنية والبناء الحالي. لا يكفي كون الإصدار الأحدث متاحًا لتبرير انتقال غير متعلق بالعمل.
هل يمكنكم تحسين تطبيق Kotlin غير مكتمل؟
نعم، رهناً بمراجعة الشيفرة وتوفّر الصلاحيات اللازمة. نتحقق أولًا من إمكانية بنائه، وما يعمل منه، وما يلزم للوصول إلى مرحلة محدّدة.
هل يمكن أن يشمل العمل تكامل Kotlin لتطبيق Flutter؟
نعم. صف API الخاص بأندرويد أو SDK المورّد. يمكن عندها تحديد نطاق طبقة Flutter المشتركة والتنفيذ الأصلي لأندرويد معًا.
شاركنا الميزة أو الانتقال أو الشاشة الصعبة
صف النتيجة المطلوبة والتطبيق الحالي بإيجاز. يمكن ترتيب الوصول إلى المستودع بعد وضوح النطاق وشروط الوصول.