سلام
دوستانی که توی open ai ثبت نام کردید و از chat gpt استفاده کردید...

در مورد روندش
اینکه از کجا شماره مجازی گرفتید
و هر نکته ی دیگه ای که فکر میکنید به درد میخوره...

لطفن کامنت ارزشمند تون رو زیر این پست بگذارید و تجربه ی خودتون رو بگید.

با تشکر 🙏

تو ورژن جدید Toastification شما میتونید message های خودتون رو با animation دلخواه نشون بدید

اگه براتون مفید بود یه استار برامون تو گیتهاب بزارید

https://github.com/payam-zahedi/toastification

@persian_flutter

⭕️بحث فلاتری

🟢در مورد پرفرمانس خیلی میشنویم.
میگن این اپه پرفرمانسش بالاس... اون یکی پایینه... و و و و...

🟢خب فلاتر یه فریمورک UI هست.
اینکه دقیقن هدف فلاتر به عنوان یه فریمورک UI چی هست رو بعدن صحبت میکنیم...

🟢ولی
❓وقتی با UI طرفیم، پرفرمانس دقیقن به چه معنی هست؟
❓توی فلاتر چطوری میتونیم تفسیرش کنیم؟
❓چه معیاری برای سنجش پرفرمانس میتونیم داشته باشیم و بر اساس اون اپ های مختلف رو با هم مقایسه کنیم؟

⚠️مشخصن در مورد رم و مدیریت حافظه صحبت نمیکنیم.
پس این موضوع رو باز نکنید.

@PureCoder_ir

🥺🥺مرز های تکنولوژی در نشست با جمعی از دانشمندان یک درصد برتر جهان دریده شد!!!!

پایتونیسم درد کلی جامعه ی ایرانه...

خواه قبول کنیم یا نکنیم...
خوشمون بیاد یا نیاد...

خوشحال باشیم یا ناراحت، بخندیم یا گریه کنیم، این جلسه و این اقای به ظاهر دانشمند و این صحبت ها، اینه ی تمام قد جامعه ی ماست...

⚡️چرخه حیات State ، مختصر ، کامل و دقیق⚡️

1⃣mount
اولین بار که یک stateful ساخته میشه و توی درخت قرار میگیره متد های زیر از state به ترتیب اجرا میشن :
State Constructor

initState
didChangeDependencies
build

❌توی هر سه متد بالا به context دسترسی داریم و میتونیم با context کار کنیم.
برخلاف تصور و اشتباه رایج خیلی ها که میگن داخل initState به context دسترسی نداریم.
🔥فقط اگه میخاستیم به یه inheritedWidget وابسته بشیم مثلن theme.of رو صدا بزنیم این کار رو باید توی دو متد didChangeDependencies یا build انجام بدیم.
🔥همیچنین توی متد های بالا با استفاده از پروپرتی widget میتونیم به ویجت این State دسترسی داشته باشیم.

2⃣setState
هر بار که توی استیت setState صدا زده بشه متد build یکبار دیگه اجرا میشه.

3⃣update
هر بار که ویجت parent این stateful این ویجت رو با یه کانفیگ جدید اپدیت کنه متدهای زیر اجرا میشن :
didUpdateWidget (Widget oldWidget)
build

ویجت parent این ویجت اپدیت شده و child خودش که همین stateful ما هست رو با یه ویجت جدید از همین type اپدیت کرده (ویجت ها immutable هستن)
در نتیجه didUpdateWidget اجرا میشه که به state اطلاع بده که ویجتت اپدیت شده.
توی ورودی هم ویجت قبلی (stateful قبلی /oldWidet) رو بهش میده.
ویجت جدید هم از طریق پروپرتی widget قابل دسترسیه.

4⃣dependencies changed
اگه این ویجت به یه InheritedWidget وابسته شده باشه مثلن Theme.of رو با context خودش صدا زده باشه.
هر بار که اون InheritedWidget اپدیت بشه و این اپدیت شدن رو به درخت زیر خودش نوتیف بده متد های زیر به ترتیب اجرا میشن :
didChangeDependencies
build

5⃣deactivate
هر بار که ویجت parent این ویجت تصمیم بگیره این نقطه از درخت رو با یه ویجت جدید جایگزین کنه یا کلن این ویجت رو حذف کنه و دیگه این ویجت بدردش نخوره این ویجت رو غیر فعال میکنه و از درخت حذف میکنه و در این مرحله متد زیر اجرا میشه :
deactivate

🔥در این مرحله هنوز متد dispose اجرا نمیشه و فقط deactivate اجرا میشه.

6⃣activate
اگه به این ویجت یه GlobalKey داده باشیم بعد از deactivate شدن ممکنه یه جای دیگه از درخت (با یه parent) دیگه به یه ویجت از این نوع و همین GlobalKey نیاز داشته باشه.
در نتیجه این ویجت activate میشه و توی اون نقطه از درخت مورد استفاده قرار میگیره و parent اش نسبت به قبل تغییر میکنه.(این اتفاق یعنی پیوند زدن به یه جای دیگه درخت حتمن باید توی همین فریم اتفاق بیفته که ویجت deactivate شده)
درنتیجه متد زیر توی state اجرا میشه :
activate
بعد از این متد هم متد
build
اجرا میشه و اگه این ویجت توی اجرای قبلی به یه inheritedWidget وابسته شده باشه قبل build هم متد زیر اجرا میشه :
didChangeDependencies
پس یا :
activate
build
یا
activate
didChangeDependencies
build
بسته به شرایط اجرا میشن.

7⃣unmount
اگه بعد از deactivate شدن و تا پایان این فریم این ویجت به هیچ جای دیگه پیوند نخوره (GlobalKey نداشته باشه یا لازم نشه که پیوند بخوره) متد زیر اجرا میشه :
dispose
و state برای همیشه میره پی کارش و غیر قابل استفاده میشه.

❌پس بلافاصله بعد از متد deactivate متد dispose اجرا نمیشه.
یه فاصله ای بینشون هست.
فاصله خیلی کم و در حد میلی ثانیه هست ولی بین اجرای این دو فاصله هست.

🔥همیشه قبل از dispose متد deactivate اجرا میشه ولی الزامن همیشه بعد از deactivate متد dispose اجرا نمیشه.

پس :
🔥توی initState هم به context دسترسی داریم.

🔥وابسته شدن به InheritedWidget رو حتمن توی didChangeDependencies یا build انجام میدیم.

🔥توی متد های deactivate و dispose کارهایی که مربوط به context میشه رو انجام نمیدیم (چون widget tree اون موقع statble نیست و در واقع این ویجت parent خودش رو از دست داده و parent نداره)

🔥کارهایی مثل dispose کردن کنترلر ها و ... رو توی متد dispose انجام میدیم و نه deactivate چون بعد از deactivate ممکنه دوباره به درخت برگرده و reperent بشه.

🔥در صورتی که ویجت GlobalKey داشته باشه (فقط GlobalKey) ممکنه بعد از deactivate شدن reparent بشه و به یه parent دیگه پیوند بخوره و مجددن activate بشه(که در این صورت state حفظ میشه)

#state_life_cycle

⭕️یک راه دیگه به غیر از const کردن برای جلوگیری از ریبیلد شدن ویجت وقتی که پرنتش ریبیلد میشه بگید 🤔

🔥مراحلی که فلاتر برای مقایسه دو ویجت توی بیلد های مختلف طی میکنه :

1⃣Reference Equality
در ابتدا چک میکنه که ایا دو ویجت رفرنس مشترک دارن یا نه.
اگه اینجوری باشه اون ویجت اصلن و ابدن ریبیلد نمیشه.

🔥میتونی مقاله ی انواع برابری دو ابجکت رو بخونی.
🔥یکی از راه های ایجاد رفرنس مشترک const کردن ویجت هست.

2⃣Type + Key
اگه رفرنس ها یکی نبودن، runtime type و key دو ویجت با هم مقایسه میشن.
اگر ویجت key نداشته باشه، مقدارش نال میشه و توی این مقایسه تاثیری نمیگذاره.

درصورتی که دو ویجت توی دو بیلد مختلف runtime type یکسان و key یکسان داشته باشن، state ویجت حفظ میشه و اون ویجت ریبیلد میشه و متد های زیر کال میشن :
✔️didUpdateWidget
✔️build

⚠️البته با فرض stateful بودن، اگه stateless هم باشه ویجت ریبیلد میشه و متد build کال میشه.

3⃣ create new ....

اگه مقایسه type و key به فنا بره و دو تا ویجت از این مقایسه سربلند بیرون نیان، ویجت قبلی کلن از درخت پرت میشه بیرون و یه دونه جدید ساخته میشه.

⚠️یه جاهایی باید از Element به جای ویجت استفاده میکردم که برای سادگی این کار رو نکردم.

@purecoder_ir

⭕️آدرس سایت:
https://purecoder.ir

⭕️گروه پرسش و پاسخ:
@purecoder_gp

⭕️کانال:
@purecoder_ir

⭕️پشتیبانی:
@PureCoder_support

🔥ویژگی های ویجت های فلاتر

1⃣ویجت ها immutable هستن.

🟢یعنی تمام instance field هاشون باید final باشه و بعد از ساخت یک ویجت دیگه نمیتونید اون رو اپدیت کنید و اگه خواستید یه ویجت جدید با ویژگی های جدید بسازید باید کلن یه دونه از اول بسازید.

🟢فرقی نمیکنه ویجت از چه نوعی باشه و در هر صورت باید immutable باشه.

🟢ویجت های stateful خودشون immutable هستن ولی یه state دارن که mutable هست.

2⃣درنتیجه ی immutable بودن، ویجت ها میتونن به const constructor مجهز بشن.

🟢یک شرط لازم (و نه کافی) برای اینکه یک کلاس const constructor داشته باشه اینه که immutable باشه و همه ی instance field هاش final باشن.

🟢پس یه ویجت میتونه const constructor داشته باشه به شرط اینکه شروط دیگه رو هم دارا باشه.
⚠️مقاله const constructor رو مطالعه کنید.

3⃣برای اینکه یه ویجت رو const کنیم علاوه بر مجهز بودن به const constructor موقع ساخت ابجکت (توی درخت) به جای new (پیش فرض) باید از const استفاده کنیم.

🟢برای const کردن باید همه ی ارگومان هایی که موقع ساخت ابجکت به constructor پاس میدیم const باشن.

🟢به این ترتیب امکان اینکه همه ویجت های ساخته شده const بشن عملن وجود نداره.

4⃣ویجت هایی که const نیستن، با هر بار ریبلید شدن درخت، یه ابجکت جدید ازشون ساخته میشه...

❓ایا اینکه با هر بار ریبیلد شدن درخت یه ابجکت جدید ازشون ساخته میشه مشکلی رو بوجود نمیاره؟

⚠️ممکنه برنامه نویس های فریمورک های دیگه این سوال رو ازتون بپرسن و باید بلد باشید که درست و دقیق جواب بدید و از فلاتر دفاع کنید.

@purecoder_ir

🔥declarative vs imperative

ویجت ها صرفن یه کانفیگ هستن.
برای نمونه شما به فلاتر میگی که یه باکس با این رنگ میخوام.
اگه خواستی رنگ باکس رو عوض کنی، ویجت قبلی رو اپدیت نمیکنی و کلن یه ویجت جدید میسازی و دوباره به فلاتر میگی که یه باکس با این رنگ میخوام.

خود فلاتر تمام کار ها رو انجام میده و یه باکس رنگی تحویلت میده و یا قبلی رو براساس کانفیگ جدیدی که بهش دادی اپدیت میکنه.

از این رو ویجت ها معمولن سبک هستن.

🟢به این سبک از برنامه نویسی declarative programming میگن.
🟢در مقابلش imperative programming قرار دارد.

🟢توی declarative شما میگی چی میخوای و به این که چطور اون چیزی که میخوای فراهم بشه کاری نداری (what)

🟢توی imperative اما به فرایند اهمیت میدی (how)

⭕️فلاتر از هر دو سبک استفاده کرده.

🟢برای نمونه وقتی با نویگیتور پوش و پاپ میکنیم داریم از imperative استفاده میکنیم.

@purecoder_ir

🔥انواع ویجت ها در فلاتر

✅StatelessWidget
✅StatefulWidget
✅InheritedWidget
✅RenerObjectWidget
✅ParentDatawidget

@purecoder_ir

🔥انواع ویجت ها در فلاتر

Widget__StatelessWidget
|
|__ StatefulWidget
|
|__ ProxyWidget
| |
| |___ InheritedWidget
| |
| |___ ParentDatawidget
|
|__ RenderObjectWidget
|
|__ LeafRenderObjectWidget
|
|__ SingleChildeRenderObj...
|
|__ MultiChildRenderObj...

@purecoder_ir

🔥انواع ویجت ها در فلاتر

✅نوع های Stateless و Stateful یه متد build دارن و subtree خودشون رو با استفاده از اون میسازن.

⚠️واضحه که برای stateful متد build توی ابجکت state قرار داره.

✅نوع proxy یه دونه child دارن و اون child در واقع subtree شون رو میسازه و خودشون شبیه به یه پروکسی عمل میکنن و subtree رو یه انگولکی میکنن.

✅نوع Render Object هم متد های
✔️createRenderObject
✔️updateRenderObject
دارن.

این ها سه تا ورژن دارن.

⭕️نوع Leaf یا برگ که مثل برک درخت هست و هیچ child ای نداره (subtree نداره)

مثل Image

⭕️نوع Single Child یه دونه Child میگیره و subtree ایش همون child اش میشه.

مثل Align یا ColoredBox

⭕️نوع Multi Child که چنتا child داره (List) و subtree های مختلف داره که هر کدوم از child ها یه شاخه ایجاد میکنن.

مثل Column یا Stack

🔥برگ های درخت فقط و فقط از نوع LeafRenderObjectWidget هستن و از انواع دیگه نمیتونن باشن.

🔥به غیر از MultiChildRenderObjectWidget بقیه تک شاخه ای هستن و فقط این نوع هست که چند شاخه ایجاد میکنه.
⚠️البته واضحه که نوع LeafRenderObjectWidget بدون شاخه هست.

@purecoder_ir

🔥RenderObjectWidget

🟢چند ماه پیش چالشی رو توی کانال گذاشتیم و یه انیمیشن ساده رو با هم طراحی کردیم.

🟢هر چند این انیمیشن رو خیلی ساده و با روش های دیگه هم میشه انجام داد ولی من به جهت جنبه ی اموزشی اومدم و به روش کاملن متفاوت پیادش کردم.

🟢یکی از کارهایی که انجام دادم طراحی یه RenderObjectWidget از پایه بود که از نوع LeafRenderObjectWidget بود.

🟢حالا که بحث انواع ویجت ها و RenderObjectWidget ها داغه، یه بار دیگه ادرس گیتهاب مربوط به این چالش رو میگذارم که با روند ساخت یه RenderObjectWidget از پایه اشنا بشید.

❓سوالاتت رو زیر این پست بپرس. 😍

⭐️توی گیتهاب هم یه استار بزن و باعث خشنودی قلبی من بشو که باعث میشه خدا ازت راضی باشه 😝

https://github.com/mohammadtaherri/multi_slice_progress_indicator

@purecoder_ir

🔥ParentDatawidget

🟢این نوع باید child مستقیم یا غیر مستقیم یه RenderObjectWidget باشن.

🟢میتونیم به ویجت Expanded که حتمن باید داخل column یا row قرار بگیره اشاره کنیم.
⚠️نری فقط Expanded رو نگاه کنی و بگی از این نوع نیست.
تا ته برو که برسی به Flexible.

🟢مثال دیگه ویجت Positioined که حتمن child مستقیم یا غیر مستقیم Stack باشه.

🟢این نوع ویجت ها فقط و فقط میتونن child یه RenderObjectWidget خاص باشن و دیگه نمیتونن به عنوان child ویجت های دیگه استفاده بشن.


🟢وقتی میگم child مستقیم یا غیر مستقیم یعنی چه؟

⭕️مستقیم یعنی مثلن Flexible مستقیم توی children یه Column قرار گرفته باشه.

⭕️غیر مستقیم یعنی خود Flexible توی یک یا چند ویجت Stateless یا Stateful پیچیده شده باشه و اون ویجت ها child ویجت Column شده باشن.

🟢یه قانون نانوشته این که باید child ویجت های MultiChildRenderObjectWidget بشن و زیاد معنی و مفهومی نداره که بخوان child ویجت های SingleChildeRenderObjectWidget ها بشن.

@purecoder_ir

🔥InheritedWidget

🟢این نوع ویجت خیلی معروفه و خیلی در موردش صحبت شده و نیازی به توضیح بیشتر نیست.

🟢این نوع رو میتونیم به عنوان سولوشن فلاتر برای مدیریت استیت تلقی کنیم.

🟢سوالات راجع به این نوع رو توی کامنت ها بپرسید.

⭕️البته این ویجت میتونه مدل های مختلفی داشته باشه, از جمله :

InheritedWidget
|
|___ InheritedModel
|
|___ InheritedNotifier

🟢ویجت هایی مثل Theme یا MediaQuery یا... در نهایت از این نوع هستن.

@purecoder_ir