إذا كنت معتادًا على استخدام واجهات المستخدم التقليدية في نظام أندرويد، فربما تكون قد تعاملت مع معرّفات XML واستدعت دوالًا مثل `setText` لتحديث الشاشة. أما في بيئة Jetpack Compose، فالنهج مختلف تمامًا: هنا، تُعتبر واجهة المستخدم دالةً للحالة . هذا يعني أننا لا نُجري تغييرات يدوية على الواجهة؛ بل نُحدد شكل التطبيق بناءً على البيانات الحالية، ونترك للإطار البرمجي مهمة القيام بالباقي.
قد يتطلب التعود على هذا الأسلوب التصريحي بعض الممارسة في البداية، ولكن بمجرد إتقانه، ستدرك أنه أكثر سلاسة. يكمن السر في فهم أن الحالة هي أي قيمة قابلة للتغيير بمرور الوقت ، بدءًا من عداد الإعجابات البسيط وصولًا إلى قاعدة بيانات Room المعقدة، وأن واجهة المستخدم تتفاعل مع هذه التغييرات بشكل تلقائي.
جوهر التفاعلية: mutableStateOf
لإخبار Compose بأنه بحاجة إلى إعادة رسم جزء من الشاشة، لا يكفي استخدام متغير Kotlin عادي . نحتاج إلى شيء يمكن للنظام "مراقبته". هنا يأتي دور `mutableStateOf`، حيث يُنشئ حاوية قابلة للمراقبة . عندما تتغير القيمة داخل هذه الحاوية، يُعلّم Compose جميع الدوال التي تقرأ تلك القيمة بأنها "غير صالحة" ويبدأ عملية إعادة الرسم.
توجد عدة طرق لتعريف هذه الحالات لجعل الكود أكثر وضوحًا. يمكننا استخدام صيغة تفويض الخاصية مع عامل التشغيل 'by' ، مما يسمح لنا بالتعامل مع الحالة كمتغير عادي دون الحاجة إلى كتابة `.value` في كل مرة. لكي يعمل هذا، لا تنسَ استيراد `getValue` و`setValue` من حزمة وقت تشغيل Compose، لأن بيئة التطوير المتكاملة (IDE) قد لا تُضمّنها تلقائيًا في بعض الأحيان.
ذاكرة التأليف: دور التذكر
من الأخطاء الشائعة جدًا عند البدء تعريف الحالة داخل دالة قابلة للتركيب دون حمايتها. بما أن إعادة التركيب تعني إعادة تنفيذ الدالة، فإن المتغيرات العادية تُعاد تهيئتها في كل تكرار . إذا كان لديك حقل نصي، فسترى أنه لا يكتب أي شيء لأن المتغير يصبح فارغًا مرة أخرى بعد أجزاء من الثانية من كل ضغطة مفتاح.
لحل هذه المشكلة، نستخدم `remember`، التي تخزن القيمة في التركيبة أثناء التنفيذ الأولي وتسترجعها في عمليات التنفيذ اللاحقة. يشبه الأمر إخبار Compose: "احفظ هذه البيانات ولا تتجاهلها حتى لو اضطررت لإعادة رسم المكون". مع ذلك، لـ `remember` قيد: إذا قمت بتدوير الجهاز المحمول أو تم إغلاق النشاط، تُفقد البيانات. في هذه الحالات، يكون الحل هو `rememberSaveable`، الذي يحفظ المعلومات في حزمة ، مما يسمح للحالة بالبقاء حتى بعد تغييرات التكوين.
إذا كنت بحاجة إلى تخزين كائنات معقدة لا تتناسب مباشرةً مع حزمة، فلديك عدة خيارات. يمكنك استخدام التعليق التوضيحي @Parcelize لجعل فئات بياناتك قابلة للتجزئة ، أو إذا كنت تفضل مزيدًا من التحكم، فقم بتنفيذ mapSaver أو listSaver لتحديد كيفية تحويل الكائن إلى بيانات قابلة للتخزين والعكس بدقة.
رفع وإعادة استخدام الدولة
عندما يدير أحد المكونات حالته بنفسه، يُطلق عليه اسم المكون ذي الحالة. هذا مناسب للأمور البسيطة جدًا، ولكنه يجعل اختبار المكون صعبًا ويقلل من مرونته. الحل هو رفع الحالة، والذي يتضمن نقل الحالة إلى مكون أب. بهذه الطريقة، يصبح المكون الابن عديم الحالة، ويقتصر دوره على عرض ما يُطلب منه وإشعار المستخدمين بالتغييرات.
يتمثل النمط القياسي في استبدال متغير الحالة بمعاملين: أحدهما للقيمة الحالية، والآخر دالة لامدا للأحداث (مثل onValueChange). يُنشئ هذا تدفقًا أحادي الاتجاه للبيانات، حيث تنخفض قيمة الحالة وترتفع قيمة الأحداث، مما يمنع تعدد مصادر البيانات الصحيحة ويقلل بشكل كبير من أخطاء التزامن.
الإدارة المتقدمة: التأثيرات، والتدفقات، ونماذج العرض
مع نمو التطبيق، يصبح وضع جميع العمليات المنطقية في كائنات قابلة للتركيب وصفةً للفشل. من الأفضل تفويض هذه المهمة إلى حاويات الحالة مثل نماذج العرض . يتكامل Compose بسلاسة مع LiveData وFlow. على سبيل المثال، يمكنك استخدام `collectAsStateWithLifecycle` لجمع التدفقات بكفاءة ، مما يضمن عدم استهلاك التطبيق للبطارية أو الموارد عندما تكون الشاشة غير مرئية.
لمعالجة الآثار الجانبية، يوفر Compose أدواتٍ مُخصصة. تُمكّنك LaunchedEffect من تشغيل إجراءات فرعية تُلغي نفسها تلقائيًا عند خروج المُكوّن من الشاشة، بينما تُعدّ DisposableEffect مثاليةً لمهام التنظيف. إذا كانت لديك قيمة تعتمد على حالات أخرى، فإنّ derivedStateOf هي الأنسب لك ، إذ تمنع إجراء عمليات حسابية مُكلفة في كل عملية إعادة تركيب إذا لم تتغير التبعيات فعليًا.
التحسين والأداء
لا يقتصر الأمر على كتابة التعليمات البرمجية فحسب، بل يُعدّ التحسين أيضًا أمرًا أساسيًا. الاستقرار هو الأساس هنا. يساعد استخدام الأنواع غير القابلة للتغيير والمُعلّمة بـ @Immutable مُصرّف Compose على التعرّف على أن الكائن لم يتغير، مما يسمح له بتخطي إعادة تجميع بعض المكونات وبالتالي تحسين السرعة.
بالنسبة للقوائم الطويلة، من الضروري استخدام LazyColumn أو LazyRow، حيث يعرضان فقط ما هو مرئي حاليًا. بالإضافة إلى ذلك، يُنصح بقراءة الحالة في أدنى مستوى ممكن من شجرة المكونات، بحيث عند حدوث تغيير، يتم إبطال الجزء الصغير المتأثر فقط من واجهة المستخدم ، وليس الشاشة بأكملها، مما يمنع حدوث أي تأخير في تجربة المستخدم.
تُسهّل هذه البنية المتكاملة، بدءًا من استخدام خاصية "remember" للذاكرة المحلية وصولًا إلى تطبيق نمط MVVM مع تدفقات أحادية الاتجاه، عملية تطوير تطبيقات أندرويد بشكل ملحوظ. فمن خلال فصل منطق الأعمال إلى نماذج عرض (ViewModels) والحفاظ على مكونات واجهة المستخدم نقية وتفاعلية، نحصل على تطبيقات قابلة للتوسع، سهلة الصيانة، والأهم من ذلك، توفر تجربة تصفح سلسة وخالية من أخطاء الحالة. شارك هذه المعلومات ليستفيد منها المزيد من المستخدمين.
