LinkedIn ✅️

https://www.linkedin.com/in/mazap64

24 Hours or what ? 🤔

#منقول

♦️كنت في انترفيو وسالني عن clean architecture عن جزء repository
الموجود في data في تقسيمة المشروع
ايه الفرق بين repository و datasource
قولت له ال datasource دا بكلمه فيه ال api وامسك ال Exception
و repository برجع فيه الموديل لو الداتا صح ولو غلط بحول Exception ل Failure واعرضه
قالي طب لو مش هستخدم api ف معرفتش اقول ايه
ممكن حد يوضح النقطه دي ؟

🔥هو مكنش مستني منك كده هو كان مستني منك رد يوضح انك فاهم ال concept نفسه يعني
ال data source هو مجرد class مسؤول عن ال connection مع مصدر ال data او ال database بغض النظر عن ان المصدر ده ايه ان كان remote server او local database او حتى device info من ال device نفسها
وكل data source مسؤؤله عن connection واحده يعني متعملش مثلا data source بتجيب من لوكال و ريموت سوا
بالتالي هو مسوؤل في آخر انه يجيب الداتا ويهندلها ل type معين
إنما ال repository تقدر تعتبره وسيط او apis ما بين ال data layer وال presentation layer او نقدر نقول هو ال abstraction بتاع ال data layer وممكن يعتمد على اكتر من data source علشان ياخد القرار يجيب الداتا من انهي مصدر
مثال على كده لو مفيش نت ال repo هيجيب الداتا من ال local data source

في الـ Clean Architecture، الفرق بين الـ Repository و الـ DataSource مهم لفهم كيفية تنظيم البيانات والتفاعل معها.

1. DataSource:
هو مكون مسؤول عن الاتصال بمصدر البيانات، سواء كان قاعدة بيانات محلية، API خارجي، أو حتى بيانات من جهاز المستخدم. الـ DataSource
يتعامل بشكل مباشر مع المصدر ويجلب البيانات منه. مثلاً، قد يكون لديك DataSource للتواصل مع API أو DataSource آخر للتعامل مع قاعدة بيانات محلية.

2. Repository:
هو طبقة تعمل كوسيط بين البيانات
(Data Layer) والـ Presentation Layer. الـ
Repository يتعامل مع واحد أو أكثر من الـ DataSource ليقرر من أين يجلب البيانات بناءً على الشروط المعينة مثل توفر الشبكة. الـ Repository يمكنه التعامل مع استثناءات الـ DataSource وتحويلها إلى حالات (States) مفهومة أكثر للطبقات الأخرى.

إذا لم تستخدم API، فالـ Repository يمكنه أن يتعامل مع DataSource آخر، مثل قاعدة بيانات محلية. عندما تسأل عن البيانات، الـ Repository سيقرر ما إذا كان يجب جلب البيانات من مصدر محلي أو عبر الإنترنت، وذلك بناءً على شروط معينة (مثل اتصال الشبكة).

مثال توضيحي:
- إذا كنت بحاجة إلى جلب بيانات من الإنترنت، فـ Repository سيستخدم DataSource للتواصل مع API.
- إذا لم يكن هناك اتصال بالإنترنت، فـ Repository قد يقرر جلب البيانات من DataSource محلي (مثل قاعدة بيانات محلية).

بهذا الشكل، يكون الـ Repository هو المسؤول عن تجميع البيانات من مصادر مختلفة وتقديمها بشكل موحد للطبقات الأعلى، بينما الـ DataSource يتعامل بشكل مباشر مع مصدر البيانات المحدد.

لو شغال Flutter 🚀، وهترفع App علي الـ Store او عندك Apps بالفعل، خلي بالك ان Google هتصنف برنامجك انه ليه bad behavior ⚠ لو الـ ANR عدي %0.47. اعرف ايه هو الـ ANR و 4 من ضمن الطرق عشان تتجنبه ⬇

الـ ANR (Android Not Responding) بيحصل لما الـ App بتاعك يحصله Freeze لمدة 5 ثواني، و بيطلع dialog للـ user يختار اذا كان يقفل الـ app او ينتظر، و طبعا دي من المواقف السيئة اللي ممكن تحصل في الـ app خاصة لو متكررة و دائما بتؤدي لخسارة جزء كبير من الـ user base بتاعتك من خلال انهم بيعملوا uninstall للـ app لو تكرر الـ freeze.

و Google في الـ documentation بتاعها بتقول:
Overall bad behavior: At least 0.47% of daily active users experience a user-perceived ANR across all device models.
و ده معناه انهم بيصنفوا الـ app انه ليه bad behavior لو الـ ANR Rate عدي الـ %0.47، يعني لو عندك 10,000 users استخدموا الـ App النهاردة، و 47 منهم طلعلهم ANR، يبقي الـ app ليه bad behavior.

💡 طبعا اسباب الـ ANR كتير وحلولهم اكتر، بس من اكثر الاسباب انتشارًا هو ان الـ UI بيكون complex ومحتاج يعمل render لـ widgets كتير في الـ screen و بيعملهم build كتير كل شوية وبسبب كده بيعمل block للـ Main Thread لفترة طويلة وبيحصل الـ ANR، لذلك دي 4 Tips هتساعدك تحسن الـ UI Performance في الـ app و تقلل الـ ANRs بدرجة كبيرة جدا لو طبقتها:

✅ 1. افصل كود الـ UI عن كود الـ Business Logic
بمعني انك مكتكبش الاكواد اللي بتعمل heavy work في الـ build() methods، لأن الـ build() بيتعملها call كل شوية عشان تعرض التغيرات اللي حصلت في الـ UI، الافضل انك تكتب كود الـ Business Logic في method لوحده و مش مربوطة مباشرة بالـ build() او انك تستخدم احد حلول الـ state management.

✅ 2. تجنب انك تعمل Single Widget و يكون كبير جدا و بيضم كذا جزء من الـ screen
عشان تتجنب انك تعمل build لجزء كبير من الـ widget tree، الافضل انك تقسم الـ screen ل sections او widgets صغيرة كل واحد فيهم مسؤول عن حاجة، بحيث انه لما يحصله update يتعمله build لوحده بدون اهدار للوقت والـ resources في عمل build للـ widgets التانية بدون حاجة.

✅ 3. استخدم const قبل كل constructor لأي widget مش هيتغير في الـ screen
و كل ما يكون متاح انك تستخدم الـ const، لأن const كأنك بتقول لـ Flutter و هو بيعمل rebuild للـ widget tree انه ميعملش build تاني للـ widget ده و هيسيبه زي ما هو بنفس حالته، و بكده هتوفر وقت و resources كتير جدا اثناء الـ build خاصة في الـ complex screens اللي فيها widgets كتير وبتفاصيل كتير.

✅ 4. استخدم StatelessWidget بدل الـ Function عشان تعمل Reusable Widget
لو عندك widget هتستخدمه كذا مرة في كذا مكان و هتخليه reusable، الأفضل انك تعمله StatelessWidget في Class بدل ما تعمله Function بيعمل return للـ widget، لأن الـ StatelessWidget اتصمم انه يعمل seamless integration مع الـ rendering pipeline، وغير كده انه بيكون فيه built-in caching techniques و ده بيحسن الـ performance. طبعًا الفرق مش هيبان في الـ widgets البسيطة والصغيرة، لكنه بيفرق جدا في الـ apps الكبيرة والـ complex screens.

اللَّهُمَّ صَلِّ عَلَى مُحَمَّدٍ، وَعَلَى آلِ مُحَمَّدٍ، كَمَا صَلَّيْتَ عَلَى إِبْرَاهِيمَ، وَعَلَى آلِ إِبْرَاهِيمَ، إِنَّكَ حَمِيدٌ مَجِيدٌ، وَبَارِكْ عَلَى مُحَمَّدٍ، وَعَلَى آلِ مُحَمَّدٍ، كَمَا بَارَكْتَ عَلَى إِبْرَاهِيمَ، وَعَلَى آلِ إِبْرَاهِيمَ، فِي الْعَالَمِينَ إِنَّكَ حَمِيدٌ مَجِيدٌ🤍

مهم ❤️

LinkedIn ✅️

https://www.linkedin.com/in/mazap64