https://pub.dev/packages/smart_pagination


- smart_pagination مكتبة Flutter جاهزة للـ pagination مع إدارة حالة مدمجة بنمط BLoC.
- تدعم أكثر من 6 أنواع عرض: ListView, GridView, PageView, StaggeredGrid, ReorderableListView وغيرها مع نفس الـ API.
- توفر معالجة أخطاء متقدمة مع 6 ستايلات Widgets جاهزة، وحالات منفصلة لأول صفحة ولتحميل المزيد، مع دعم إعادة المحاولة اليدوية والتلقائية.
- تدعم REST APIs وStreams (real-time) مع استراتيجيات مختلفة للـ pagination (offset, cursor, lazy loading, smart preloading) وتحسينات أداء للذاكرة.
- قابلة للتخصيص بدرجة كبيرة في الـ UI، مع دعم أنواع Generics، وفلاترة server/client side، وأكثر من 60 اختبار لضمان الاستقرار.

هذه قائمة مختصرة بأشهر مكتبات Flutter مع وصف قصير + رابط الباكج + التوثيق الخاص بها:



🧠 إدارة الحالة (State Management)

1. provider – أبسط حل شهير لإدارة الحالة يعتمد على InheritedWidget ويوفّر Dependency Injection بشكل أنيق.
Package: https://pub.dev/packages/provider
Docs: https://pub.dev/documentation/provider/latest


2. flutter_riverpod – إطار حديث لإدارة الحالة، Reactive، يدعم async بسهولة، وقوي جدًا للمشاريع المتوسطة والكبيرة.
Package: https://pub.dev/packages/flutter_riverpod
Docs: https://riverpod.dev/docs


3. flutter_bloc – Widgets جاهزة لتطبيق نمط BLoC مع فصل واضح بين الـ UI والـ Business Logic.
Package: https://pub.dev/packages/flutter_bloc
Docs: https://bloclibrary.dev
🌐 الشبكات (Networking / APIs)


4. dio – HTTP Client قوي يدعم Interceptors, FormData, Upload/Download, Timeout، وإلغاء الطلبات.
Package: https://pub.dev/packages/dio
Docs: https://pub.dev/documentation/dio/latest


5. http – مكتبة رسمية بسيطة لاستهلاك REST APIs، مناسبة للحالات الخفيفة أو عند رغبتك في شيء minimal.
Package: https://pub.dev/packages/http
Docs: https://pub.dev/documentation/http/latest


🧭 التوجيه (Routing & Navigation)


6. go_router – Router declarative مبني على Navigation 2.0 مع دعم deep links وURL-based navigation.
Package: https://pub.dev/packages/go_router
Docs: https://pub.dev/documentation/go_router/latest



💾 التخزين المحلي (Local Storage / Persistence)

7. shared_preferences – لتخزين بيانات بسيطة (key-value) مثل الإعدادات وحالة تسجيل الدخول.
Package: https://pub.dev/packages/shared_preferences
Docs: https://pub.dev/documentation/shared_preferences/latest


8. hive – NoSQL key-value DB خفيف وسريع بدون الحاجة لـ SQL، مع تشفير AES-256.
Package: https://pub.dev/packages/hive
Docs: https://pub.dev/documentation/hive/latest


9. sqflite – أشهر Plugin لـ SQLite في Flutter، يدعم transactions وbatches وإدارة نسخ قاعدة البيانات.
Package: https://pub.dev/packages/sqflite
Docs: https://pub.dev/documentation/sqflite/latest


10. drift – مكتبة Persistence Reactive فوق SQLite، توفر type-safe SQL + stream queries + دعم isolates.
Package: https://pub.dev/packages/drift
Docs: https://drift.simonbinder.eu/docs
🛠 أدوات عامة وواجهات (Utilities & UI Helpers)


11. url_launcher – لفتح الروابط في المتصفح، الاتصال الهاتفي، إرسال SMS أو بريد من داخل التطبيق.
Package: https://pub.dev/packages/url_launcher
Docs: https://pub.dev/documentation/url_launcher/latest



12. cached_network_image – تحميل صور من الإنترنت مع كاش تلقائي + Placeholder وError Widget.
Package: https://pub.dev/packages/cached_network_image
Docs: https://pub.dev/documentation/cached_network_image/latest


13. intl – تنسيقات التاريخ والأرقام والـ localization (ترجمة الرسائل، plurals، إلخ).
Package: https://pub.dev/packages/intl
Docs: https://pub.dev/documentation/intl/latest


🔥 Firebase Integration

14. firebase_core – الأساس لربط تطبيقك بـ Firebase، يجب تهيئته قبل استخدام أي Firebase plugin آخر.
Package: https://pub.dev/packages/firebase_core
Docs: https://firebase.google.com/docs/flutter/setup


15. cloud_firestore – Plugin للتعامل مع Cloud Firestore (NoSQL Realtime DB مع offline support).
Package: https://pub.dev/packages/cloud_firestore
Docs: https://firebase.flutter.dev/docs/firestore/overview

🚀 مكتبة Flutter رهيبة اسمها super_interactive_text 👇
تخلي أي نص في تطبيقك “ذكي” ويتحوّل تلقائيًا لعناصر قابلة للنقر ✅
🔗 روابط (URL)
📧 إيميلات
📞 أرقام هاتف
#️⃣ هاشتاقات
@️⃣ منشن (username)
🌐 وحتى روابط منصّات التواصل + دعم روابط داخلية للتنقّل داخل التطبيق
مفيدة جدًا لتطبيقات الدردشة، التعليقات، الوصف، أو أي مكان فيه نصوص كثيرة 💬✨
🌐 رابط المثال التجريبي: https://geniussystems24.github.io/super_interactive_text/
📦 رابط المكتبة: https://pub.dev/packages/super_interactive_text
#Flutter #Dart #OpenSource #MobileDev #UI #DeveloperTools

https://geniussystems24.github.io/tooltip_card/#/animations

احدى مكاتب الـ Flutter التي استغرق بناءه وتطويرها وقت ليس بالقليل.. وكان سبب بناءها تسهيل واجهات المستخدم في نظام شركتنا #GeniusLink.

🔥 مكتبة tooltip_card لـ Flutter: Tooltip/Popover احترافية مستوحاة من Fluent TeachingTip وتدعم Material 3 و RTL.
✅ مناسبة لشرح العناصر داخل التطبيق بشكل جميل وواضح.
🧠 تموضع ذكي حول العنصر (12 اتجاه) لتفادي خروجها من الشاشة.
➡️ تدعم سهم/Beak قابل للتخصيص لتحديد الهدف بدقة.
👆 تريجرات متعددة: Tap / Hover / Double-tap حسب تجربة المستخدم.
🎛 تحكم كامل عبر Controller (فتح/إغلاق برمجياً بسهولة).
✨ تخصيص عالي للشكل: ألوان، حواف، ظل، ومسافات.
📦 جرّبها : <https://pub.dev/packages/tooltip_card>

هل صادفت شاشة منتجات “تفلاش” بيانات ناقصة… ثم تبدأ الطلبات تتكرر على الـ API بدون سبب؟

في MyApp واجهنا سيناريو شائع في Local-First داخل الـ SDK:
عند عرض Product List، كل منتج يحتاج Reference Data: Section / Unit / Manufacturer.
لكن عند انتهاء TTL تصبح البيانات Stale.

⚠️ المشكلة (The Blind Spot)
بدون سياق مزامنة مثل since أو lastSentAt، الـ SDK لا يعرف ما تغيّر فعلاً → يلجأ إلى Blind Full Fetch (Get All).

🔥 النتيجة
Redundant API Calls + High Server Load + Poor UX + نفس الداتا تُرسل مراراً.

✅ الحل
Delta/Incremental Sync + إرسال since = lastSentAt عند إعادة الطلب،
مع نافذة منع تكرار (10 دقائق) + (اختياري) Stale-While-Revalidate،
ومع ضغط UI العالي: Single-Flight / In-Flight Deduplication.

هل تستخدمون updatedSince / ETag / lastSyncAt في مشاريعكم؟

شرح الحل في المنشورات القادمة

#API #MobileArchitecture #DistributedSystems

حل مشكلة “الطلبات المكررة” في Reference Data بطريقة أبسط وأذكى داخل MyApp ✅

بدل ما الـ SDK يعيد جلب كل شيء عند انتهاء TTL أو عند تكرار فتح الشاشة، طبقنا 3 أفكار مع بعض:

1) Delta Sync (Incremental Updates)
كل مرة نطلب فقط التغييرات عبر:
?since=lastSentAt
يعني: “أعطني ما تغيّر منذ آخر مزامنة ناجحة” بدل Full Fetch.

2) Throttle Window (مثلاً 10 دقائق)
لو المستخدم أعاد فتح الشاشة أو كرر نفس الطلب خلال 10 دقائق:
لا نرسل API Call جديد → نكتفي بالمحلي.
وبعد انتهاء النافذة نسمح بطلب Delta جديد.

3) Stale-While-Revalidate (SWR)
نعرض البيانات المحلية فوراً (حتى لو قديمة قليلاً) ونحدّث بصمت في الخلفية.
النتيجة: تجربة أسرع بدون “فلاش” بيانات ناقصة.

📌 النتيجة النهائية:
Optimized Network ✅
Low Server Load ✅
Fast & Fluid UX ✅
Tiny Delta Payload بدل Massive Payload ✅

هل تستخدمون lastSyncAt / lastSentAt أو Delta Sync في مشاريعكم؟

#API #MobileArchitecture #DistributedSystems

مشكلة شائعة في Local-First: “Race Condition” تسبّب رحلات API مكررة 🚨

مشكلة شائعة في Local-First: “Race Condition” تسبّب رحلات API مكررة 🚨

تخيّل شاشة Product List تُرندر عدة عناصر في نفس اللحظة (Product A / B / C…).
كل منتج يحتاج نفس الـ Reference Data مثل: Section #4.
الـ SDK يعمل Local-First → يفحص Local DB (Cache) أولاً.

⚠️ أين المشكلة؟
لأن الطلبات متزامنة، الجميع يصلون للكاش قبل أن يكتب أول طلب النتيجة:
Local DB = MISS (Not Found Yet)
فيقوم كل منتج بإطلاق طلب شبكة مستقل لنفس البيانات…
فتتحول العملية إلى 20+ طلب متطابق قبل أن يكتمل الأول.

🔥 الأثر على الخلفية (Backend)
- High Concurrency Load
- Wasted Bandwidth
- Risk of Rate Limiting
- UX أبطأ بسبب ازدحام الشبكة

🧠 المصطلحات الشائعة
- Cache Stampede / Thundering Herd
- Race Condition (In Local-First Cache)
- Redundant API Calls (وأحياناً تُرى كـ N+1 / Over-fetching حسب السياق)

✅ كيف نعالجها عادة؟
- Single-Flight / In-Flight Deduplication: “طلب واحد لكل مفتاح” والبقية تنتظر نفس الـ Future/Promise
- Request Coalescing: تجميع الطلبات المتطابقة
- (اختياري) Prefetch/Batch للـ Reference Data عند تحميل المنتجات

هل واجهت هذا السيناريو في تطبيقك؟ وكيف تعاملت معه؟

الحل في المنشورات القادمة

#API #MobileArchitecture #DistributedSystems

حل “الطلبات المتزامنة المكررة” في Local-First: Request Coalescing (Single-flight) ✅

المشهد معروف:
شاشة Product List تُرندر عدة منتجات في نفس اللحظة (Product A / B / C…)
وكلهم يحتاجون نفس الـ Reference Data مثل: Get Section #4.
بدون حل، كلهم يطلقون API Calls متطابقة قبل ما يكتمل أول طلب ويكتب للكاش.

حل “الطلبات المتزامنة المكررة” في Local-First: Request Coalescing (Single-flight) ✅

المشهد معروف:
شاشة Product List تُرندر عدة منتجات في نفس اللحظة (Product A / B / C…)
وكلهم يحتاجون نفس الـ Reference Data مثل: Get Section #4.
بدون حل، كلهم يطلقون API Calls متطابقة قبل ما يكتمل أول طلب ويكتب للكاش.

🧠 الحل: SDK Request Coordinator (In-flight Map)
نضيف طبقة داخل الـ SDK تعمل كـ “مُنسّق طلبات”:
- تحتفظ بخريطة: Map<Key, Future>
- المفتاح = (Section#4)
- القيمة = Shared Future (طلب جاري)

كيف يعمل؟
1) أول طلب (Product A):
- لا يجد المفتاح في الـ In-flight Map
- ينشئ Shared Future
- ويرسل 1x API Request فقط

2) الطلبات التالية (Product B / C…):
- تجد Shared Future موجودة
- لا تُنشئ طلبات جديدة
- فقط “تنتظر” نفس الطلب الجاري (Await existing in-flight request)

📦 عند وصول النتيجة
- يتم كتابة البيانات إلى Local DB (Cache) ✔️
- يتم توزيع نفس النتيجة فوراً لكل عناصر UI المنتظرة (Fan-out) ✔️

📌 النتيجة
- 1x Optimized API Request بدل 20x Duplicate Requests
- Minimal Backend Load
- Fast & Consistent UX
- Cache يُملأ مرة واحدة ويُستخدم للجميع

🔎 مصطلحات مرتبطة
- Request Coalescing
- Single-flight Mechanism
- In-flight Deduplication
- Shared Future / Promise
- (وأحياناً يُستخدم كـ Lock per Key)

هل تطبّقون Single-flight في الـ SDK أو على مستوى Repository Layer؟
#API #MobileArchitecture #DistributedSystems