در زمان توسعه اپلیکیشن‌های فلاتر، باید اطمینان پیدا کنیم که ویجت‌ها تا حد امکان قابلیت استفاده مجدد دارند. بدین ترتیب ویجت‌ها تا حد امکان از هر نوع منطقی آزاد باقی می‌مانند. در این نوشته به بررسی برخی تکنیک‌های گردش داده و نمایندگی رویداد در فلاتر می‌پردازیم که موجب می‌شود اپلیکیشن‌های فلاتر انعطاف‌پذیری بیشتری یافته و پیوند کمتری با منطق پروژه داشته باشند.

گردش داده

یک سناریوی معمول در اپلیکیشن‌های فلاتر، دانلود کردن داده‌ها از شبکه و سپس نمایش آن روی صفحه است. یکی از رویکردهای ممکن برای اجرای این سناریو، ارسال درخواست شبکه در یک ویجت و سپس دانلود کردن داده‌ها است. این رویکرد به صورت زیر پیاده‌سازی می‌شود:

مشکل رویکرد فوق این است که پیوند زیادی با CustomerList و همچنین با داده‌های آرایه دارد. این بدان معنی است که CustomerList نمی‌تواند داده‌ها را از والد گرفته و نمایش دهد. بدین ترتیب صرفاً می‌تواند روی آرایه اعلان‌شده درون ویجت CustomerList کار کند و امکان استفاده از آن در سناریوهای دیگر وجود ندارد.

یک روش بهتر برای مدیریت این سناریو این است که داده‌ها از والد به ویجت CustomerList ارسال شوند و سپس نمایش یابند. این رویکرد در کد زیر پیاده‌سازی شده است:

این کد مشابه نسخه قبلی است، اما یک تفاوت مهم دارد. این بار داده‌ها را به ویجت CustomerList ارسال می‌کنیم و ویجت CustomerList تنها برای نمایش داده‌ها استفاده می‌شود و کاری به جز آن ندارد. این بدان معنی است که CustomerList مسئول واکشی کردن داده‌ها نیست. تنها مسئولیت این ویجت نمایش دادن داده‌ها است. CustomerList می‌تواند به سادگی در صفحه‌های دیگر استفاده شود و در این حالت می‌توان مجموعه متفاوتی از داده‌های مشتری را به ویجت ارسال کرد. در زمان توسعه اپلیکیشن‌های فلاتر باید اطمینان پیدا کنیم که داده‌ها از والد به فرزند ارسال می‌شوند.

گردش داده و نمایندگی رویداد در فلاتر

نمایندگی

ویجت‌ها صرفاً برای نمایش داده‌ها استفاده نمی‌شوند، بلکه می‌توانند رویدادهایی نیز ایجاد کنند. زمانی که رویدادها در ویجت فرزند ایجاد می‌شوند، بهتر است «نمایندگی رویداد» (Event Delegation) را به والد بدهیم تا اکشن مناسب را اجرا کند. کد زیر را که در آن ویجت CustomerList یک اکشن روی رویداد onTap مربوط به ListTile انجام می‌دهد در نظر بگیرید:

مشکل رویکرد فوق آن است که ویجت CustomerList اکنون به طور کامل با اکشن ‎_navigateToCustomerDetailsScreen پیوند یافته است. روش بهتر آن است که به والد اجازه دهیم تصمیم بگیرد در زمان تپ شدن ویجت، می‌خواهد چه کاری انجام دهد. پیاده‌سازی آن به صورت زیر است:

این رویکرد بسیار بهتر است، زیرا اکنون نمایندگی رویداد به والد داده شده است و بدین ترتیب والد بهتر می‌تواند در مورد کاری که می‌خواهد انجام بدهد، تصمیم‌گیری کند. این وضعیت موجب می‌شود که CustomerList انعطاف‌پذیری بیشتری پیدا کند، چون اکنون می‌تواند نیازهای والدهای مختلفی را برآورده سازد.

سازمان‌دهی و نام‌گذاری

ساختار اپلیکیشن به راهنماهایی که شرکت ارائه می‌کند، بستگی دارد. ما پس از تحقیق و خواندن کد توسعه‌دهندگان مختلف مجموعه راهنمایی‌های کوچک زیر را جمع‌بندی کرده‌ایم:

  • نام‌گذاری فایل‌های دارت به شیوه «حالت ماری» (snake case) باشد. برای نمونه از نام customer_list.dart استفاده کنید.
  • Page نشان‌دهنده صفحه‌های اپلیکیشن باشد که شامل ویجت‌ها می‌شود. برای نمونه HomePage ،CustomerListPage و غیره.
  • هر نوع از کلاس‌ها در پروژه در پوشه مجزایی سازمان‌دهی شوند، برای نمونه صفحه‌ها، ویجت‌ها، سرویس‌ها و غیره.

سخن پایانی

در این مقاله با گردش داده‌ها در اپلیکیشن فلاتر آشنا شدیم و پیشنهاد کردیم که ارتباط فرزند به والد با استفاده از الگوی نمایندگی مناسب خواهد بود. امیدواریم از مطالعه این رهنما بهره آموزشی لازم را برده باشید.

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

==

میثم لطفی (+)

«میثم لطفی» دانش‌آموخته ریاضیات و شیفته فناوری به خصوص در حوزه رایانه است. وی در حال حاضر علاوه بر پیگیری علاقه‌مندی‌هایش در رشته‌های برنامه‌نویسی، کپی‌رایتینگ و محتوای چندرسانه‌ای، در زمینه نگارش مقالاتی با محوریت نرم‌افزار نیز با مجله فرادرس همکاری دارد.

آیا این مطلب برای شما مفید بود؟

نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *