🔵 أولاً: ما هو BLoC؟

BLoC pattern

BLoC = Business Logic Component

هو أسلوب لإدارة الحالة يفصل بين:

🧠 منطق التطبيق (Business Logic)
🎨 واجهة المستخدم (UI)

🧠 الفكرة الأساسية

التطبيق يعمل مثل “نظام رسائل”:

المستخدم يقوم بحدث (Event)
يتم إرسال الحدث إلى BLoC
BLoC يعالج الحدث
يخرج حالة جديدة (State)
الواجهة تتحدث

🔄 مخطط تدفق BLoC

👆 User Action
      ↓
📩 Event
      ↓
🧠 BLoC (Processing)
      ↓
📊 State
      ↓
🎨 UI Update

🔍 مثال ذهني

تخيل:

ضغطت زر “تحميل بيانات”

ما يحدث:

Event = طلب تحميل
BLoC يبدأ المعالجة (API مثلاً)
يخرج:
- Loading
- Success أو Error

🎯 مميزات BLoC

✅ 1. فصل كامل بين UI و Logic

الواجهة لا تعرف كيف تعمل البيانات.

✅ 2. مناسب جداً للمشاريع الكبيرة

لأنه:

منظم
قابل للتوسع

✅ 3. قابل للاختبار (Testable)

تستطيع اختبار المنطق بدون UI.

✅ 4. يعتمد على Streams

يعني:

تدفق بيانات مستمر
تحديثات لحظية

❌ عيوب BLoC

معقد للمبتدئين 😅
يحتاج كتابة أكثر (Boilerplate)

🟣 ثانياً: ما هو Cubit؟

Cubit flutter

Cubit هو نسخة مبسطة من BLoC.

🧠 الفكرة الأساسية

بدل:

Event ➜ State

يصبح:

Function ➜ State

🔄 مخطط Cubit

👆 User Action
      ↓
⚙️ Function (Cubit)
      ↓
📊 State
      ↓
🎨 UI Update

🔍 الفرق الجوهري

BLoC	Cubit
يستخدم Events	لا يستخدم Events
أعقد	أبسط
مناسب للأنظمة الكبيرة جداً	مناسب لمعظم التطبيقات

🎯 مميزات Cubit

✅ 1. سهل التعلم

لا يوجد Events

✅ 2. أقل كود

أبسط في الكتابة

✅ 3. نفس قوة BLoC تقريباً

لكن بدون تعقيد Streams المباشر

✅ 4. مناسب للمشاريع المتوسطة والكبيرة

❌ عيوب Cubit

أقل تنظيم من BLoC في المشاريع الضخمة جداً
لا يوجد فصل صارم مثل BLoC

🔥 الفرق بشكل بصري

🧱 BLoC (نظام رسمي صارم)

UI → Event → BLoC → State → UI

⚡ Cubit (مباشر وسريع)

UI → Function → State → UI

🧠 متى أستخدم كل واحد؟

استخدم Cubit إذا:

تريد سرعة في التطوير
المشروع متوسط
لا تحتاج تعقيد كبير

استخدم BLoC إذا:

مشروع ضخم جداً
فيه تدفقات معقدة
فريق كبير يعمل عليه

🧩 تشبيه بسيط

🏢 BLoC = شركة كبيرة

كل شيء له قسم
نظام صارم
إجراءات واضحة

🏪 Cubit = متجر صغير

مباشر
سريع
بدون تعقيد

🔥 خلاصة قوية

BLoC = قوة + تنظيم + تعقيد
Cubit = بساطة + سرعة + مرونة

🚀 نصيحتي لك

ابدأ بـ Cubit 👇
ثم لما تفهمه 100% ➜ انتقل إلى BLoC

إذا تحب الخطوة الجاية 👇
أقدر أرسم لك Flow حقيقي لتطبيق (Login أو API) باستخدام Cubit و BLoC حتى تفهمهم بشكل احترافي 🔥

اي نعم أحب

جميل 🔥 الآن سنأخذ مثال حقيقي وواضح جداً:
👉 تطبيق تسجيل الدخول (Login)
ونشرح كيف يعمل باستخدام Cubit و BLoC كمخطط ذهني احترافي (بدون كود).

🟣 أولاً: تدفق Cubit (Login Flow)

Cubit flutter

🎯 الفكرة العامة

Cubit يعمل بشكل مباشر:
👉 المستخدم ➜ دالة ➜ حالة ➜ واجهة

🔄 المخطط الكامل

👤 User يدخل email + password
        ↓
🔘 يضغط زر Login
        ↓
⚙️ Cubit.login()
        ↓
📊 State: Loading
        ↓
🌐 API Request
        ↓
📊 State:
   ✔ Success → دخول
   ❌ Error → رسالة خطأ
        ↓
🎨 UI تتحدث تلقائياً

🧠 شرح ذهني

المستخدم يضغط زر تسجيل الدخول
يتم استدعاء دالة داخل Cubit (مثلاً login)
Cubit يقول:
- “أنا الآن في حالة Loading”
يرسل طلب للسيرفر
بعد النتيجة:
- نجاح ➜ Success
- فشل ➜ Error
الواجهة تتغير حسب الحالة

📊 الحالات (States)

🟡 Initial
🔵 Loading
🟢 Success
🔴 Error

💡 كيف تفكر فيه؟

Cubit =

“أنا أملك الحالة، وأغيرها مباشرة حسب ما يحدث”

🔵 ثانياً: تدفق BLoC (Login Flow)

BLoC pattern

🎯 الفكرة العامة

BLoC يعمل عبر وسيط (Events)

🔄 المخطط الكامل

👤 User يدخل البيانات
        ↓
🔘 يضغط Login
        ↓
📩 Event: LoginRequested
        ↓
🧠 BLoC يستقبل الحدث
        ↓
📊 State: Loading
        ↓
🌐 API Request
        ↓
📊 State:
   ✔ Success
   ❌ Error
        ↓
🎨 UI تتحدث

🧠 شرح ذهني

المستخدم يضغط زر
يتم إرسال Event (طلب تسجيل دخول)
BLoC يستلم الحدث
يقرر ماذا يفعل
يغير الحالة:
- Loading
- Success / Error
UI تستجيب

📦 مكونات BLoC

📩 Events

LoginRequested
LogoutRequested

📊 States

Initial
Loading
Success
Error

🧠 BLoC

هو العقل الذي يربط بينهم

⚔️ مقارنة حقيقية (Login)

العنصر	Cubit	BLoC
البداية	Function مباشرة	Event
التعقيد	بسيط	أعلى
التحكم	أقل تنظيماً	أكثر تنظيماً
مناسب	أغلب التطبيقات	الأنظمة الكبيرة

🔥 الفرق بشكل بصري واضح

Cubit ⚡

Button → login() → State → UI

BLoC 🧱

Button → Event → BLoC → State → UI

🧠 متى تستخدم كل واحد في هذا المثال؟

استخدم Cubit إذا:

عندك Login بسيط
API واحد
لا يوجد سيناريوهات معقدة

استخدم BLoC إذا:

🧩 تخيلها بهذه الطريقة

Cubit:

مثل زر تشغيل مباشر 🔘

BLoC:

مثل نظام طلبات داخل شركة 📩

🚀 خلاصة احترافية

Cubit = سرعة + بساطة
BLoC = تنظيم + تحكم عالي

🔥 الخطوة القادمة (مهم جداً)

إذا تريد توصل لمستوى قوي 👇
أقدر أرسم لك:

💡 “Architecture كاملة لتطبيق Flutter”

UI
Cubit/BLoC
Repository
API

بشكل احترافي مثل الشركات 🔥

نعم ارسم

تمام 🔥 الآن سنرسم لك Architecture احترافية كاملة لتطبيق Flutter
(نفس اللي تُستخدم في الشركات) — بشكل واضح وبسيط.

سنستخدم مفهوم:
👉 Clean Architecture + Cubit/BLoC

🏗️ الشكل العام للتطبيق

🎨 UI (Screens / Widgets)
        ↓
🧠 Cubit / BLoC
        ↓
📦 Repository
        ↓
🌐 API / Local DB

🎨 أول طبقة: UI (واجهة المستخدم)

🧩 ماذا تحتوي؟

صفحات (Login, Home…)
Widgets
Buttons, TextFields

🎯 دورها

عرض البيانات فقط
إرسال أوامر (Actions)

❗ مهم جداً

الـ UI لا يحتوي منطق ❌

🔄 مثال

User يضغط Login
        ↓
يرسل الطلب إلى Cubit/BLoC

🧠 الطبقة الثانية: Cubit / BLoC

Cubit flutter
BLoC pattern

🎯 دورها

إدارة الحالة (State)
تنفيذ المنطق

🔄 ماذا تفعل؟

استقبال الطلب من UI
        ↓
تشغيل المنطق
        ↓
طلب بيانات من Repository
        ↓
إرجاع State جديد

📊 الحالات

Loading
Success
Error

🧠 ملاحظة

هذه الطبقة هي “العقل الحقيقي” للتطبيق

📦 الطبقة الثالثة: Repository

🎯 لماذا موجودة؟

لعمل فصل كامل بين:

منطق التطبيق
مصدر البيانات

🔄 ماذا تفعل؟

Cubit/BLoC يطلب بيانات
        ↓
Repository يقرر:
   🌐 API ؟
   💾 Local DB ؟
        ↓
يرجع البيانات

💡 الفائدة

تغيير API بدون تغيير UI
اختبار أسهل

🌐 الطبقة الرابعة: Data Source

🧩 أنواعها

🌍 Remote Data Source

API
الإنترنت

💾 Local Data Source

SQLite
Cache

🔄 دورها

تنفيذ الطلب فعلياً:
- HTTP Request
- قراءة من قاعدة بيانات

🔥 التدفق الكامل (Login مثال)

🟣 باستخدام Cubit

👤 User
   ↓
🎨 UI
   ↓
⚙️ Cubit.login()
   ↓
📦 Repository.login()
   ↓
🌐 API
   ↓
📦 Repository
   ↓
📊 Cubit State
   ↓
🎨 UI Update

🔵 باستخدام BLoC

👤 User
   ↓
🎨 UI
   ↓
📩 Event (LoginRequested)
   ↓
🧠 BLoC
   ↓
📦 Repository
   ↓
🌐 API
   ↓
📦 Repository
   ↓
📊 State
   ↓
🎨 UI

⚔️ الفرق داخل الـ Architecture

الطبقة	Cubit	BLoC
طريقة التشغيل	Function	Event
التعقيد	أقل	أعلى
التحكم	مباشر	منظم أكثر

🧠 لماذا هذه المعمارية قوية؟

✅ 1. فصل كامل (Separation of Concerns)

كل طبقة لها دور واحد فقط

✅ 2. سهولة التعديل

تغير API؟
لا تحتاج تعديل UI 😎

✅ 3. اختبار سهل

تستطيع اختبار كل طبقة لوحدها

✅ 4. مناسب للشركات

مشاريع كبيرة
فرق متعددة

🧩 تخيلها بشكل بسيط

🏢 التطبيق مثل شركة

🎨 UI = موظف الاستقبال
🧠 Cubit/BLoC = المدير
📦 Repository = المسؤول عن البيانات
🌐 API = المورد الخارجي

🔥 خلاصة احترافية

أفضل Structure في Flutter:

UI
↓
Cubit / BLoC
↓
Repository
↓
Data Source