فلاتر یک SDK برای ساخت اپلیکیشنهای موبایل است که از سوی گوگل ارائه شده و به ایجاد اپلیکیشنهای مدرن همراه برای iOS و اندروید با استفاده از کدبیس (تقریباً) یکسان کمک میکند. فلاتر در زمینه محیطهای توسعه اپلیکیشنهای موبایل چند پلتفرمی یک تازهوارد محسوب میشود و برخلاف دیگر فریمورکها مانند React Native از جاوا اسکریپت استفاده نمیکند، بلکه از DART به عنوان زبان برنامهنویسی خود بهره جسته است. در این مطلب به معرفی روش ایجاد منوهای کشویی در فلاتر میپردازیم.
اگر میخواهید با فریمورک فلاتر بیشتر آشنا شوید، پیشنهاد میکنیم ابتدا مطلب جامع گوگل فلاتر (Flutter) از صفر تا صد — ساخت اپلیکیشن به کمک ویجت را مطالعه کنید.
منوی کشویی در اپلیکیشنهای همراه، یک صفحه کناری است که عموماً شامل آیتمهای منو است و در زمان باز شدن حدود نیمی از صفحه را اشغال میکند. اگر تاکنون از اپلیکیشنهایی مانند توییتر یا Gmail استفاده کرده باشید، حتماً میدانید که در مورد چه چیزی صحبت میکنیم.
برای ساخت یک منوی کشویی ابتدا باید یک منوی خالی ایجاد کنیم. به این منظور همانند همه اپلیکیشنهای فلاتر که از طراحی متریال برخوردار هستند، یک MaterialApp پایه ایجاد خواهیم کرد. این MaterialApp زمینهای است که یک Scaffold را با Drawer در خود جای خواهد داد.
کد یک MaterialApp پایه به صورت زیر است:
در کد فوق، DWidget یک ویجت است که منوی کشویی ما را در خود جای خواهد داد. لازم به ذکر است که drawers بخشی از Scaffold به همراه appBar و body هستند. زمانی که drawer را به Scaffold اضافه کردید، یک آیتم منوی سه خطی روی گوشه چپ-بالای نوار اپلیکیشن ایجاد میکند که با کلیک روی آن میتوانید صفحه drawer را مشاهده کنید.
کد ابتدایی آن به صوت زیر است:
این کد یک اپلیکیشن میسازد که یک منوی کشویی خالی ابتدایی مانند تصویر زیر ایجاد میکند:

همان طور که احتمالاً متوجه شدهاید، drawer مقادیر :child (و نه :children) میپذیرد و این بدان معنی است که هر زمان میتوانیم تنها یک ویجت درون drawer خود داشته باشیم.
برای این که بتوانیم بیش از یک ویجت داشته باشیم، باید از ویجتهایی مانند Column استفاده کنیم که قادر به نگهداری از چند ویجت فرزند هستند. کد drawer زمانی که حاوی ویجت Column باشد به صورت زیر خواهد بود:
این کد سه خط متن را در drawer نمایش میدهد.
اکنون میدانیم که drawer-ها چه هستند و چگونه ایجاد میشوند. با این وجود اگر بخواهیم منوهای کشویی خود را با منوهای کشویی اپلیکیشنهای توییتر و جیمیل مقایسه کنیم، متوجه خواهیم شد که آن drawer-ها همواره به همراه یک هدر ارائه میشوند که تقریباً 20 درصد از فضای فوقانی منو را اشغال میکند.
در فلاتر، میتوانیم هدر مشابهی را با استفاده از ویجت DrawerHeader ایجاد کنیم. این ویجت یک child میگیرد و امکان تزیین هدر را به ما میدهد. در مثالی که در ادامه ارائه شده است از DrawerHeader استفاده کردهایم، به طوری که میتوانیم مرز کامل ویجت را تمییز دهیم. کد DrawerHeader به صورت است:
اکنون منوی کشویی ما به صورت زیر در آمده است:

البته مطمئناً از این که میبینید هدر تمام فضای منو را اشغال کرده است شگفتزده شدهاید، در حالی که به طور معمول باید 20 درصد فضای فوقانی منو را اشغال کند. دلیل وقوع این وضعیت آن است که child در drawer تنها یک DrawerHeader دارد و هیچ عنصر دیگری هنوز اضافه نشده است.
برای جابجایی هدر drawer به سمت بالای منوی کشویی، باید از ویجتهایی مانند Column یا ListView استفاده کنیم که شامل چندین ویجت هستند. ما قصد داریم از ListView در اینجا استفاده کنیم چون Column همه فضای موجود را به صوت یکسان اشغال نمیکند و بدین ترتیب بخشهایی از فضای اشغال نشده روی صفحه باقی میگذارد. روش استفاده از ListView درون یک Drawer به صورت زیر است:
نتیجه نوشتن کد فوق در اپلیکیشن حاصل، به صورت زیر خواهد بود:

اکنون به چیزی که به دنبالش بودیم، دست یافتیم. این وضعیت به هدر منوهای کشویی اپلیکیشنهایی مانند جیمیل و توییتر نیز شبیه شده است.
اینک میتوانیم هدر را به هر ترتیبی که میخواهیم تزیین کنیم و به این منظور آیتمها و لینکهای زیادی وجود دارند. در مورد تزیین هدر در مطالب بعدی صبحت خواهیم کرد؛ در این نوشته توجه خود را معطوف به تکمیل کارکرد منوی کشویی و افزودن برخی آیتمهای کاربردی میکنیم.
از آنجا که میخواهیم برخی کاربردها در زمان انتخاب (یا تپ کردن) آیتمهای منوی کشویی اجرا شوند باید از ویجتهایی استفاده کنیم که بتوانند متد onTap را مدیریت کنند. در غیر این صوت باید یک کانتینر پیرامون ویجتهایی که ژستها را مدیریت میکنند ایجاد کنیم.
با این وجود، استفاده از دستگیره توکار onTap در این مثال ارجحیت دارد، زیرا استفاده از آن آسانتر است. ویجتی که میتوان درون ListView استفاده کرد ListTile نام دارد. در ادامه چند آیتم را با استفاده از ListTile ایجاد میکنیم و اکشنهای متناظر را با استفاده از متد ()onTap اضافه میکنیم. اکشنهای زیادی وجود دارند که میتوان روی ()onTAP اضافه کرد و در اغلب موارد هدف ما بارگذاری یک صفحه جدید با ()onTAP است.
در این بخش چند صفحه (یعنی ویجت) ایجاد میکنیم و آنها را در نتیجه یک اکشن از سوی کاربر نهایی روی منوی کشویی بارگذاری میکنیم.
این صفحهها را با اکشن ()onTap روی LostTile بارگذاری میکنیم. بدین ترتیب کد کامل منوی کشویی به صورت زیر درمیآید:
روش کارکرد اکشنها در اپلیکیشن در این زمان به صورت زیر است:

اینک ما موفق شدیم صفحههای جدیدی را با کلیک روی آیتمهای منوی کشویی بارگذاری کنیم؛ با این وجود زمانی که تلاش کنیم به صفحه اصلی بازگردیم، میبینیم که منوی کشویی همچنان در آنجا حضور دارد. این وضعیت در تصویر فوق نیز مشخص است. این وضعیت آزاردهندهای است، زیرا ما نمیخواهیم منوی کشویی در آنجا باقی بماند؛ مگر این که آنها را به طور صریح مجدداً بارگذاری کنیم.
برای رفع این مشکل باید پیش از بارگذاری صفحه حدید از سوی ()Navigator.pop، منوی کشویی را حذف کنیم. بدین منظور باید کد ()onTap را به صورت زیر بنویسیم:
بدین ترتیب هنگامی که صفحه نهایی باز میشود، منوی کشویی در صفحه اصلی باقی نمیماند.

در زمان طراحی اپلیکیشن، عموماً قصدمان بر این است که اکشنهای رایج را روی منوی کشویی قرار دهیم و لذا منوی کشویی باید در همه صفحههای اپلیکیشن حضور داشته باشد. این کار از طریق اطمینان یافتن از این که منوهای کشویی روی همه Scaffold-ها در همه صفحههای اپلیکیشن وجود دارند، میسر خواهد بود.
معنی عملی گفته فوق این است که میتوانیم کد drawer را در ویجتهای «بیحالت» (Stateless) مجزا به صورت زیر داشته باشیم:
و از کد زیر درون ویجتهای خود به همراه Scaffold استفاده کنیم:
اپلیکیشن حاصل، منوهای کشویی خواهد داشت که روی همه صفحهها در دسترس ما قرار دارند:

بدین ترتیب به پایان این نوشته با موضوع معرفی منوهای کشویی در اپلیکیشنهای فلاتر میرسیم. امیدواریم از مطالعه این مطلب بهره آموزشی لازم را کسب کرده باشید. شما میتوانید هرگونه دیدگاه یا پیشنهاد خود را در بخش نظرات این نوشته با ما و دیگر خوانندگان مجله فرادرس در میان بگذارید.
منبع: فرادرس
پایتون یک زبان زیبا است و در عین این که استفاده از آن ساده محسوب میشود ساختار کاملاً گویایی دارد. اما آیا با همه امکانات این زبان برنامهنویسی آشنا هستید؟ قابلیتهای پیشرفته هر زبان برنامهنویسی عموماً از طریق به کارگیری گسترده و طولانیمدت آن زبان به دست میآیند. برای نمونه، شاید تاکنون در زمان کدنویسی یک پروژه پیچیده مجبور به جستجوی چیزی در وبسایت stackoverflow شده باشید. در این موارد ممکن است به راهحل زیبایی برای مسئله خود دست یافته باشید که در آن از یک قابلیت پیشرفته پایتون استفاده شده است و شما نیز تا به حال هرگز آن را مورد استفاده قرار ندادهاید.
این روش کشف از طریق کاوش و تصادف، مسلماً یکی از جالبترین روشهای یادگیری محسوب میشود.
در این مقاله 5 قابلیت پیشرفته پایتون را معرفی میکنیم که کاملاً مفید هستند و مهمتر از آن این است که روش استفاده از آنها را نیز مورد بررسی قرار خواهیم داد.
تابع «لامبدا» (Lambda) یک تابع ناشناس یا بینام کوچک است. منظور از بینام در اینجا آن است که عملاً هیچ نامی برای تابع تعیین نشده است. تابعهای پایتون به طور معمول با سبک زیر تعریف میشوند:
اما تابعهای لامبدا هیچ نامی نمیگیرند. دلیل این کار آن است که مقصود از تعریف تابعهای لامبدا، اجرای نوعی عبارت یا عملیات ساده است که نیازی به تعریف یک تابع کامل وجود ندارد.
تابع لامبدا میتواند هر چند آرگومان که لازم است بگیرد؛ اما در اغلب موارد تنها یک عبارت دارد:
همان طور که میبینید تعریف این تابع بسیار آسان است. در کد فوق یک محاسبه ریاضی مقدماتی را بدون نیاز به تعریف کامل تابع اجرا کردهایم. این یکی از قابلیتهای فراوان پایتون است که موجب میشود بتوانیم به روشی تمیز و سادهسازی شده از این زبان برنامهنویسی بهره بگیریم.
()Map یک تابع توکار پایتون است که برای اِعمال تابعی روی یک دنباله از عناصر مانند لیست یا دیکشنری استفاده میشود. این تابع کاملاً سرراست است و مهمتر از آن، این است که چنین عملیاتی را به روشی «مطمئن» اجرا میکند.
مثال فوق را بررسی کنید. ما میتوانیم تابع خود را روی یک لیست منفرد یا لیستهای چندگانه به کار بگیریم. در واقع، میتوان از یک map روی هر نوع تابع پایتون که فکرش را بکنید استفاده کرد. تنها شرط این کار آن است که آن تابع با دنباله عناصری که عملیات روی آنها اجرا میشود سازگار باشد.
تابع توکار filter در پایتون کاملاً مشابه تابع Map است، چون یک تابع را روی یک دنباله (لیست، چندتایی، دیکشنری) اعمال میکند. تفاوت کلیدی این است که ()filter تنها عناصری را بازمیگرداند که تابع اعمالشده مقادیر true برای آنها بازگشت دهد.
برای توضیح بیشتر کد مثال زیر را بررسی کنید:
ما در کد فوق نهتنها درست یا نادرست بودن هر عنصر لیست را بررسی کردهایم؛ بلکه تابع ()filter از این نکته نیز اطمینان حاصل کرده است که تنها عناصری بازگشت مییابند که به صورت درست ارزیابی شدهاند. این تابع برای مدیریت آسان دو مرحلهی بررسی یک عبارت و ساخت یک لیست بازگشتی کاملاً مناسب است.
ماژول Itertools پایتون، مجموعهای از ابزارها برای مدیریت تکرارکنندهها است. منظور از تکرارکننده (iterator) نوع دادهای است که میتواند در یک حلقه استفاده شود و شامل لیست، چندتایی و دیکشنری است.
استفاده از تابع در ماژول Itertools امکان اجرای عملیات مختلف تکرارکننده را به ما میدهد که به طور معمول نیازمند تابعهای چندخطی و «خلاصهسازی لیست» (list comprehension) پیچیده بودند. کد مثال زیر را برای درک بهتر ویژگیهای فوقالعاده Itertools ملاحظه کنید:
تابعهای Generator امکان اعلان یک تابع را به ما میدهند که مانند یک تکرارکننده عمل میکند، یعنی میتواند در یک حلقه استفاده شود. این وضعیت موجب میشود که کد تا حد زیادی سادهتر شود و کارایی حافظه آن نسبت به حلقههای for ساده بسیار بالاتر است. برای نمونه تصور کنید میخواهیم همه اعداد 1 تا 1000 را با هم جمع کنیم. بخش نخست کد زیر شیوه انجام این کار را با استفاده از حلقه for نشان میدهد:
این کد در مواردی که لیست کوچک است، مثلاً در صورت وجود 1000 عدد عملکرد مناسبی دارد. مشکل زمانی بروز پیدا میکند که بخواهیم لیست بسیار بزرگی، برای مثال 1 میلیارد عدد اعشاری را با هم جمع کنیم. در این حالت اگر از یک حلقه for استفاده کنیم، حجم بالایی از حافظه از سوی لیست ایجاد شده در حافظه اشغال میشود. همه افراد به RAM نامحدود دسترسی ندارند تا چنین چیزی را ذخیره کنند. تابع ()range در پایتون همین کار را انجام میدهد و لیست را در حافظه میسازد.

بخش دوم کد فوق روش جمع کردن لیستی از اعداد را با استفاده از generator پایتون نمایش میدهد. یک generator تنها زمانی که لازم باشد، عناصر را میسازد و آنها را در حافظه ذخیره میکند و این کار را به صورت یک به یک انجام میدهد. این بدان معنی است که اگر مجبور باشید 1 میلیارد عدد اعشاری ایجاد کنید، در هر زمان تنها یکی از آنها در حافظه ذخیره خواهند شد. تابع ()xrange در پایتون از generator-ها برای ساخت لیست استفاده میکند.
نکته مهم اینجا است که اگر بازه بزرگی داشته باشید که بخواهید یک لیست برای آن بسازید باید از یک generator برای تابع xrange استفاده کنید. این وضعیت به طور خاص در مواردی مفید خواهد بود که بخواهید یک سیستم واقعاً حساس از نظر حافظه مانند اپلیکیشن موبایل یا محاسبات پیشرفته بسازید.
این بدان معنی است که اگر بخواهید روی یک لیست چندین بار چرخهای را تکرار کنید و این لیست آن قدر کوچک باشد که در حافظه جای بگیرد، بهتر است از حلقههای for و تابع range استفاده کنید. دلیل این امر آن است که generator-ها و xrange مقادیر لیست را هر بار که به آنها دسترسی پیدا میکنید، از نو میسازند در حالی که range یک لیست استاتیک است و مقادیر صحیح برای دسترس سریع در حافظه ایجاد میشوند.
بدین ترتیب به پایان این مطلب با عنوان بررسی 5 قابلیت پیشرفته پایتون و روش استفاده از آنها میرسیم. هر گونه دیدگاه یا پیشنهاد خود را در بخش نظرات این نوشته با ما و دیگر خوانندگان مجله فرادرس در میان بگذارید.
منبع: فرادرس
React Native یک فریمورک عالی برای توسعه اپلیکیشنهای موبایل چند پلتفرمی برای گوشیهای مبتنی بر iOS و اندروید است. در این مقاله قصد داریم با همدیگر فرایند ساخت یک اپلیکیشن «کوچک» آب و هوا را با استفاده از React Native و Expo از طریق واکشی دادهها به صورت آنی مرور کنیم. اگر تاکنون هرگز با React Native کار نکردهاید، میتوانید از این راهنمای گام به گام به عنوان آغاز مسیر خود برای تبدیل شدن به یک توسعهدهنده اپلیکیشنهای موبایل استفاده و یک پروژه جالب به رزومه خود اضافه کنید.
اگر تجربه کار با React.js را داشته باشید، در یادگیری این راهنما هیچ مشکلی نخواهید داشت. اگر در زمینه جاوا اسکریپت یا اکوسیستم React.js یک تازهکار محسوب میشوید، پیشنهاد میکنیم پیش از ادامه مطالعه این مقاله، برای این که بتوانید مفاهیم مقدماتی این راهنما را درک کنید، سری به این آموزشها نیز بزنید:
توجه داشته باشید که React Native یک فریمورک اپلیکیشن موبایل هیبرید نیست. این فریمورک از پلی بین جاوا اسکریپت و API-های native پلتفرم مقصد استفاده میکند. برای کسب اطلاعات بیشتر در این زمینه پیشنهاد میکنیم سری به مستندات رسمی (+) React Native بزنید.
ما در این راهنما از Expo (+) استفاده خواهیم کرد که به عنوان «سریعترین روش برای ساخت اپلیکیشن» توصیف شده است. Expo یک مجموعه اوپنسورس از ابزارها و سرویسهایی است که به طور خاص زمانی که تازه وارد دنیای React Native شدهاید، بسیار به کار شما میآید. ابزار توسعهای که در این نوشته برای Expo استفاده میکنیم، Expo XDE (+) نام دارد.
همه موارد مورد نیاز اینها هستند. بنابراین در ادامه فرایند توسعه اپلیکیشن خود را آغاز میکنیم.
Expo XDE را پس از نصب کردن باز کنید و روی Create New Project کلیک کنید:

نام اپلیکیشن خود را وارد کرده و روی Create کلیک کنید. نام اپلیکیشن باید با حروف کوچک لاتین باشد. دلیل این مسئله آن است که رابط کاربری Expo XDE از کاراکترهای حروف بزرگ پشتیبانی نمیکند.


Expo در پسزمینه از ابزار مدیریت پکیج React Native برای شبیهسازی اپلیکیشن و بارگذاری وابستگیها از فایل package.json اپلیکیشن استفاده میکند. مزیت استفاده از Expo EDE این است که لازم نیست پنجرههای ترمینال چندگانه را باز کنید و میتوانید اپلیکیشن را همزمان با توسعه روی دستگاه واقعی تست کنید. زمانی که این مرحله پایان یافت، کد منبع اپلیکیشن ایجاد میشود و میتوانیم آن را در یک شبیهساز روی سیستم محلی آغاز کنیم تا پیشنمایشی از اپلیکیشن پیشفرض به دست بیاوریم.

اگر از Mac استفاده میکنید، باید مطمئن شوید که Xcode روی سیستمتان نصب شده است. اگر از ویندوز استفاده میکنید، دستورالعملهای نصب اندروید استودیو برای اجرای شبیهساز را پیگیری کنید.
اگر میخواهید از مرحله شبیهسازی اپلیکیشن عبور کنید و آن را بدون ایجاد هر گونه فایل apk. یا ipa. روی دستگاه واقعی تست کنید، میتوانید کلاینت Expo را نصب کرده و کد QR ایجاد شده از سوی Expo XDE را اسکن کنید.

زمانی که کد منبع کار بستهبندی را انجام داد، یک پیام موفقیت در ترمینال Expo XDE نمایش مییابد:

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

پیام نمایش یافته در این صفحه کد سادهای است که از سوی App.js در ریشه اپلیکیشن ما رندر شده است:
<Text> را به صورت زیر تغییر دهید:
در این مرحله مشاهده میکنید که خروجی رندر میشود و اپلیکیشن به صورت خودکار و آنی بارگذاری مجدد میشود. برای مشاهده تغییرات نیازی به رفرش کردن وجود دارد.

بدین ترتیب مرحله نخست آغاز کار را انجام دادهایم. در مرحله بعدی یک پروتوتایپ استاتیک از اپلیکیشن خود میسازیم تا ببینیم چه سر و شکلی خواهد داشت.
در این مرحله نخستین صفحه اپلیکیشن خود را توسعه میدهیم که یک صفحه بارگذاری است. بدین منظور در فایل App.js یک «حالت محلی» (local state) تعریف کنید:
کد فوق اعلام میکند که وقتی حالت محلی شیء isLoading نادرست است، نام اپلیکیشن را باید نشان دهیم. این همان چیزی است که قصد داریم رندر کنیم. در ادامه و زمانی که دادهها را با موفقیت واکشی کردیم، به جای نمایش دادن نام اپلیکیشن، وضعیت آب و هوا را در این صفحه نمایش خواهیم داد. در حال حاضر، این پیام را بررسی میکنیم و بدین منظور نخست باید به این سؤال پاسخ دهیم که اگر اپلیکیشن ما در حالت بارگذاری باشد چه خواهد شد؟ متن پیام را به این صفحه اضافه میکنیم تا به کاربر نشان دهیم اپلیکیشن در حال واکشی کردن دادهها است.
هنگامی که اپلیکیشن ما کار بارگذاری دادهها از API را به پایان ببرد، حالت isLoading را به صورت False تنظیم میکنیم:

ما یک کامپوننت «آب و هوا» (Weather) در مسیر components/Weather.js./ تعریف میکنیم. کد قالب برای هر صفحه شرایط جوی، یکسان خواهد بود و به دو view تقسیم میشود که یکی هدر و دیگری بدنه است. ویوی هدر آیکون شرایط جوی و دما را نشان میدهد و ویوی بدنه متن مرتبط با شرایط جوی را نمایش خواهد داد.
در Weather.js، شروع به تعریف کردن دو کانتینر درون کانتینر اصلی میکنیم که یکی headerContainer و دیگری bodyContainer است. توجه داشته باشید که کامپوننت weather به صورت یک کلاس و نه یک تابع تعریف میشود تا props را دریافت کند و از این رو میتواند یک حالت را مدیریت کند.
ما از MaterialCommunityIcons استفاده خواهیم کرد که به همراه Expo به عنوان یک کتابخانه فرعی از کتابخانه humongous به نام vector-icons عرضه میشود:
بدین ترتیب اپلیکیشن ما پس از اتمام مرحله پروتوتایپ به صورت زیر در خواهد آمد:

برای واکشی دادهها به صورت آنی از API نقشه Open Weather (+) استفاده میکنیم، چون کاملاً مفید و سازگار است. برای ارتباط با این API باید یک کلید API داشته باشیم، یعنی باید یک حساب کاربری در سایت ایجاد کنیم تا کلید API را دریافت کنیم. توجه داشته باشید که فعال شدن کلید API مربوط به Open Weather دستکم 10 دقیقه طول میکشد.
در وبسایت به بخش API section بروید. چنان که میبینید نیازهای ما بر اساس دادههای جوی حاضر تأمین میشود. ما قصد داریم کلید API را در فایل utils/WeatherAPIKey.js/. ذخیره کنیم.
طرز کار API مربوط به Open Weather چنین است که باید مختصات طول و عرض جغرافیایی را از روی مکان دستگاه به آن ارائه کنیم. سپس دادهها را از سرور آن به صورت یک شیء JSON واکشی میکنیم. زمان کار با سرور به دو چیز نیاز داریم که یکی دما و دیگری شرایط جوی است. ما باید این دو مقدار را در حالت محلی App.js ذخیره کنیم.
در این مرحله کار خود را ایمپورت کردن کلید API که قبلاً تعریف کردیم آغاز میکنیم و سپس حالت خود را با مقادیر temperature ،weatherCondition و error بهروزرسانی میکنیم. بدین منظور از ()componentDidMount استفاده میکنیم که یک متد چرخه عمر است که به رندر مجدد اپلیکیشن پس از واکشی دادهها از سوی API کمک میکند. این متد همچنین در زمینه بهروزرسانی حالت به ما کمک خواهد کرد. ما از یک API به نام navigator نیز برای دریافت موقعیت دستگاه استفاده میکنیم. این همان جایی است که API جاوا اسکریپت از طریق یک پل با API نیتیو همکاری میکند. ما مقادیر طول و عرض جغرافیایی را به تابع سفارشی خود با نام fetchWeather ارسال میکنیم که API مربوط به Open Weather Map در آن فراخوانی میشود.
نتیجه کار در قالب JSON است و اگر آن را در کنسول لاگ کنید، میتوانید نتیجه را به صورت یک شیء JSON در ترمینال Expo مشاهده کنید که مقادیر زیادی در خود دارد. ما تنها به مقدار دما و شرایط جوی نیاز داریم و سپس حالت محلی خود را با مقادیر جدیدی که به دست آوردهایم بهروزرسانی میکنیم. units=metric& در انتهای فراخوانی API موجب میشود که دما از مقیاس کلوین به سلسیوس تبدیل شود.
اینک تنها کاری که باید انجام دهیم، ارسال این دو مقدار حالت محلی به صورت props به کامپوننت weather است و سپس آن را طوری بهروزرسانی میکنیم که آن prop-ها را دریافت کند. ابتدا در فایل App.js تغییرات زیر را ایجاد کنید:
فایل weather.js را نیز به صورت زیر بهروزرسانی کنید:

از آنجا که بخش دشوار کار که واکشی دادهها به صورت همزمان بود را انجام دادیم، اینک باید کاری کنیم که کامپوننت weather ما بر اساس مقادیری که دریافت میکند رفتاری دینامیک داشته باشد. این رفتار دینامیک با withweatherCondition مرتبط خواهد بود.
با استفاده از withweatherCondition میتوانیم تغییراتی را در پسزمینه، عنوان، عنوان فرعی آیکون جوی خود تعریف کنیم. کار خود را با تعریف از پیش آماده شرایط جوی در یک فایل به نام utils/WeatherConditions.js./ آغاز میکنیم:
این شرایط جوی به وسیله API مربوط به Open Weather ارائه میشوند. سپس این فایل را در weather.js ایمپورت میکنیم. همچنین PropTypes را برای دو prop که از App.js دریافت میکنیم تعریف خواهیم کرد. به کد زیر توجه کنید:
بخش غالب کد منبع یکسان است. ما اینک برخی موارد را از طریق دسترسی به prop-های شرایط جوی به صورت دینامیک تغییر میدهیم که شامل پسزمینه، آیکون، نام شرایط جوی و عنوان فرعی آن میشود. همچنین میتوانید تغییراتی بنا به دلخواه خود در استایل اپلیکیشن ایجاد کنید تا ظاهری مینیمالتر یا زیباتر بیابد.

نکته: پیش از آن که اپلیکیشن را روی دستگاه واقعی خود اجرا کنید، باید مطمئن شوید که دسترسی اینترنت و مکان روی دستگاه برای این اپلیکیشن فعال شده است. ما در این مقاله در مورد دسترسیهای اپلیکیشن صحبت نکردیم، چون تا حدودی خارج از حیطه این مطلب به حساب میآید. برای مشاهده کد کامل این پروژه میتوانید به این ریپوی گیتهاب (+) مراجعه کنید.
اگر این نوشته برای شما مفید بوده است، آموزشهای زیر نیز به شما پیشنهاد میشوند:
در این مقاله در مورد مفهوم تصاویر واکنش گرا یا Responsive صحبت خواهیم کرد. تصاویر واکنشگرا به تصاویری گفته میشود که روی دستگاههای مختلف که اندازههای صفحه، وضوح تصویر و دیگر ویژگیهای متفاوت دارند، به طرز مناسبی نمایش پیدا میکنند. همچنین با امکانات HTML برای پیادهسازی تصاویر واکنشگرا آشنا خواهیم شد. تصاویر واکنشگرا بخشی از طراحی وب واکنشگرا هستند. شما برای مطالعه این مطلب باید با مبانی HTML و شیوه افزودن تصاویر استاتیک به یک صفحه وب آشنا باشید. هدف از این نوشته، آشنایی با شیوه استفاده از ویژگیهایی مانند srcset برای عنصر <picture> جهت پیادهسازی راهحلهای تصویر واکنشگرا در یک وبسایت است.
برای مطالعه قسمت قبلی این مجموعه مطلب میتوانید روی لینک زیر کلیک کنید:
سناریوی متداول زیر را تصور کنید. یک وبسایت معمولی میتواند شامل یک تصویر هدر و برخی تصاویر محتوایی در زیر هدر باشد. تصویر هدر به طور معمول کل عرض صفحه را پوشش میدهد و تصویر محتوا یک بخش (یا همه) عرض ستون محتوا را اشغال میکند. به تصویر زیر توجه کنید:

این وضعیت روی یک دستگاه با صفحه عریض مانند لپتاپ یا دسکتاپ به خوبی نمایش پیدا میکند. کد صفحه فوق به صورت زیر است:
ما در این بخش قصد نداریم کدهای CSS را مورد بررسی دقیقی قرار دهیم و صرفاً برخی موارد را در ادامه فهرستبندی کردهایم:
با این وجود، زمانی که این صفحه وب را روی دستگاههایی با عرض کمتر مشاهده میکنید با برخی مشکلات مواجه خواهید شد. در این موارد هدر ظاهر مناسبی دارد؛ اما در یک صفحه موبایل ارتفاع بیشتری از صفحه را اشغال میکند. در این اندازه، دیدن افراد درون نخستین تصویر محتوا دشوار میشود.

یکی از راههای برای بهبود این وضعیت آن است که نسخه برش یافتهای از تصویر را نمایش دهیم که وقتی سایت روی صفحههای کمعرض نمایش پیدا میکند، صرفاً جزییات مهم تصویر را نمایش دهد. تصویر دوم برش یافته نیز میتواند برای نمایش روی صفحه دستگاههایی با عرض متوسط مانند تبلت استفاده شود. این مشکل به طور معمول به نام مسئله «art direction» شناخته میشود.
به علاوه در صورتی که قرار است تصویرها روی یک صفحه کوچک موبایل نمایش یابند، نیازی به جاسازی چنین تصاویر بزرگی روی صفحه نیست. این وضعیت به نام مسئله «Resolution Switching» شناخته میشود. چنان که در بخش قبلی این سری مقالات در مورد گرافیکهای برداری (+) گفتیم، تصویر raster مجموعهای از پیکسلها است که عرض و ارتفاع مشخصی دارد. یک تصویر کوچک raster در صورت نمایش در اندازهای بزرگتر از اندازه اصلی خودش تار به نظر میرسد (اما گرافیک برداری چنین نیست).
به طور عکس، نمایش یک تصویر بزرگ روی صفحهای که بسیار کوچکتر از اندازه تصویر است، کار بیهودهای محسوب میشود. این کار موجب هدر رفتن پهنای باند میشود و به طور خاص برای آن دسته از کاربران موبایل حائز اهمیت است که نمیخواهند تصویر بزرگی را که برای نمایشگرهای دسکتاپ طراحی شده، دانلود کنند. یک راهحل ایدهآل در این موارد، آن است که چند وضوح تصویر مختلف داشته باشیم و بسته به دستگاههایی که به دادههای روی وبسایت دسترسی مییابند، نسخه مناسب را ارائه کنیم.
برای این که متوجه بشوید مسائل پیچیدهتر از این هستند، باید بگوییم که برخی دستگاهها صفحههای با وضوح تصویر بالاتر دارند که به تصاویر بزرگتر از مقدار معمول نیاز دارند تا به خوبی نمایش پیدا کنند. این مشکل نیز شبیه به مشکل فوق است؛ اما در چارچوب متفاوتی قرار دارد.
ممکن است فکر کنید که تصاویر برداری میتوانند این مشکلات را حل کنند و البته تا حدی نیز قادر به حل این مسائل هستند. آنها هم اندازه کوچکی دارند و هم به خوبی تغییر مقیاس پیدا میکنند و در هر جایی که ممکن است بهتر است از آنها استفاده کنید. با این که این تصاویر برای برخی از انواع تصاویر مانند الگوها، عناصر اینترفیس و غیره مناسب هستند؛ اما برای برخی از انواع دیگر تصویر مانند عکسها که نیاز به جزییات زیادی دارند به سرعت حجیم میشوند. قالب تصاویر raster مانند JPEG برای این نوع از تصاویر که در مثال فوق نیز مشاهده کردید، مناسبتر هستند.
در اوایل تا اواسط دهه 90 میلادی، زمانی که وب تازه متولد شده بود، این نوع از مشکلات چندان رایج نبودند، چون دستگاههایی که امکان مرور وب را داشتند، لپتاپها و رایانههای دسکتاپ بودند و از این رو مهندسانِ مرورگرها و طراحان به پیادهسازی چنین راهحلهایی حتی فکر هم نمیکردند. فناوری تصاویر واکنشگرا در سالهای اخیر و برای حل مشکلاتی که در بخشهای قبلی اشاره کردیم ابداع شده است و امکان ارائه چندین تصویر از سوی مرورگر را فراهم ساخته است. این تصاویر همگی موضوع واحدی را نمایش دهند؛ اما تعداد پیکسلهای متفاوتی دارند (Resolution Switching) و یا این که تصاویر مختلف که مناسب فضابندیهای متفاوت هستند ارائه میکنند (art direction).
نکته: دقت کنید که ویژگیهای جدیدی که در این نوشته بررسی میکنیم، یعنی srcset ،sizes و <picture> هنوز از سوی همه نسخههای مرورگرهای مدرن موبایل و دسکتاپ پشتیبانی نمیشوند.
در این بخش روی دو مسئلهای متمرکز میشویم که در بخش قبلی تشریح کردیم و روش حل آنها را با استفاده از ویژگیهای تصاویر واکنشگرا در HTML مورد بررسی قرار میدهیم. باید توجه داشته باشید که ما در این بخش روی <img>-های HTML تمرکز خواهیم کرد. این عناصر را در ناحیه محتوای مثال ابتدای این نوشته مشاهده کردید و دیدید که تصویر موجود در هدر سایت صرفاً برای تزیین است و لذا توسط تصاویر پسزمینه CSS پیادهسازی شده است. میتوان استدلال کرد که CSS نسبت به HTML ابزارهای بهتری برای طراحی واکنشگرا ارائه کرده است.
ابتدا باید از خود بپرسیم resolution switching قرار است کدام مشکل را حل کند؟ ما میخواهیم محتوای تصویری یکسانی و البته با اندازه بزرگتر یا کوچکتر، بسته به اندازه صفحه دستگاه مقصد نمایش دهیم. این همان موقعیتی است که باید از محتوای تصویر دوم که در مثال فوق معرفی کردیم، استفاده کنیم. عنصر استاندارد <img> به طور سنتی تنها امکان تعیین یک فایل منبع منفرد برای تصویر در مرورگر ارائه میکند:
با این وجود میتوانیم از دو خصوصیت جدید srcset و sizes استفاده کنیم تا چند تصویر منبع اضافی همراه با سرنخهایی در اختیار مرورگر قرار دهیم تا نوع مناسب را بسته به موقعیت انتخاب کند. در ادامه یک نمونه استفاده از این ویژگیها را مشاهده میکنید:
خصوصیتهای srcset و sizes به ظاهر پیچیده به نظر میرسند؛ اما اگر آنها را به صورت فوق قالببندی کنید و هر خصوصیت را در یک خط جدید قرار دهید، درک آنها چندان دشوار نخواهد بود. هر مقدار شامل یک لیست است که با ویرگول از هم جدا میشود و هر بخش از لیست از سه بخش فرعی تشکیل یافته است. محتوای هر ردیف به صورت زیر است:
srcset مجموع تصاویری که مرورگر میتواند از بین آنها انتخاب کند را شامل میشود و اندازه هر تصویر را نیز نمایش میدهد. پیش از هر ویرگول موارد زیر را مینویسیم:
Sizes مجموعهای از «شرایط رسانه» (Media Condition) است؛ یعنی عرض صفحه را تعریف و تعیین میکند که هر کدام از شرطهای فوق تا چه اندازهای باید انتخاب شوند. اینها سرنخهایی هستند که قبلاً در موردش صحبت کردیم. در این حالت، پیش از هر ویرگول موارد زیر را مینویسیم:
نکته: در مورد عرض اسلات باید یک طول مطلق (px ،em) یا طول نسبی صفحه (vw) ارائه کنید؛ اما امکان تعیین درصد وجود ندارد. ممکن است متوجه شده باشید که آخرین عرض اسلات شرط رسانهای ندارد. دلیل این مسئله آن است که این مقدار پیشفرض است و هنگامی که هیچ شرط رسانهای صحیح نباشد انتخاب میشود. مرورگر هر چیزی را که پس از اولین شرط سازگار بیابد نادیده میگیرد، بنابراین در مورد ترتیببندی شرطهای رسانهای با احتیاط عمل کنید.
بدین ترتیب وقتی این خصوصیتها تنظیم شوند، مرورگر به صورت زیر عمل خواهد کرد:
این همه داستان است. بنابراین در این مرحله اگر یک مرورگر مناسب با اندازه صفحه 480 پیکسل وجود داشته باشد، شرط رسانهای (max-width: 480px) درست خواهد بود و از این رو اسلات 440px انتخاب میشود و بدین ترتیب تصویر elva-fairy-480w.jpg بارگذاری خواهد شد، زیرا عرض ذاتی آن 480w به 440px نزدیکترین مطابقت را دارد. تصویر 800px روی دیسک فضایی به اندازه 128 کیلوبایت اشغال میکند؛ در حالی که نسخه 480 پیکسلی تنها 63 کیلوبایت حجم دارد که موجب صرفهجویی 65 کیلوبایت پهنای باند در زمان بارگذاری میشود. اینک تصور کنید اگر این صفحهای باشد که تصاویر زیادی روی آن باشد، استفاده از این تکنیک موجب میشود که کاربران موبایل از پهنای باند زیادی استفاده کنند.
مرورگرهای قدیمیتر که از این ویژگیها پشتیبانی نمیکنند، آنها را نادیده میگیرند و به بارگذاری تصویر ارجاع یافته در خصوصیت src به صورت معمول میپردازند.
نکته: در بخش <head> سند شاهد خطی به صورت زیر هستیم:
که مرورگرهای قدیمی را وامیدارد تا از اندازه صفحه واقعی خود برای بارگذاری صفحههای وب استفاده کنند. برخی از مرورگرهای موبایل از عرض صفحه خود استفاده میکنند و به جای بارگذاری صفحه وب در اندازههای بزرگ اندازه صفحه را کاهش میدهند که فایده چندانی برای تصاویر یا طراحی واکنشگرا ندارد. در مورد این وضعیت در بخشهای بعدی این سری مقالات بیشتر صحبت خواهیم کرد.
برخی ابزارهای مفید توسعهدهنده در مرورگرها وجود دارند که به تعیین عرضهای ضروری اسلات و موارد دیگر کمک میکنند. زمانی که این موارد را محاسبه میکنیم، ابتدا نسخه غیر واکنشگرای مثال خود را که در ابتدای این مقاله ارائه شده است در یک برگه جدید مرورگر باز کنید. سپس به نمای طراحی واکنشگرا در مسیر Tools > Web Developer > Responsive Design View بروید تا امکان بررسی طرحبندی صفحه روی دستگاههای مختلف با اندازه صفحههای متفاوت را داشته باشید.
ما عرض صفحه را برابر با 320 پیکسل و سپس 480 پیکسل قرار دادیم و در هر مرحله به بخش DOM Inspector رفته و روی عنصر <img> کلیک کردیم، سپس به اندازه آن در برگه Box Model در سمت راست نمایشگر نگاه کردیم. بدین ترتیب عرض ذاتی تصاویر به دست میآید.

سپس میتوانید با تعیین عرض صفحه به مقدار دلخواه، بررسی کنید که آیا srcset کار میکند یا نه. بدین منظور به بخش Network Inspector بروید و سپس صفحه را مجدداً بارگذاری کنید. بدین ترتیب لیستی از فایلها را میبینید که دانلود میشوند تا صفحه وب ایجاد شود. در اینجا میتوانید ببینید که فایل تصویر انتخابی برای دانلود کدام است.
نکته: زمانی که مشغول تست صفحه روی مرورگر کروم هستید، باید زمانی که DevTools با رفتن به مسیر Settings > Preferences > Network باز شده است، کش را غیر فعال کنید، چون در غیر این صورت کروم تصاویری که قبلاً دانلود کرده را بارگذاری میکند و اهمیتی به تصاویری متناسبتر هستند نمیدهد.

اگر شما در وبسایت خود از چندین وضوح نمایشی پشتیبانی میکنید؛ اما همه افراد تصویرهای شما را در اندازه واقعی صفحه مشاهده میکنند، میتوانید با استفاده از srcset با x-descriptors و بدون sizes به مرورگر اعلام کنید که یک وضوح تصویر مناسب را انتخاب کند. نمونهای از آن را در ادامه مشاهده میکنید:

در این مثال، CSS زیر روی تصویر به طرزی اعمال شده است که عرضی برابر با 320 پیکسل روی صفحه خواهد داشت:
در این حالت خصوصیت sizes مورد نیاز نیست و مرورگر محاسبه میکند که نمایشگر کدام وضوح تصویر را دارد و مناسبترین تصویر را که در srcset ارجاع یافته است ارائه میکند. بنابراین اگر دستگاهی به صفحهای دسترسی پیدا کند که وضوح نمایش پایین/استاندارد دارد و در آن هر پیکسل نماینده یک پیکسل CSS است، تصویر elva-fairy-320w.jpg بارگذاری خواهد شد. اگر دستگاه وضوح تصویر بالایی داشته باشد و در آن برای هر پیکسل CSS دو پیکسل نمایشگر یا بیشتر وجود داشته باشد، تصویر elva-fairy-640w.jpg بارگذاری خواهد شد. تصویر 640 پیکسل حجمی به اندازه 93 کیلوبایت دارد، در حالی که تصویر 320 پیکسل 39 کیلوبایت حجم دارد.
اگر بخواهیم یادآوری بکنیم، مسئله Art Direction شامل تغییر دادن تصویر نمایش یافته برای ایجاد تناسب در اندازههای متفاوت نمایشی است. برای نمونه اگر یک تصویر منظره بزرگ باشد که فردی در میانه آن ایستاده است و در یک وبسایت روی مرورگر دسکتاپ نمایش مییابد، زمانی که این وبسایت روی مرورگر موبایل نمایش میابد، بد به نظر میآید، زیرا آن فرد واقعاً کوچک خواهد بود و به سختی دیده میشود. در چنین مواردی شاید واقعاً بهتر باشد که تصویر پرتره کوچکتری روی موبایل نمایش یابد که فرد را در حالت بزرگنمایی شده نمایش میدهد. عنصر <picture> به ما امکان میدهد که صرفاً این نوع از راهحل را پیادهسازی کنیم.
اگر به مثال ابتدای این نوشته بازگردیم، میبینیم که تصویر موجود در هدر نیاز شدیدی به Art Direction دارد.
این وضعیت را با استفاده از <picture> که مانند عناصر <video> و <audio> است اصلاح میکنیم. عنصر <picture> یک پوشش است که شامل چند عنصر <source> است و چند منبع متفاوت در اختیار مرورگر قرار میدهد تا انتخاب کند و البته پس از عنصر کاملاً مهم <img> میآید. با استفاده از این راهحل کد ما به صورت زیر درمیآید:
عناصر <source> شامل یک خصوصیت media هستند که شامل شرط رسانهای است و چنان که در مثال srcset دیدیم، این شرطها آزمونهایی هستند که تصمیم میگیرند کدام تصویر نمایش پیدا کند. نخستین تصویری که مقدار true بازگشت دهد نمایش خواهد یافت. در این حالت اگر عرض صفحه برابر با 799 پیکسل باشد، نخستین <source> عنصر تصویر نمایش پیدا خواهد کرد. اگر عرض صفحه برابر با 800 پیکسل یا بیشتر باشد، تصویر منبع دوم نمایش پیدا میکند.
خصوصیتهای srcset شامل مسیر تصویری هستند که باید نمایش پیدا کند. دقت داشته باشید چنان که در مورد <img> قبلاً دیدیم، <source> نیز یک خصوصیت srcset میگیرد که در آن چند تصویر ارجاع یافتهاند و یک خصوصیت sizes نیز دارد. بنابراین میتوانید چندین تصویر را از طریق عنصر <picture> ارائه کنید؛ اما در این صورت باید چندین وضوح تصویر نیز برای هر یک تعیین کنید. در عمل شما احتمالاً در اغلب موارد چنین چیزی را نمیخواهید.
در همه موارد، باید یک عنصر <img> ارائه کنید که دارای خصوصیتهای src و alt باشد و درست قبل از </picture> آمده باشد، چون در غیر این صورت هیچ تصویری نمایش پیدا نخواهد کرد. این عنصر حالت پیشفرض را تعیین میکند. این حالت وقتی اعمال میشود که هیچ شرط رسانهای مقدار true بازگشت ندهد و همچنین در مورد مرورگرهایی که از عنصر picture پشتیبانی نمیکنند به عنوان یک fallback عمل میکند.
این کد امکان نمایش یک تصویر مناسب را روی صفحههای عریض و همچنین نمایشگرهای کمعرض مانند تصویر زیر فراهم میسازد:


نکته: شما باید از خصوصیت media تنها در سناریوهای Art Direction استفاده کنید؛ اما زمانی که از media بهره میگیرید، شرطهای رسانه را درون خصوصیت sizes هم نیاورید.
زمانی که مرورگر شروع به بارگذاری یک صفحه میکند، ابتدا و پیش از آن که parser اصلی شروع به بارگذاری و تفسیر CSS و جاوا اسکریپت صفحه بکند، هر تصویری که وجود داشته باشد را دانلود (پیش بارگذاری) میکند. این یک تکنیک مفید است که به صورت میانگین موجب 20 درصد بهبود در زمان بارگذاری صفحه میشود. با این وجود، در مورد تصاویر واکنشگرا مفید نیست چون باید راهحلهایی مانند srcset پیاده سزای شو. بدین ترتیب برای نمونه نمیتوان عنصر <img> را بارگذاری درک د و سپس عرض صفحه را با استفاده از جاوا اسکریپت تشخیص داد و به صورت دینامیک منبع تصویر را در صورت نیاز به تصاویر کوکتر عوض کرد. چون در این زمان تصویر اصلی قبلاً بارگذاری شده است و با این کار تصویر کوچکتر نیز بارگذاری میشود که از نظر واکنشگرایی وضعیتی بدتر از قبل را رقم میزند.
چند قالب جدید تصویر مانند WebP و JPEG-2000 وجود دارند که میتوانند همزمان اندازه فایل کم و کیفیت بالا را داشته باشند. با این وجود پشتیبانی مرورگرها از این قالبهای تصویر پراکنده است.
عنصر <picture> امکان تداوم سرویسدهی در مرورگرهای قدمی را فراهم میکند. شما میتوانید انواع MIME آ درون خصوصیت type وارد کنید تا مرورگرها بتوانند بیدرنگ انواع فایلی را که پشتیبانی نمیکنند رد کنند:
در این یادگیری عملی، انتظار داریم که قوی و شجاع باشید و مسیر را برخلاف روال معمول این سری مقالات بدون کمک ما طی کنید، یا دستکم بخش عمده آن را به صورت مستقل طی کنید. از شما خواسته میشود که حالت Art Direction خودتان را برای صفحههای عریض و کمعرض با استفاده از <picture> پیادهسازی کنید و یک نمونه سوئیچ وضوح تصویر داشته باشید که در آن از srcset استفاده شده باشد. بدین منظور باید کارهای زیر را انجام دهید:
نکته: از بخش devtools مرورگر برای پیدا کردن اندازههای مورد نیاز، چنان که در متن مقاله اشاره کردیم استفاده کنید.
بدین ترتیب به پایان این مقاله با موضوع تصاویر واکنشگرا رسیدیم. امیدواریم از آشنا شدن با این تکنیکها لذت برده باشید. به عنوان جمعبندی اشاره میکنیم که در زمان بحث از واکنشگرایی دو مسئله وجود دارد که میخواهیم حل کنیم:
این مسئلهای که در آن میخواهیم تصاویر برش یافتهای را برای طرحبندیهای مختلف ارائه کنیم. برای نمونه یک تصویر چشمانداز که صحنه کاملی از یک طرحبندی دسکتاپ را نمایش نشان میدهد و یک تصویر پرتره که سوژه اصلی را در حالت بزرگنمایی شده در طرحبندی موبایل به نمایش میگذارد. این مسئله را با استفاده از عنصر <picture> میتوان حل کرد.
مسئلهای که در این حالت میخواهیم حل کنیم، این است که فایلهای تصاویر کوچکتری را روی دستگاههای با صفحه کمعرض نمایش دهیم، چون به تصاویر بزرگ که مناسب مرورگرهای دسکتاپ هستند نیاز ندارند. در این حالت به صورت گزینه بندی شده تصاویر با وضوح متفاوت را برای صفحههای با اندازه بزرگ و کوچک ارائه میکنیم. این مسئله را میتوان با استفاده از گرافیکهای برداری (تصاویر SVG) و همچنین خصوصیتهای srcset و sizes حل کرد.
در بخش بعدی این سری مقالات راهنمای جامع HTML به ارزیابی آموختههای خود در زمینه فایلهای چندرسانهای میپردازیم.
برای مطالعه قسمت بعدی از این مجموعه مطلب آموزشی روی لینک زیر کلیک کنید:
کمپانی «کُدمنتور» (Codementor) هر سال گزارش جامعی پیرامون زبانهای برنامهنویسی که افراد نباید بیاموزند فراهم میکند. معمولا، گزارشهایی که سازمانهای گوناگون فراهم میکنند پیرامون محبوبترین زبانهای برنامهنویسی و یا در واقع پیرامون زبانهایی است که توصیه میشود افراد بیاموزند. اما کدمنتور درست برعکس این جریان عمل کرده و لیست زبانهای برنامهنویسی را منتشر میکند که توصیه میشود افراد نیاموزند.
زبانهای قرار گرفته در صدر لیست زبانهایی که توصیه میشود افراد یاد نگیرند، عبارتند از: «اِلم» (Elm)، «کافیاسکریپت» (CoffeeScript)، (اِرلنگ) (Erlang)، «لوآ» (Lua) و «پِرل» (Perl). در واقع در این مطلب، مخاطب با «زبان های برنامه نویسی که نباید در سال ۲۰۱۹ بیاموزد» آشنا خواهد شد.
شایان ذکر است که در گزارش کدمنتور، زبانهای «جاوا اسکریپت» (JavaScript)، «پایتون» (Python) و «جاوا» (Java) حضور ندارند. این زبانها، قطعا از بهترین زبانهای برنامهنویسی با محبوبیت بسیار بالا محسوب میشوند. یکی از اهداف دیگر بررسی کدمنتور، ارزیابی زبانهای با محبوبیت کمتر است تا عملکرد و پسرفت آنها در مقابل یکدیگر را بسنجد. ۲۰ زبان برنامهنویسی، در این بررسی بر اساس سه معیار زیر رتبهبندی شدهاند:
در ادامه، لیست کامل این زبانها ارائه شده است.

همانطور که از تصویر بالا مشهود است، «اِلم» (Elm) بدترین زبان در بین پنج تا از بدترین زبانها برای یادگیری در سال ۲۰۱۹ است. در رتبه دوم بدترین زبانها برای یادگیری، «کافیاسکریپت» (CoffeeScript) قرار دارد و در جایگاههای سوم به بعد، به ترتیب «ارلنگ» (Erlang)، «لوآ» (Lua) و «پِرل» (Perl) قرار دارند.
نتایج بررسیهای کدمنتور از سال گذشته تاکنون تفاوتهای قابل توجهی داشته است. برای مثال، «دارت» (Dart) در سال ۲۰۱۸ در صدر لیست بدترین زبانها برای یادگیری قرار داشت، در حالیکه در سال ۲۰۱۹، به رتبه ۱۳ دست یافت که این نشان از بهبود قابل توجه آن دارد. پرسشی که در این وهله ممکن است مطرح شود این است که این زبان چگونه توانسته تنها در یک سال، ۱۳ رتبه بهبود پیدا کند؟
پاسخ این پرسش را باید در خبر انتشار چارچوب متنباز توسعه برنامههای کاربردی موبایل «فلاتِر» (Flutter) جست. این چارچوب توسط گوگل ساخته شده و برای توسعه اپلیکیشنهای موبایل برای اندروید و iOS مورد استفاده قرار میگیرد. همچنین، «فلاتر» روش اصلی ساخت برنامههای کاربردی برای سیستمعامل «گوگل فیوشا» (Google Fuchsia) محسوب میشود.
فلاتر به زبانهای «سی» (C)، «سیپلاسپلاس» (++C) و دارت نوشته شده است. این امر موجب شد تا نرخ مشارکت جامعه برای زبان دارت افزایش قابل توجهی پیدا کند. جامعه کوچک اما فعال دارت، اکنون دارای توسعهدهندگان متعددی است که در حال کار روی دارت و فلاتر هستند.
دومین تغییر قابل توجه در مقایسه با گزارش سال گذشته مربوط به جابهجا شدن «آبجکتیو-سی» (Objective-C) است که در لیست بدترینها چند رتبه پایینتر رفته (بهتر شده) و کافیاسکریپت با یک رتبه بدتر شدن، جایگزین آبجکتیو-سی شده است. میتوان تغییرات نسبت به سال گذشته را در تصویر زیر مشاهده کرد.

در مقایسه با رتبهبندیهای سال گذشته برای بدترین زبانهای برنامهنویسی، میتوان عنوان «بهبودیافتهترین زبانهای برنامهنویسی» را به دارت و «روبی» (Ruby) داد. از سوی دیگر، «کاتلین» (Kotlin) و «آر» (R) نیز امسال در لیست زبانهایی که «کمترین بهبود» را داشتهاند قرار میگیرند.
در نهایت، «کلوژر» (Clojure) و «هسکل» (Haskell) دو زبانی هستند که نسبتا به سال گذشته در جایگاه خود (از سال ۲۰۱۸ تا ۲۰۱۹) پایدار باقی ماندهاند. با تحلیل مدل تغییر رتبهها از سال ۲۰۱۸ تا ۲۰۱۹ ، کدمنتور به مخاطبان توصیه میکند که بهتر است چه زبانهایی را در اولویت یاد نگرفتن خود قرار دهند. بنابراین، سه زبان برنامهنویسی که باید از یادگیری آنها اجتناب کرد، کافیاسکریپت، ارلنگ و لوآ هستند. اگرچه، توسعهدهندگان میتوانند هر زبانی که دوست دارند یاد بگیرند، شاید این زبانها هم تا سال ۲۰۲۰ به جایگاه قابل توجهی دست پیدا کردند!
منبع: فرادرس