طراحی برای یکپارچگی

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

یک مشکل رایج یکپارچگی زمانی است که فرآیند پس‌زمینه یک برنامه - به عنوان مثال، یک سرویس یا گیرنده پخش - در پاسخ به برخی رویدادها یک گفتگو ظاهر می‌شود. این ممکن است رفتاری بی ضرر به نظر برسد، به خصوص زمانی که در حال ساخت و آزمایش برنامه خود به صورت مجزا در شبیه ساز هستید. با این حال، زمانی که برنامه شما بر روی یک دستگاه واقعی اجرا می شود، برنامه شما ممکن است در زمانی که فرآیند پس زمینه شما کادر گفتگو را نمایش می دهد، تمرکز کاربر نداشته باشد. بنابراین ممکن است برنامه شما گفتگوی خود را در پشت برنامه فعال نمایش دهد، یا می تواند از برنامه فعلی تمرکز کند و گفتگو را در مقابل هر کاری که کاربر انجام می دهد نمایش دهد (مثلاً شماره گیری یک تماس تلفنی). این رفتار برای برنامه شما یا کاربر کار نمی کند.

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

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

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

این سند مشکلات رایج یکپارچگی و نحوه اجتناب از آنها را مورد بحث قرار می دهد.

داده ها را رها نکنید

همیشه به خاطر داشته باشید که اندروید یک پلتفرم موبایل است. ممکن است بیان آن بدیهی به نظر برسد، اما مهم است که به خاطر داشته باشید که فعالیت دیگری (مانند برنامه «تماس تلفنی ورودی») می‌تواند هر لحظه بر روی Activity شما ظاهر شود. این کار متدهای onSaveInstanceState() و onPause() را فعال می کند و احتمالاً منجر به از بین رفتن برنامه شما می شود.

اگر زمانی که فعالیت دیگر ظاهر شد، کاربر در حال ویرایش داده‌ها در برنامه شما بود، برنامه شما احتمالاً با از بین رفتن برنامه شما، این داده‌ها را از دست می‌دهد. البته مگر اینکه ابتدا کار در حال انجام را ذخیره کنید. "Android Way" دقیقاً این کار را انجام می دهد: برنامه های Android که ورودی را می پذیرند یا ویرایش می کنند باید متد onSaveInstanceState() را لغو کنند و وضعیت خود را به روشی مناسب ذخیره کنند. هنگامی که کاربر دوباره از برنامه بازدید می کند، باید بتواند داده های خود را بازیابی کند.

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

داده های خام را افشا نکنید

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

"راه اندروید" ایجاد یک ContentProvider است تا داده های شما را از طریق یک API تمیز، سنجیده و قابل نگهداری در معرض سایر برنامه ها قرار دهد. استفاده از یک ContentProvider بسیار شبیه به قرار دادن یک رابط زبان جاوا برای تقسیم و جزء کردن دو قطعه کد است که با هم جفت شده اند. این بدان معناست که می‌توانید فرمت داخلی داده‌های خود را بدون تغییر رابطی که توسط ContentProvider در معرض نمایش قرار می‌گیرد، تغییر دهید، و این بدون تأثیر بر سایر برنامه‌ها.

حرف کاربر را قطع نکنید

اگر کاربر برنامه‌ای را اجرا می‌کند (مانند برنامه تلفن در حین تماس)، مطمئناً او این کار را عمدا انجام داده است. به همین دلیل است که باید از فعالیت‌های تخم‌ریزی خودداری کنید، مگر در پاسخ مستقیم به ورودی کاربر از فعالیت فعلی.

یعنی از BroadcastReceivers یا Services در حال اجرا در پس‌زمینه، startActivity() را فراخوانی نکنید. انجام این کار برنامه‌ای را که در حال حاضر اجرا می‌شود قطع می‌کند و باعث آزار کاربر می‌شود. شاید حتی بدتر از آن، فعالیت شما ممکن است به یک «راهزن ضربه‌ای کلید» تبدیل شود و مقداری از ورودی‌هایی را که کاربر در میانه ارائه به فعالیت قبلی انجام داده بود، دریافت کند. بسته به کاری که برنامه شما انجام می دهد، این می تواند یک خبر بد باشد.

به جای ایجاد رابط های Activity UI به طور مستقیم از پس زمینه، در عوض باید از NotificationManager برای تنظیم اعلان ها استفاده کنید. این‌ها در نوار وضعیت ظاهر می‌شوند و کاربر می‌تواند در اوقات فراغت خود روی آن‌ها کلیک کند تا ببیند برنامه شما چه چیزی را به او نشان می‌دهد.

(توجه داشته باشید که همه این موارد در مواردی که Activity خودتان قبلاً در پیش زمینه است صدق نمی کند: در این صورت، کاربر انتظار دارد فعالیت بعدی شما را در پاسخ به ورودی ببیند.)

کارهای زیادی برای انجام دادن دارید؟ آن را در یک موضوع انجام دهید

اگر برنامه شما نیاز به انجام محاسبات گران قیمت یا طولانی مدت دارد، احتمالا باید آن را به یک رشته انتقال دهید. این از نمایش مخوف "Application Not Responsing" به کاربر جلوگیری می کند که نتیجه نهایی آن نابودی آتشین برنامه شما خواهد بود.

به‌طور پیش‌فرض، همه کدهای یک Activity و همچنین تمام View‌های آن در یک رشته اجرا می‌شوند. این همان رشته ای است که رویدادهای رابط کاربری را نیز مدیریت می کند. به عنوان مثال، هنگامی که کاربر کلیدی را فشار می‌دهد، یک رویداد key-down به صف رشته اصلی Activity اضافه می‌شود. سیستم کنترل کننده رویداد باید آن رویداد را به سرعت حذف کند و مدیریت کند. اگر این کار را نکرد، سیستم پس از چند ثانیه نتیجه می گیرد که برنامه هنگ شده است و پیشنهاد می کند آن را برای کاربر بکشد.

اگر کد طولانی‌مدت دارید، اجرای آن به صورت درون خطی در Activity، آن را روی رشته مدیریت رویداد اجرا می‌کند و عملاً کنترل‌کننده رویداد را مسدود می‌کند. این کار پردازش ورودی را به تاخیر می اندازد و منجر به گفتگوهای ANR می شود. برای جلوگیری از این امر، محاسبات خود را به یک رشته انتقال دهید. این سند Design for Responsiveness نحوه انجام آن را مورد بحث قرار می دهد.

یک صفحه فعالیت را بیش از حد بارگذاری نکنید

هر اپلیکیشنی که ارزش استفاده را داشته باشد، احتمالا چندین صفحه نمایش متفاوت خواهد داشت. هنگام طراحی صفحه‌نمایش رابط کاربری خود، حتماً از چندین نمونه Object Activity استفاده کنید.

بسته به پیشینه توسعه خود، می‌توانید یک Activity را شبیه به یک اپلت جاوا تفسیر کنید، زیرا نقطه ورود برنامه شما است. با این حال، این کاملاً دقیق نیست: در جایی که یک زیر کلاس اپلت تنها نقطه ورودی یک اپلت جاوا است، یک Activity باید به عنوان یکی از چندین نقطه ورودی به برنامه شما در نظر گرفته شود. تنها تفاوت بین فعالیت "اصلی" شما و هر فعالیت دیگری که ممکن است داشته باشید این است که اتفاقاً "اصلی" تنها کسی است که به عملکرد "android.intent.action.MAIN" در AndroidManifest شما ابراز علاقه کرده است. فایل xml.

بنابراین، هنگام طراحی برنامه خود، برنامه خود را به عنوان یک فدراسیون از اشیاء Activity در نظر بگیرید. این باعث می شود کد شما در طولانی مدت بسیار قابل نگهداری باشد و به عنوان یک اثر جانبی خوب، با سابقه برنامه اندروید و مدل "backstack" نیز به خوبی بازی می کند.

تم های سیستم را گسترش دهید

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

رابط کاربری خود را طوری طراحی کنید که با وضوح صفحه نمایش چندگانه کار کند

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

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

فرض کنید شبکه کند است

دستگاه های اندرویدی با انواع گزینه های اتصال به شبکه عرضه خواهند شد. همه دارای برخی از امکانات دسترسی به داده خواهند بود، اگرچه برخی از آنها سریعتر از دیگران خواهند بود. با این حال، کمترین مخرج مشترک GPRS است، سرویس داده غیر 3G برای شبکه های GSM. حتی دستگاه‌های دارای قابلیت 3G زمان زیادی را در شبکه‌های غیر 3G صرف می‌کنند، بنابراین شبکه‌های کند برای مدت طولانی در آینده یک واقعیت باقی خواهند ماند.

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

یک مشکل بالقوه در اینجا این است که اگر از شبیه ساز استفاده می کنید، بسیار آسان است که در این دام بیفتید، زیرا شبیه ساز از اتصال شبکه رایانه رومیزی شما استفاده می کند. این تقریباً تضمین شده است که بسیار سریعتر از یک شبکه سلولی است، بنابراین شما می خواهید تنظیمات شبیه ساز را تغییر دهید که سرعت پایین تر شبکه را شبیه سازی می کند. شما می توانید این کار را در Android Studio از طریق مدیر AVD یا از طریق یک گزینه خط فرمان هنگام راه اندازی شبیه ساز انجام دهید.

صفحه لمسی یا صفحه کلید را فرض نکنید

اندروید از انواع فرم فاکتورهای گوشی پشتیبانی می کند. این یک روش فانتزی برای گفتن این است که برخی از دستگاه های اندرویدی دارای صفحه کلید کامل "QWERTY" هستند، در حالی که برخی دیگر دارای تنظیمات کلیدی 40، 12 کلیدی یا حتی سایر کلیدها هستند. به طور مشابه، برخی از دستگاه ها صفحه نمایش لمسی خواهند داشت، اما بسیاری از آنها اینگونه نیستند.

هنگام ساخت برنامه های خود، این را در نظر داشته باشید. در مورد طرح‌بندی‌های صفحه‌کلید خاص فرضیات نکنید - مگر اینکه، البته، واقعاً علاقه‌مند به محدود کردن برنامه خود باشید تا فقط در آن دستگاه‌ها قابل استفاده باشد.

باتری دستگاه را حفظ کنید

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

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

کاربران بسیار باهوش هستند: اگر برنامه شما تشنه انرژی است، می توانید روی آن ها حساب کنید که متوجه آن می شوند. تنها چیزی که در آن مرحله می توانید از آن مطمئن باشید این است که برنامه شما برای مدت طولانی نصب نمی شود.