شش اشتباه رایج در توسعه اپلیکیشن های Android

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

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

بیایید شش اشتباه رایج که بنظرم باعث پایین اومدن کیفیت اپلیکیشن میشه رو بررسی کنیم:

استفاده نکردن از Intent

Intentها یکی از کامپوننت‌های کلیدی Android هستند که از آنها برای انتقال یا پاس‌دادن داده‌ها به قسمت‌های مختلف اپلیکیشن یا حتی بین اپلیکیشن‌ها استفاده می‌شود، البته تنها راه این نیست ولی مرسوم‌ترین راه است.

بیایید مثالی را بررسی کنیم:

فرض کنید که می‌خواهید یک متن را مثلا از طریق SMS توسط برنامه به اشتراک بگذارید. به نظر شما کدام یک از دو روش زیر منطقی است؟

روش اول:

• افزودن مجوز SEND_SMS permission به برنامه
• نوشتن کد ارسال SMS توسط SmsManager
• توضیح دادن به کاربر که چرا برنامه شما به مجوز ارسال پیام که ممکن است از شارژ ریالی شما کم کند نیاز دارد و چرا باید این مجوز را به برنامه بدهد.

روش دوم (استفاده از Intent):

یک SMS Intent بسازید و به برنامه‌ای که برای این کار توسعه یافته اجازه بدهید تا بقیه کار را انجام دهد

Intent sendIntent = new Intent(Intent.ACTION_VIEW);

sendIntent.setData(Uri.parse("sms:" + telephoneNumber));

sendIntent.putExtra("sms_body", x);

startActivity(sendIntent);

اگر هنوز شک دارید ، مطمئن باشید که روش دوم بهتر است. این روش می‌تواند تقریبا برای هر چیزی استفاده شود، مانند: گرفتن عکس یا ضبط ویدئو، به اشتراک گذاشتن محتوا، نشان دادن موقعیت روی نقشه، ثبت یک رویداد در تقویم و ….

البته مواردی نیز وجود دارد که شما مجبورید خودتان این کارها را انجام بدهید، برای مثال برای اپلیکیشنی که پردازش تصویر به صورت real time با دوربین انجام می‌دهد. تشخیص این موارد به عهده شما توسعه‌دهنده عزیز است.

استفاده نکردن از Fragment ها

در همین مجله و در این لینک بطور کامل لزوم استفاده از آنها رو بیان کردم. 😉

متوقف شدن Main Thread

ترد اصلی برنامه یک هدف اصلی دارد، و آن تعامل داشتن با کاربر از طریق رابط کاربری یا بهتر بگم : keeping the user interface responsive

من زیاد رایج به علم مغر و چشم و … اطلاعاتی ندارم ولی اینو میدونم که چشم ما هر اتفاقی که زیر ۲۴ فریم بر ثانیه با تاخیر بیشتر از ۱۰۰ میلی ثانیه رو میتونه تشخیص بده و دیدن چنین چیزی توی اپلیکیشن زیاد از نظر کاربر جالب نیست و فکر میکنه اپلیکیشن روان و راحت کار نمیکنه!

این به این معناست که شما در این فرصت کوتاه بعد از انجام هر عملی از طرف کاربر باید بازخورد مناسب داشته باشید. اگر بازخورد مناسبی در این زمان نداشته باشید کاربر فکر می‌کند که کنترل برنامه از دستش خارج شده و یک بازخورد با اثر منفی بر روی کاربر خواهد داشت.

حتی بدتر از این گاهی اوقات نخ اصلی برنامه (Main Thread) برای مدتی متوقف می‌شود (۵ ثانیه برای Activity و ۱۰ ثانیه برای Broadcast Receivers) که با پیغام زیر مواجه میشویم.

شاید ۶ ثانیه برای انجام عملیات در Activity برای شما کافی باشد ولی آیا کاربر با مشاهده پیغام بالا هنوز مایل به ماندن است؟؟؟

برای جلوگیری از این رخداد میتوانید از worker/background استفاده کنید مخصوصا هنگامی که می‌خواهید یکی از کارهای زیر را انجام دهید:

• network calls
• bitmap loading
• image processing
• database querying
• SD reading / writing

 اختراع دوباره چرخ

تقریبا من این جمله رو از زبان تمام توسعه‌دهندگان حرفه‌ای شنیده‌ام که   “چرخ را دوباره اختراع نکنید! “

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

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

به طور مثال می‌توانید از ابزارهای زیر استفاده کنید:

• gradle as a build system.
• Retrofit / Volley for network calls.
• Picasso for image loading.
• Gson / Jackson for JSON parsing.
• common implementations for social login.

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

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

چند نکته برای اینکه چنین اتفاقی رخ ندهد:

• dp متفاوت از px می‌باشد. به این لینک یک نگاه بندازید.
• فرم‌ها را برای دستگاه‌هایی با تراکم پیکسلی متفاوت در جهت‌های متفاوت (افقی و عمودی) طراحی کنید. برای اطلاعات بیشتر به این لینک مراجعه کنید.
• از ابزار Draw 9-patch استفاده کنید.

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

درست است که نمی‌توانیم اپلیکیشن خود را در همه دستگاه‌ها تست کنیم، ولی براحتی می‌توانید از Emulator مختلفی استفاده کنید. یکی از بهتر از آنها Genymotion است که نسخه رایگان آن تاحدود زیادی به شما کمک خواهد کرد.

قرار ندادن minSdkVersion بر روی ۱۴

خب این یه اشتباه نیست ولی یه انتخاب و عمل نادرسته!

درسته که نسخه ۲٫x یک نقطه عطف در توسعه این پلتفرم بود ولی باید یک سری چیزها رو پشت سر گذاشت. پشتیبانی از دستگاه‌های قدیمی‌تر پیچیدگی کد برنامه رو بیشتر می‌کند و شما باید استثناهای زیادی را در اپلیکیشن کنترل کنید.

بعلاوه در این لینک شما می‌توانید مشاهده کنید که کاربران این ورژن ها بسیار کم هستند.

البته این کار شاید باعث از دست دادن کاربران زیادی برای اپلیکیشن‌های پرمخاطبی همچون Facebook باشد ولی آیا برای شما هم چنین است؟؟؟

اگر شما هم مورد دیگری به نظرتان می‌آید با ما در میان بگذارید.