با طعم کد!

اشتباهات پر تکرار یک برنامه‌نویس اندروید – قسمت اول

این اتفاقات شاید برای هر برنامه‌نویسی اتفاق بیفتد،...

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

۱. برای اندروید توسعه بده!

خوشبختانه این اشتباه در حال حاضر کمتر رایج است (شاید بخشی از این بهبود به این علت باشد که مشتریان ما فهمیده‌اند که روز هایی که فقط اپل استانداردهای طراحی را تنظیم می‌کرد رو به پایان است و امروزه گوگل استانداردهایی بهینه و مناسب برای طراحی پیشنهاد کرده‌است) اما هنوز هم گاهی اپلیکیشن‌هایی را مشاهده می‌کنیم که نسخه برگردان ورژن iOS خود هستند.
این مشکل را بدون هیچ جانبداری نسبت به اندروید یا iOS مطرح می کنم و برای تمامی پلتفرم هایی که برای پیشرفت دنیای موبایل حتی یک قدم رو به جلو برداشته اند ارزش خاصی قائلم، اما در حال حاضر نمی‌توان و نباید استانداردهای طراحی iOS را به خورد گروه بزرگی از کاربران داد که به استاندارد های اندروید عادت کرده و UI/UX آن را به عنوان سیستم عامل مورد علاقه خود انتخاب کرده‌اند، به نظر من هرگز این اشتباه را مرتکب نشوید، مگر اینکه یک دلیل فوق العاده خوب برای شکستن این مورد داشته باشید. گاها بعضی از استانداردها زیر پا گذاشته می‌شود و خود سبکی جدید و نوآور ایجاد می‌کند، اما واقعا بیایید با خودمان صادق باشیم، قرار نیست هر روز یک سبک جدید و نوآور تولید کنیم!! :))

۲.برای خودت توسعه نده!

با توجه به تعداد و تنوع دستگاه های اندرویدی از سایز صفحه و وضوح تصویر و تا تنوع در معماری سیستم و تفاوت در ورژن سیستم عامل و همچنین امروزه تنوع در نسبت تصویر، این واقعیتی غیر قابل انکار است که هرگز نباید فقط و فقط توسعه یک برنامه را برای یک دستگاه انجام داد و یا اگر یک برنامه روی یک دستگاه به خوبی کار میکند از تست و آزمایش آن روی دستگاه های دیگر صرف نظر کرد.
پیشنهاد میکنم برای توسعه در اندروید حتما واحد های مناسب برای هر قسمت را به کار ببرید، به عنوان مثال برای اشیا از “پیکسل مستقل از تراکم” یا همان dp و برای نوشتار -اگر احساس میکنید تغییر سایز در نوشتار سیستم عامل باعث ضربه به رابط کاربری شما نمی شود- از “پیکسل مستقل از مقیاس” یا همان sp استفاده کنید. خوشبختانه IDE ها این پیشنهادات را در اکثر مواقع یادآوری می‌کنند، اما در نظر داشته باشید اگر برای یک متن مشخصه‌ی سایز را تعیین نکنید، این مشخصه از مقدار پیش فرض با واحد sp استفاده می‌کند.
در صورتی که اپلیکیشن شما دارای منابع و تصاویری است که باید در هر صفحه با کیفیت مناسب دیده شوند حتما از کیفیت ها مختلف در ابعاد مختلف استفاده کنید، به این معنی که یک دستگاه با تراکم پیکسلی پایین هیچ نیازی ندارد که تصویری با ابعاد بالا را بارگزاری کند (باعث کند شدن و ایجاد مشکل در دستگاه های ضعیف‌تر می‌شود) و همچنین درصورتی که ابعاد تصویر برای دستگاه های با تراکم پیکسلی بالا و ابعاد بزرگ‌تر، کم باشد احساس ناخوشایند از رابط کاربری به کاربر القا می‌شود.
برای استفاده از تصویرها و منابعی که ممکن است اصطلاحا کشیده شوند و یا فرم اصلی خود را از دست بدهند، پیشنهاد میکنم حتما از ۹patch استفاده کنید. باور کنید زمان زیادی از شما نمی گیرد اما در ازاء آن از به هم ریختن و تغییر شکل رابط کاربری برای دستگاه های متفاوت جلوگیری می‌کنید.
آخرین پیشنهاد برای ابعاد مختلف صفحات این است که جداگانه برای اندازه های مختلف طراحی کنید، شاید تعداد و تنوع صفحات خیلی زیاد باشد اما پس از مدتی این نکته را خواهید فهمید که با طراحی تعداد انگشت شماری از این صفحات می توانید همه آن ها را پوشش دهید.
پس از همه این آزمون ها، یک بار دستگاه اندرویدی خودتان را به حالت افقی بچرخانید، خیلی از اپلیکیشن ها طراحی برای حالت Landscape را فراموش می‌کنند. اگر رابط کاربری شما برای حالت افقی بهینه نیست، آن را جداگانه طراحی کنید و یا در AndroidManifest این قابلیت را غیرفعال کنید.
در پایان برای آزمایش و آزمون برنامه ای که توسعه داده‌اید، نیازی ندارید که چندین دستگاه اندرویدی داشته باشید، کافیست به راحتی از شبیه سازها استفاده کنید. به عنوان بهترین تجربه، Genymotion مورد موفقی است که گاها بهتر از داشتن چند دستگاه اندرویدی به من کمک می‌کند.
در قسمت بعدی این نوشتار به مشکلات دیگری اشاره خواهم کرد.

برچسب ها
نمایش بیشتر

نوشته های مشابه

دیدگاهتان را بنویسید

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

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

بستن
بستن