التقرير ده خريطة مبدئية للتنفيذ. كل محور فيه شرح مبسّط وطريقة تقنية مقترحة. التفاصيل النهائية تتحسم بعد جرد النظام واختبار الحلول؛ لم يتم تنفيذ ترحيل أو تغيير بيانات الإنتاج.
١. نقل Firestore إلى Supabase Self-hosted
بالمبسّطهننقل بيانات المنصة لمخزن إحنا مسؤولين عنه. لازم كل طالب يفضل شايف كورساته، وجهازه مربوط صح، والمفاتيح شغالة، وكل مدرس يشوف بياناته فقط. نجرب على نسخة اختبارية ونجهز طريق رجوع.
الطريقة التقنية
- نحصر الـ collections والحقول والـ Cloud Functions والـ security rules واستخداماتها في تطبيق الطالب وStudio والـ Dashboard والبوتات.
- نصمم PostgreSQL schema للمدرسين والطلبة والكورسات والمحاضرات والاشتراكات والأجهزة والتراخيص، مع الاحتفاظ بمعرّفات Firebase أو جدول mapping للمطابقة.
- نفصل قرار نقل البيانات عن تسجيل الدخول: ممكن نحتفظ بـ Firebase Auth انتقالياً، أو ننقل إلى Supabase Auth بعد اختبار طرق الدخول وكلمات المرور والجلسات. لا نفترض انتقال الحسابات بلا إعادة دخول.
- نطبق RLS وعزل العملاء، ونختبر صلاحيات الطالب والمدرس؛ مفاتيح الإدارة تفضل على السيرفر.
- نجرّب export وtransform وimport على staging، ونقارن الأعداد والعلاقات وعينات البيانات والصلاحيات، ونختبر الكورسات القديمة والمفاتيح وربط الأجهزة.
- نحدد مصدر الحقيقة أثناء الانتقال والتغييرات التي حدثت خلال النقل، ثم نطرح تدريجياً بمعايير توقف وrollback يعالج البيانات المكتوبة بعد التحويل.
التشغيل: الاستضافة الذاتية تحتاج نسخاً احتياطية مشفرة خارج السيرفر، وتجارب استعادة، ومراقبة وتحديثات وسعة مناسبة. قرار نقل الهوية مع البيانات أو تأجيله يتحسم بعد الجرد.
٢. متابعة المشاهدة بالتفصيل
بالمبسّطالتطبيق يسجل الطالب شاف إيه ووصل لفين والأجزاء اللي رجع شغّلها. المدرس يشوف عدد الطلاب ونسب التقدم وأكتر أجزاء الفيديو تكراراً، مع توضيح إن البيانات الأوفلاين ممكن تتأخر.
الطريقة التقنية
- نعرّف أحداث بدء التشغيل والإيقاف والانتقال بين المواضع والانتهاء وتغيير السرعة، ونسجل فترات المشاهدة الفعلية.
- نقسم الفيديو لمقاطع تحليلية، مثلاً كل ١٠ أو ٣٠ ثانية بعد تحديد الدقة والتكلفة، ونحسب عدد الطلاب الفريدين ومرات مشاهدة كل مقطع لرسم خريطة الإعادات.
- نفصل بين التقدم الفريد، وإجمالي وقت التشغيل الذي يشمل الإعادة، والمشاهدين الفريدين، وعدد الإعادات، بتعريف واضح لكل رقم.
- نحتفظ بالأحداث الخام لفترة محددة ونبني منها جداول مجمّعة لتقارير سريعة، مع سياسة للاحتفاظ وتصحيح التجميع.
- نعرض وقت آخر مزامنة ونوضح إن الأرقام قد تتأخر. نحدد سياسة الخصوصية ونوضح للمستخدم نوع المتابعة.
مثال: لو الطالب شاف أول ٥ دقائق ثم أعاد دقيقة منها، يبقى التقدم الفريد ٥ دقائق وإجمالي التشغيل ٦ دقائق. الأرقام لا تثبت وحدها انتباه الطالب أو فهمه.
٣. المزامنة الأوفلاين
بالمبسّطالجهاز يحتفظ بدفتر للأحداث، ويسلّمه للسيرفر لما الاتصال يسمح. ولو النت فصل، يكمل بعدين من غير ما يحسب نفس الحدث مرتين.
الطريقة التقنية
- نحفظ الأحداث محلياً بمعرّف فريد لكل حدث ونسخة schema ووقت الجهاز ومدة التشغيل وهوية الجلسة.
- نرسلها على دفعات ونحذف الحدث المحلي فقط بعد إقرار السيرفر بحفظه، ونستخدم idempotency لمنع التكرار.
- نضيف retry تدريجياً وحدوداً للتخزين والدفعات، ونعالج امتلاء المساحة وإغلاق التطبيق المفاجئ.
- نسجل وقت الاستلام ونتعامل مع اختلاف ساعة الجهاز والأحداث المتأخرة. نحدد طريقة دمج التقدم بين الأجهزة.
- نختبر انقطاع الشبكة وتكرار الطلب وإعادة التشغيل والعمل أوفلاين لفترة طويلة. المزامنة في الخلفية على iOS تخضع لقيود النظام؛ نضمن المحاولة عند فتح التطبيق وعودة الاتصال دون وعد بالفورية دائماً.
٤. المشاهدة المباشرة بالـ segments
بالمبسّطالطالب يبدأ المشاهدة من غير ما ينزّل الفيديو كله: التطبيق يطلب أجزاء صغيرة مشفرة ويعرضها بالتتابع، ويختار جودة مناسبة للاتصال.
الطريقة التقنية
- نجهز نسخ جودة مختلفة ونقسمها إلى segments مع manifest مناسب، مثل HLS، بعد اختبار دعم المنصات.
- نحفظ المحتوى المشفر في object storage أو CDN؛ قاعدة البيانات تحفظ البيانات الوصفية والصلاحيات.
- نتحقق من الحساب والاشتراك والجهاز قبل منح وصول محدود المدة للمحتوى والترخيص وفق تصميم الحماية.
- نطبق buffering وadaptive bitrate ونتعامل مع الانتقال بين أجزاء الفيديو والانقطاع وانتهاء الترخيص.
- على Apple ندرس توافق FairPlay ومسار HLS والترخيص الموجود، ونجربه فعلياً على الأجهزة.
- نقيس وقت بدء التشغيل والتوقفات واستهلاك البيانات على شبكات ضعيفة.
البث يضيف تكلفة تخزين ونقل بيانات وخدمة تراخيص. حماية DRM تقلل التسريب لكنها لا تمنعه بالكامل؛ نحدد مستوى الحماية والتكلفة قبل اختيار الحل.
٥. التحميل المباشر وتحديث المحتوى
بالمبسّطالطالب يضغط تحميل داخل التطبيق، ويتابع التقدم ويوقف ويكمل. لو المحاضرة اتعدّلت، التطبيق يعرف إن فيه نسخة أحدث من غير ما الطالب يدور على ملف خارجي.
الطريقة التقنية
- نبني download manager بطابور واستئناف للتحميل والتحقق من سلامة الملف قبل إتاحته.
- نعطي كل محتوى version وmanifest وبصمات للملفات؛ ننزل النسخة الجديدة منفصلة ونفعّلها بعد التحقق، فتفضل القديمة متاحة لو فشل التحديث.
- نحافظ على تشفير الملفات ونحدد صلاحية الترخيص الأوفلاين وسياسة إلغاء الوصول.
- نضيف إدارة مساحة توضّح حجم المحاضرة وحذف التنزيل وإعادة تحميله، بدون المساس بالاشتراك.
- نختبر توافق ملفات .sec الحالية مع التوزيع الجديد قبل قرار تحويل المكتبة.
٦. تحديث التطبيق نفسه
بالمبسّطالتطبيق يعرف إن فيه إصدار جديد ويوصل الطالب للتحديث بالطريقة المناسبة لجهازه. الكمبيوتر ممكن يدعم تحديثاً مباشراً، وiPhone له قناة توزيع وقواعد خاصة.
الطريقة التقنية
- ننشر release manifest موثوق فيه رقم الإصدار والمنصة وقناة التوزيع والحد الأدنى المتوافق ورابط الحزمة وبصمتها.
- على Windows والقنوات المناسبة نختبر updater يتحقق من توقيع الحزمة وسلامتها، مع استعادة الإصدار السابق عند فشل التثبيت.
- على Android نختار الآلية حسب المتجر أو التوزيع المباشر والتوقيع. وعلى iOS نستخدم قناة التوزيع المعتمدة ونراعي قواعد Apple المتعلقة بتنزيل الكود.
- نطرح تدريجياً ونحافظ على توافق الإصدارات القديمة، ولا نجبر الجميع على التحديث إلا لسبب واضح.
٧. تبسيط التجربة وزيادة المرونة
بالمبسّطالطالب يلاقي كورسه ويكمل آخر محاضرة ويختار المشاهدة أو التحميل بسهولة. والمدرس يتحكم في الشكل والمزايا المناسبة له من غير نسخ مختلفة لكل تعديل قدر الإمكان.
الطريقة التقنية
- نرسم رحلات الدخول وفتح الكورس والمشاهدة والتحميل والأوفلاين وحل مشكلة الجهاز والتحديث.
- نختبر نماذج واجهات مع مستخدمين حقيقيين ونقيس خطوات ووقت الوصول لأول محاضرة.
- ننشئ design system يدعم العربي وRTL وإمكانية الوصول وحالات التحميل والخطأ وأحجام الشاشات.
- نضيف إعدادات للبراند والمزايا لكل عميل بقيم افتراضية واضحة، مع دعم النسخ القديمة والعمل أوفلاين.
- السيرفر يتحقق من الصلاحيات؛ إخفاء زر في الواجهة وحده لا يعتبر حماية.
من ملاحظات الطلبة المسجلة: اختبار تكبير الفيديو وإدارة مساحة المحاضرات المحمّلة.
٨. الذكاء الاصطناعي في Studio
بالمبسّطالمدرس يختار فيديو، وStudio يجهز مسودة كويز من محتواه مع الإجابات والمواضع المرتبطة في الفيديو. المدرس يراجع ويعدل قبل النشر.
الطريقة التقنية
- نستخدم transcript موجوداً أو نستخرج نصاً بتوقيتات، ونحدد مكان المعالجة والمزوّد بناءً على الخصوصية والتكلفة.
- نقسم النص لأجزاء، ونولد أسئلة منظمة تتضمن السؤال والاختيارات والإجابة والشرح والموضع المصدر.
- نتحقق من اكتمال البنية وصلاحية الاختيارات وتقليل التكرار، ونعرض المسودة مع رابط لموضعها في الفيديو.
- يبقى النشر بعد مراجعة المدرس؛ التحقق الآلي لا يضمن صحة المعلومة الطبية.
- نضيف طابور jobs بالحالة والفشل وإعادة المحاولة وتقدير التكلفة قبل التشغيل، وسياسة الاحتفاظ بالنصوص وإرسالها لمزوّد خارجي.
بعد إثبات جودة الكويز، يمكن البناء على نفس الأساس للملخصات وأسئلة المراجعة.
٩. تحسين الأداء
بالمبسّطنقيس على أجهزة حقيقية قبل التعديل، ونحدد سبب البطء، ثم نحسّنه ونقارن بنفس القياس.
الطريقة التقنية
- نقيس وقت فتح التطبيق وأول شاشة وبداية الفيديو والذاكرة وحجم التطبيق والأعطال على أجهزة وشبكات مختلفة.
- نستخدم profiling لتحديد هل المشكلة في Flutter أو فك التشفير أو البيانات أو الصور أو الشبكة.
- نراجع pagination وcaching وتجميع الطلبات وفهارس PostgreSQL، ونبعد العمل الثقيل عن مسار الواجهة عند الحاجة.
- نختبر الأوفلاين والبث والتحميل معاً على أجهزة أضعف، ونضع أهدافاً رقمية بعد معرفة خط الأساس.
١٠. تحديث نسخة iPhone
بالمبسّطنراجع نسخة iPhone ونختبر الدخول والكورسات والتشغيل والتحميل والأوفلاين والحماية والتحديث على أجهزة فعلية، ونصلح المشاكل ونعيد اختبارها قبل الإصدار.
الطريقة التقنية
- نقارن مستودع iOS بمصدر التطبيق الرئيسي، ونحدد الفروق واعتماديات FairPlay وطريقة البناء.
- نختبر أجهزة وإصدارات ممثلة، وشبكة ضعيفة ومساحة قليلة والخلفية والعودة وانتهاء الصلاحيات.
- نختبر المحتوى القديم والجديد والترخيص الأوفلاين وتسجيل الشاشة وفق السلوك المطلوب.
- نراجع متطلبات Apple والخصوصية والتجربة الخاصة بالمراجعة، ثم نبني بالبنية المناسبة مثل Codemagic ونطرح beta تدريجية.
- نتابع أعطال التطبيق ومشاكل التشغيل قبل التوسع.
الهدف نسخة مستقرة جداً بمعايير قبول قوية، لكن الاختبار لا يضمن انعدام كل المشاكل على جميع الأجهزة والظروف.
ترتيب التنفيذ المقترح
- الجرد والقياس: الكود والبيانات والهوية والحماية وiOS والأداء.
- تصميم الأساس: قاعدة البيانات والصلاحيات وتعريفات المتابعة والأوفلاين والتراخيص.
- تجربة الترحيل: staging ومقارنة البيانات واختبار النسخ الاحتياطي والاستعادة.
- المتابعة والمزامنة: الأحداث والدفعات والتقارير ومراعاة التأخير.
- البث والتحميل: نماذج عملية لكل منصة ثم التوافق وترحيل المحتوى تدريجياً.
- التجربة والمرونة: تصميم واختبار رحلات الطالب والمدرس.
- كويزات AI: مسودة بمراجعة المدرس مع قياس الجودة والتكلفة.
- الطرح التدريجي: اختبارات الأداء وiOS مستمرة من البداية، وبوابة قبول قبل كل إصدار.
المصادر وحدود التقرير
التقرير مبني على توثيق Secure Player المتاح ومراجعة محدودة لملفات الاعتماديات، وليس تدقيقاً شاملاً لكل الكود. تطبيق الطالب ونسخة iOS يستخدمان Firestore عبر REST، ونسخة iOS فيها مكونات مرتبطة بـ FairPlay؛ بقية التفاصيل تحتاج جرداً واختباراً.
المقترحات قرارات مبدئية للتخطيط، وليست ترحيلاً منفذاً أو وعداً بنتائج مقاسة.