Rattibha

في العام الماضي أعلنت Apple و Google عن إطلاق مكتبتين جديدة لتحسين آلية إنشاء الواجهات في عالم تطبيقات الجوال وهي Jetpack Compose و SwiftUI. هذا الدعم من منصات الـ Native فتح المجال أكثر لتبني فكرة الـ server driven UI. فخلونا نشوف ونتعرف أكثر على هذه الفكرة
#android #ios #ui

مارح نتطرق في هذا الثريد للكلام عن هذه المكتبتين وخصوصاً بإننا صرنا نشوف كثير من المصادر اللي ممكن تساعدك في فهمها .. لكن اليوم رح نحاول نتكلم عن أنماط بدأت تستخدم بكثرة بين المطورين حتى يستفيدوا منها بأكبر قدر ممكن ولعل أهمها مثل ما ذكرت الـ Server Driven UI

فكرة الـ Server Driven UI أو ممكن أحيانا تسمى Backend Driven UI بكل بساطة هي طريقة لإعطاء السيرفر كامل الحرية والقدرة على التحكم في الأشياء اللي تعرض على شاشة المستخدم .. وهذا رح يساعدك في إنك تتخلص من الـ static layouts وتصير واجهاتك dynamic و reactive أكثر

هذه الفكرة بدأت تنتشر لما بدأنا نتقبل أكثر إطارات الـ hybrid مثل flutter و react native .. واللي تستخدم طريقة الـ declarative في بناء الواجهات من قبل حتى compose و swiftui ..لكن كان من أكبر مشاكلها هو تواجد bridge يحولك كل الـ components المستخدمة ويعطيها الـ native look-and-feel

هذا الجسر كان أيضاً يسبب بطء بسيط في عملية الـ rendering وخصوصاً لو كان الـ ui element معقد .. لكن بمجرد ظهور compose و swiftui وتخليهم التام عن وجود أي جسر كون العناصر اللي رح يتم بناءها native تلقائياً .. خلانا نشوف تقبل أكبر لفكرة إعطاء السيرفر القدرة على التحكم في الواجهات

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

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

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

وهذا اللي خلانا نعتمد على فكرة الـ server driven UI .. بكل بساطة رح تتيح لك إمكانية إنك تغير وتبدل أشياء كثيرة من السيرفر وبمجرد ما يدخل العميل على التطبيق .. رح يرسل السيرفر آخر التحديثات الخاصة بالـ UI structure اللي لازم تنعرض للعميل
كلام كبير 😎👌

طبعاً تطبيق هذه الفكرة مو بسيط .. ويحتاج إلى communication رهيب مابين 3 أطراف رئيسة .. مصمم الواجهات .. ومطور التطبيقات .. والـ API developer للسيرفس أو الـ endpoint اللي رح يكلمها مطور التطبيق عشان يبني الواجهة اللي رح تنعرض للعميل .. وكل شخص رح يكون له أدوار معينة

دور المصمم واضح وهو تقسيم التصميم المقترح لأجزاء صغيرة وتوضيح الأجزاء الـ dynamic اللي من الممكن إنها تتغير مستقبلاً والأجزاء الـ static أو اللي مارح تتغير بالإضافة إلى توضيح الـ actions اللي من الممكن تنفيذها على العنصر بمعنى هل العنصر رح يدعم الـ click أو الـ long click وغيرها

بعد الإنتهاء من تصميم الـ primary blocks أو الأجزاء الأساسية .. رح يتم إعطاءها لمطور التطبيق حتى يبدأ يحول التصميم لعناصر داخل التطبيق وربطها بشكل مباشر مع الـ API اللي رح يتم تنفيذها من قبل مطور الـ backend واللي بدوره رح يحاول يصمم API مطابقة في مخرجاتها لعناصر التصميم

هذا المستوى من التنفيذ لفكرة الـ SDUI يطلق عليه أحياناً الـ block-level implementation .. بمعنى إن الـ layout containers رح تكون ثابتة .. يعني لو كان أول element موجود عندك في الصفحة carousel مثلاً .. فالشي الوحيد اللي رح يتغير هو الـ blocks اللي رح تنعرض داخل الـ carousel

هذا المستوى يعتبر سهل التنفيذ عموماً أو doable بمعنى أصح .. وخصوصاً مع الإمكانيات اللي تقدمها compose و swiftui .. لكن لو حبينا نطلع لمستوى أعلى ونبدأ نتحكم في نفس الـ layouts وترتيبها أو حتى تغييرها فـ رح تبدأ تزيد الـ complexity بشكل بسيط .. والجهد رح يزيد طبعاً

نهايةً .. المستوى المطلوب تنفيذه رح تقدر تحدده بناء على عدة عوامل .. أهمها هي القابلية لعنصر معين إنه يتغير بمعنى is it likely to be changed later وإذا كانت الإجابة نعم فـhow often ؟ وأكيد طبعاً مستوى فريق التطوير والتصميم ومدى تمرسهم على هذا المفهوم

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