Flutter & Dart ✨️

صباح الخير ..

انا بقالي فتره كبيره بعيد عن كتابة المحتوى الخاص ب Flutter لكني هشارككم النهارده تجربتي مع استخدام Provider في مشروع متوسط الحجم وهقدملك كتير من المعلومات اللي هتحتاج تعرفها فاقرا البوست للاخر للأهمية..

لو انت لسه مبتدئ ف غالبا الكلام هيكون صعب عليك شويه.

كان قراري الشخصي باستخدام ال Provider ليه عدة اسباب منها:

ارتياحي لل architecture اللي بيقوم عليه ال Provider واللي بيشبه الطريقة اللي Flutter بتستخدمها علشان تعمل Update لل widget state.
ال Code Flexibility اللي بيقدمها ال Provider واللي بتتيحلك استخدامه في اكتر من مكان داخل المشروع "بشرط تنظيم الكود".
مكانش عندي تخوفات من قدرة ال Provider انه يشيل مشروع بحجم متوسط.

أماكن استخدام ال Provider داخل المشروع:
إستخدام ال Provider كان في مكانين:
أول مكان في ال View layer فيه مجموعة Providers منفصلين تماماً عن ال View model layer الغرض منها بس هندلة التغييرات اللي بتحصل ف ال widgets اللي مابتحتاجش اي نوع من انواع الداتا اللي موجوده في ال model ولا كمان بتحتاج تدخل من ال handlers لعدم وجود heavy logic to organize يعني ببساطة هو بس موجود علشان يتحكم في ال widgets اللي كل تغييراتها قائمة على ال UI بعيد تماما عن ال data وال business logic وتعقيداتها. ودي حجمها صغير مقارنة بالاستخدام التاني.
تاني مكان وهو الاستخدام الحيوي لل Providers في view model layer .. مجوعة كبيرة من ال Providers اللي بيحتوي على ال business logic واللي بيدير بشكل كبير أغلب ال behaviors جوه الأبليكيشن واللي كلامي هيكون عنهم.

المميزات:
طبيعة ال provider انه singleton مكننا من استغلال النقطه دي لصالحنا في كتير من المواضع اللي بتستخدم نفس ال value في اكتر من مكان زي مثلاً احتياجنا ل token holder ثابت طول ال user journey ولحد ما يقفل الابليكيشن.
سهولة التعامل مع التغييرات وصغر حجم الكود اللي بتكتبه علشان تقدر تعمل set وانك مش بتحتاج مجهود كبير علشان تقدر تعمل retrieve & update واللي بتحصل بشكل instant و efficient.
مرونة الكود اللي تقدر تكتبه جوه ال Provider class واللي تقدر تكتب فيه كل ال Business logic بتاعك بشرط انك تراعي ال SRP علشان الكود بتاعك من السهل جدا انه يبقى messy code.

العيوب:
في كتير من الأوقات هتحتاج تستخدم ال Provider داخل ال initState ولكن مش هتعرف لانه بيحتاج context وده مش بيكون متوفر في ال init فبيكون قدامك حل من اتنين ..
1- انك تستخدمه داخل ال didChangeDependencies وده مش دايماً أفضل حل بسبب ال Unexpected behavior اللي ممكن تقابله لو انت مش فاهم طبيعة ال didChangeDependencies.

2- انك تستخدمه داخل ال init من خلال Future.delayed أو WidgetsBinding وده الحل الأفضل من وجهة نظري.
ال Provider ليست controller قائمة بذاتها بمعنى ان قدرة ال Provider لو انت عايز تستخدمه as orchestrator ضعيفه جداً وبيحتاج Orchestrator layer فوقيها لأسباب كتيره منها:
- ال Provider مايقدرش يكلم other provider بشكل مباشر فهتحتاج orchestrator تباصيله ال Providers اللي هيستخدمها كنوع من أنواع ال method dependency injection.
- الكود بتاعك هيبقى messy code لو مفيش layer تجبر الكود انه يبقى one direction flow والوضع هيزداد سوء كل ما زاد عدد ال features وتداخلها لدرجة انه ممكن يعقد عملية تعديل أو مسح أي كود مكتوب.
ضرورة انتباهك للوقت اللي تستخدم فيها listen: false نظرا لكون ال default قيمته true.

باختصار:
ال Provider ممتاز جداً .. سهل وسريع وبسيط.
لو مش فاهم طبيعة ال Provider هتلاقي نفسك بتسئ استخدامه في كتير من الأوقات بسبب ال Flexibility.
ال Provider بيحتاج layer فوقيه تنظم كل ال events علشان تقدر تستفيد منه الاستفاده القصوى من غير ما تكتب كود متداخل وغير مرتب.

ده كان نظرة عامة وخلاصة تجربة ان شاء الله تفيدك وشرفني برأيك لو شايف حاجه غلط.
#flutter #provider
#منقول

4.6K views09:10

Flutter & Dart ✨️

مساء الخير
هتكلم النهارده شوية عن Dart وفي نهاية البوست هتلاقي challenge بسيطه لو حليتها فانت مش محتاج تقرا البوست.

مفهوم ال asynchronization في لغة Dart:
كتير من اللغات بتقدر تحقق مفهوم ال parallelism عن طريق انها تستخدم ال multithreading بمعنى انه يكون فيه اكتر من thread بيتشاركوا نفس المكان من ال memory وكل thread تشتغل على تاسك منفصله وبالتالي الوقت الكلي المستخدم لتنفيذ N من التاسكات في وجود N من ال threads هيساوي نفس الوقت المستخدم لتنفيذ تاسك واحده فقط وده طبعًا بيعلي السرعه والكفاءة.
للأسف Dart مش واحده من اللغات دي رغم انها بتديلك الإمكانية انك تعمل ده ولكن ده مش الشكل الافتراضي ليها ولا ده موطن قوة dart وده اللي بيصعب على Flutter بناء تطبيقات بتستخدم resources كبيره من ال cpu زي انك تعمل image processing لان النوعيه دي من التاسكات بتحتاج انها تستخدم كل cpu core ممكنه.
طيب ازاي Dart بتقدر تنفذ async tasks رغم كونها بتشتغل على thread واحده ؟
بتقدر تنفذ ده عن طريق استخدام event queue ينظم عملية دخول ال events بكل انواعها سواء كانت I/O event او cpu event او Future event وهنا بييجي دور ال event loop في انها تعمل processing للايفنت اللي عليه الدور لو كان sync فبتنفذه وتدخل على التاسك اللي بعده ولو كان Future فبتركنه لحد ما يحصلها hock trigger يقولها ان ال Future خلص ومستني processing.

من الاخر يعني Dart مش بتميز بين ال events ومش بتضطرك تكتب كود ولا تعمل مجهود علشان تقدر تنفذ async task لان ال event loop ذكيه كفايه انها تقدر تفهم انها مش محتاجه تستنى event ممكن ياخد ثواني على ما يحصل في حين انه لغات زي java و swift بيضطروك تكتب ال async task بطريقه معينه لانهم بيستخدموا ال multithreading فبيخلوا كل Async task تشتغل في thread منفصله علشان مايحصلش lock لل main thread وهي بتستنى ال Future انه يخلص.
بمعنى ان Dart مش بتحقق مفهوم ال parallelism ولكنها بتحقق مفهوم مشابه لل parallelism اسمه ال concurrency.
ال event loop بتتعامل مع التاسكات بالترتيب ده (من الأسرع للأبطأ)
1- sync task: print("task");
2- async microtask: Future.microtask(()=>print("microtask"));
3- async task: Future(()=>print("async task"));

بعد ما عرفت كل ده خليني اقولك ان Dart بتستخدم حاجه اسمها isolate وهي زي ال thread ولكنها مختلفه في ان كل isolate ليها dedicated memory خاصه بيها هي فقط وبتتيحلك انك تستخدم multi isolates سواء عن طريق ال low level كود من خلال spawn أو الأفضل تستخدم ال Function اللي وفرتها Flutter واللي هي compute ولكنها محدوده بعض الشئ في استخداماتها وبتحط عليك restrictions لانه زي ماتفقنا دي مش موطن قوة Dart.

وأخيراً حاول تحل ال challenge البسيطه دي علشان تتأكد انك فهمت كلامي أو اسألني فيه.
void main() async{
print("A");
await Future((){
print("B");
Future(()=>print("C"));
Future.microtask(()=>print("D"));
Future(()=>print("E"));
print("F");
});
print("G");
}

#flutter
#شرح

#منقول

3.6K views13:08

Flutter & Dart ✨️

يسعد أوقاتكم بكل الخير, بدايةً قبل قراءتك للمنشور علّق بالصلاة على النبي, ثم أكمل قراءة.

التحديثات الجديدة الخاصة بالدارت وفلاتر دسمة جدًا وكثيرة ولا يمكن إجمالها بمنشور, لذلك اليوم سنتحدث عن تحديثات الدارت فقط.

جديد لغة دارت 3.0
أولًا:
Dart Portability:
أصبح بالإمكان ترجمة أكواد dart للعمل على بيئتين جديدتين:
1. Linux RISC-V
2. WebAssembly
وحنتكلم عن الWebAssembly (WASM).
زي ما أنتوا عارفين المشاريع المكتوبة بفلاتر يمكن ترجمتها للعمل على بيئات متعددة, وكذلك يمكن إنشاء تطبيق ويب منها.

دارت يترجم أكواده لما يقابله بالjs كون المتصفحات تتعامل مع الجافاسكريبت (وليس الدارت).

الجديد هنا أنه أصبح بالإمكان تحويل المشروع ل WebAssembly للحصول على أداء أسرع وثقل أقل على الرام.

ثانيًا: Patterns
المقصود بها طرق كتابة أكوادك بشكل أكثر تعبيرًا.

تحديث 1: multiple returns
ويقصد بها أن تعيد أكثر من ناتج للميثود. (بديل الtuple).
لو افترضنا أنك تريد إرجاع بيانات سيارة من ميثود ما (الاسم وسنة الانتاج),
الطريقة الأولى والقديمة أنك تعمل class, وتعرف فيه الاسم وسنة الانتاج, ثم تنشء منه object وتسند له القيم وترجعه للميثود.
class Car{
final String name;
final int year;
Car(this.name,this.year);
}

Car someMethod(String name){
var car = Car(name,2013);
return car;
}

void main(){
var car = someMethod('skoda');
print('${car.name} ${car.year}');
}

الجديد الآن تستطيع إرجاع أكثر من قيمة معًا.
بديل الكود السابق بنفس الناتج:

(String,int) someMethod(String name){
return (name,2013);
}

void main(){
var car = someMethod('skoda');
print('${car.$1} ${car.$2}');
}

أو

void main(){
var (name,year) = someMethod('skoda');
print('$name $year');
}

تحديث 2:
بالإصدارات السابقة كنا نستخدم الif/else في تخصيص List وقت كتابة الكود.
الآن أصبح استخدام if/else على الnamed arguments بنفس الطريقة.
مثال:
ListTile(
title:Text('Some list tile'),
if(enableSubtitle)
...(subTitle:Text('Some subtitle')));

تحديث 3:
الswitch/case كانت تتطلب أمرين:
الأول أنك تمرر constants لcases
الثاني أنك تنهي كل case ب break;

الأمر الأول, أصبحت الcase أكثر مرونة,
مثلًا:
void someMethod(){
switch(something){
case condition1:
..
case condition2:
...
case condition3 when condition 4:
...
default:
...
}
}

الأمر الثاني, بالنسبة لجملة break; سيتم الاستغناء عنها نهاية الcase. لأنها فعليًا بدون معنى ولا قيمة (بس هما ضافوها من باب هذا ما وجدنا عليه آباؤنا).

الأمر الثالث:
بالإمكان دمج أكثر من case بنفس الcase بدلًا من أسطر متتابعة:
مثلًا
switch(someThing){
case condition1:
case condition2:
case condition3:
//your code
}

يمكن كتابتها كذلك:

switch(someThing){
case condition1 condition2 condition3:
//your code
}
مثل ما أشرنا بالأعلى أصبحت مرنة ولا تتطلب وسيطات ثابتة.

الأمر الرابع:
بالإمكان استخدام معاملات المقارنة مباشرة بدون الإشارة كل مرة للمتغير اللي داخل switch:
مثلًا:
switch(age){
case age<5:
...
case age>5 && age <10:
...
}

صار ممكن اختصارها كالتالي:
switch(age){
case <5:
...
case >5 && <10:
...
}

تحديث 4:
تفنيط (فكفكة الjson) والتعامل معه - json
destructuring
لاحظ هالمثال:
var json = {'car':['skoda',2013]};

switch(json){
case {'user':[String name,int year]}:
print('The car $name made in $year');
default:
print('Unkown json pattern');
}

تحديث 5:
تفنيط الObject والتعامل معه: Object destructuring
لاحظ هالمثال:
var cars = {'Skoda':2013, 'Kia':2019};
for(var MapEntry(:name,:year) in cars.entries)
{
print('$name made in $year');
}

هذا جزء من التحديثات المعلنة علمًا بأن النسخة 3.0 من الدارت لم تنزل stable بل ما زالت في dev channel.

بالتوفيق لكم, ولا تنسى تعلّق بالصلاة على النبي - صلى الله عليه وسلم-.

#flutter_forward
#dart_updates
#منقول

3.4K views19:20

Flutter & Dart ✨️

Job title: Senior or (semi-Senior) Flutter Developer
Job type: Full-time
Work location: remote
Required Skills:
good understanding of OOP, SOLID principles, and design patterns.
at least 2+ years experience as a flutter developing
Experience with Restful APIs, Push Notification, Getx, Bloc, and Google maps.
Deployed at least 1 app to Play & App stores
experience working with source control like GitHub.
please send your cv to: mostafadeve@gmail.com

#jobs #flutter #dart

4.0K views19:14