اندروید برای قدرت دادن به کاربر و اجازه دادن به آن‌ها برای استفاده از اپلیکیشن‌ها به صورت بصری طراحی شده است. برای مثال، کاربران یک اپلیکیشن ممکن است صحفه را بچرخانند، به یک اعلان پاسخ دهند و یا یک کار دیگر را انجام دهند، و آن‌ها باید بتوانند پس از چنین رویدادهایی به صورت یکپارچه به استفاده از برنامه ادامه دهند.
برای ارائه این تجربه‌ی کاربری، شما باید بدانید که چگونه چرخه‌ی زندگی component را مدیریت کنید. Component می‌تواند یک اکتیویتی، فرگمنت، سرویس، خود اپلیکیشن و یا حتی process پایه باشد. یک component دارای چرخه‌ی زندگی است، که در طی آن از حالت‌هایی عبور می‌کند. هروقت از یکی از حالت‌ها عبور کند، سیستم از طریق متد callback چرخه‌ی زندگی به شما اطلاع می‌دهد.
برای توضیح اینکه چرخه‌ی زندگی چگونه کار می‌کند، سناریوهای مختلفی را تعیین کرده‌ایم که در مقالات بعدی توضیح داده خواهند شد.
سناریوهای زیر رفتار پیش‌فرض اجزاء را نشان می‌دهد، مگر اینکه به طور دیگری ذکر شود.
چرخه‌ی زندگی اندروید - بخش اول: Single Activity
سناریوی اول : اپلیکیشن خاتمه یافته و مجدد شروع شده
- کاربر بر روی دکمه‌ی برگشت کلیک کرده
- متد Activity.finish صدا زده می‌شود
این ساده‌ترین سناریو است که نشان می‌دهد که چه اتفاقی می‌افتد وقتی که یک اپلیکیشن تک اکتیویتی توسط کاربر شروع شده، خاتمه یافته و مجدد شروع شده.
مدیریت حالت‌ها
- onSavedInstance صدا زده نمی‌شود( تا زمانی که اکتیویتی خاتمه‌بیابد، نیاز به ذخیره‌ی حالت‌ها نیست )
- onCreate وقتی که دوباره باز می‌شود bundle ندارد، چون که اکتیویتی خاتمه‌یافته و حالت نیاز به بازیابی ندارد.
سناریوی دوم : کاربر به بیرون حرکت می‌کند
- کاربر بر روی دکمه‌ی Home کلیک می‌کند
- کاربر به برنامه‌ی دیگری می‌رود( از طریق منوی کلی، اعلان‌ها، پذیرش تماس و غیره)
در این سناریو سیستم اکتیویتی را متوقف کرده، اما بلافاصله آن را تمام نمی‌کند.
در این سناریو سیستم اکتیویتی را متوقف کرده، اما بلافاصله آن را تمام نمی‌کند.
مدیریت حالت‌ها
وقتی که اکتیویتی شما وارد وضعیت متوقف شده، سیستم از onSaveInstanceState برای ذخیره‌ی وضعیت اپلیکیشن استفاده می‌کند، در حالتی که سیستم process اپلیکیشن را بعدا ازبین می‌برد.
با فرض اینکه process از بین‌نرفته، نمونه‌ی اکتیویتی در حافظه باقی می‌ماند و تمام حالت‌ها را حفظ می‌کند. وقتی که اکتیویتی به پیش‌زمینه بازمی‌گردد، اکتیویتی این اطلاعات را فرامی‌خواند. بنابراین نیازی به ایجاد مولفه‌هایی که قبلا ایجاد کرده‌اید نیست.
سناریوی سوم : تغییر configuration
- تغییر configuration مانند چرخش صفحه
- کاربر پنجره را در حالت چند پنجره‌ای، تغییر اندازه می‌دهد
مدیریت حالت
تغییر congiguration مانند چرخش صفحه یا تغییر اندازه‌ی پنجره باید به کاربر اجازه دهد که دقیقا همان جایی که بوده‌اند ادامه دهند.
- اکتیویتی کاملا نابود شده است، اما حالت ذخیره شده است و برای نمونه‌ی جدید بازگردانده می‌شود.
- Bundle در onCreate و onSavedInstanceState یکی است.
سناریوی چهارم : اپلیکیشن توسط سیستم نگه داشته می‌شود
- فعال کردن حالت چند پنجره‌ای (Api ۲۴+) و از دست دادن focus
- برنامه‌ی دیگری تاحدودی برنامه‌ی درحال اجرا را پوشش می‌دهد( یک دیالوگ خرید، دیالوگ runtime permission dialog، دیالوگ ورود یک third-party )
- ظاهر شدن یک intent chooser، مانند دیالوگ اشتراک‌گذاری
این سناریو در حالت‌های زیر صدق نمی‌کند:
- دیالوگ در همان برنامه. نمایش AlertDialog یا DialogFragment، اکتیویتی زیرین را نگه‌نمی‌دارد
- اعلان‌ها. کاربر یک اعلان جدید دریافت کند و یا نوار اعلان‌ها را پایین بکشد، اکتیویتی زیرین را نگه‌نمی‌دارد.
چرخه‌ی زندگی اندروید - بخش دوم: Multiple Activity
توجه داشته باشید، هنگام نمایش چرخه‌ی زندگی برای چندین component ( اکتیویتی، فرگمنت، و غیره ) در یک نمودار، رویدادهای گروه‌بندی شده‌ای که در کنار هم ظاهر می‌شوند به صورت موازی اجرا می‌شوند. تمرکز اجرا می‌تواند از یک گروه موازی از رویدادها به یک گروه دیگر در هر زمان تغییر کند، بنابراین ترتیب فراخوانی بین گروه‌های موازی رویدادها تضمین نمی‌شود. اگرچه، ترتیب داخل گروه تضمین شده است.
سناریوی زیر مربوط به اکتیویتی و وظایفی نیست که launch mode سفارشی و یا task affinity مشخص شده دارند. برای اطلاعات بیشتر، به Task And Back Stack بر روی وبسایت توسعه‌دهندگان اندروید مراجعه کنید.
سناریوی اول – Back Stack: حرکت بین اکتیویتی‌ها
در این سناریو، هنگامی که اکتیویتی جدید آغاز می‌شود، اکتیویتی1 متوقف شده (اما نابود نمی‌شود)، شبیه به حالتی که کاربر به بیرون از برنامه حرکت می‌کند (انگار که دکمه‌ی "Home" فشار داده شده است).
هنگامی که دکمه‌ی برگشت فشار داده می‌شود، اکتیویتی2 نابود شده و پایان می‌یابد.
مدیریت حالت
توجه داشته باشید که onSavedInstanceState صدا زده می‌شود ولی onRestoreInstanceState صدا زده نمی‌شود. اگر وقتی که اکتیویتی دوم فعال می‌شود، تغییر configuration داشته باشیم، اکتیویتی اول نابود شده و فقط وقتی که تمرکز بر روی آن باشد دوباره ساخته می‌شود. به همین دلیل است که saveInstanceState مهم است.
اگر برای ذخیره‌ی منابع، سیستم process اپلیکیشن را نابود کند، این یک سناریوی دیگر است که حالت نیاز به بازیابی دارد.
سناریوی دوم – Back Stack: اکتیویتی در Back Stack قرار دارد با تغییر configuration
مدیریت حالت
ذخیره‌ی حالت فقط برای آن اکتیویتی که در پیش‌زمینه قرار دارد مهم نیست. همه‌ی اکتیویتی‌هایی که در پشته قرار دارند، نیاز دارند که حالت را بعد از تغییر configuration بازیابی کنند تا Ui را دوباره بسازند.
سناریوی سوم – Back Stack: process اپلیکیشن نابود می‌شود
هنگامی که سیستم‌عامل اندروید نیاز به منابع دارد، اپلیکیشن‌هایی که در پس‌زمینه هستند را نابود می‌کند.
مدیریت حالت
توجه داشته باشید که حالت کامل پشته ذخیره می‌شود، اما برای استفاده‌ی بهینه از منابع، اکتیویتی‌ها فقط وقتی که دوباره ساخته‌شوند بازیابی می‌شوند.
چرخه‌ی زندگی اندروید بخش سوم: Fragmentz
در این قسمت به بررسی رفتار فرگمنت‌ها هنگام وصل‌شدن به اکتیویتی خواهیم پرداخت. این سناریو را با وقتی که فرگمنت به پشته اضافه می‌شود اشتباه نگیرید (برای اطلاعات بیشتر در مورد transaction و back stack در فرگمنت‌ها به Tasks and Back Stack مراجعه کنید).
سناریوی اول: اکتیویتی و فرگمنت شروع شده و خاتمه می‌یابند
توجه داشته باشید که اجرای onCreate اکتیویتی قبل از اجرای فرگمنت تضمین شده است. اگرچه callBackهای نشان داده شده در کنار هم مانند onStart و onResume به صورت موازی اجرا می‌شوند و بنابراین می‌توانند به هر ترتیب فراخوانده شوند. برای مثال سیستم باید متد onStart اکتیویتی را قبل از متد onStart فرگمنت اجرا کند، اما بعد از آن متد onResume فرگمنت را قبل از متد onRsume اکتیویتی اجرا می‌کند.
مراقب باشید که زمان اجرای دنباله‌های مربوطه را طوری مدیریت کنید که از شرایط مسابقه دوری کنید.
سناریوی دوم: چرخش اکتیویتی با فرگمنت
مدیریت حالت
حالت فرگمنت به شکلی مشابه با اکتیویتی ذخیره و بازیابی می‌شود. تفاوت این است که در فرگمنت onRestoreInstanceState وجود ندارد، اما Bundel در متد‌های onCreate, onCreateView, onActivityCreate فرگمنت وجود دارد.
فرگمنت می‌تواند حفظ شود، به این معنی که از همان نمونه در تغییر configuration استفاده شود.
سناریوی سوم: چرخش اکتیویتی با فرگمنت حفظ شده
فرگمنت پس از چرخش نابود و ساخته نمی‌شود، زیرا پس از دوباره ساخته شدن اکتیویتی از همان نمونه‌ی فرگمنت استفاده می‌شود. حالت Bundel هنوز در onActivityCreate موجود است.
استفاده از نمونه فرگمنت حفظ شده توصیه نمی‌شود مگر اینکه از آن برای ذخیره داده در تغییر configuration استفاده شود(در فرگمنت غیر Ui). این همان چیزی است که ViewModel در داخل کتابخانه‌ی Architecture Component انجام می‌دهد، اما با یک Api ساده‌تر.
چرخه‌ی زندگی اندروید بخش چهارم: ViewModels,Translucent Activity and Launch Modes
ViewModels
چرخه‌ی زندگی ViewModel کاملا ساده است، آن‌ها فقط یک Callback دارند به نام onCleared. اگرچه تفاوت‌هایی بین Scop در اکتیویتی و فرگمنت وجود دارد.
توجه داشته باشید که مقداردهی اولیه وقتی اتفاق می‌افتد که ViewModel را فراهم کنید، که به‌طور معمول در onCreate انجام می‌شود.
Translucent Activity
Translucent Activityها دارای زمینه‌ی نیمه‌شفاف(معمولا شفاف) هستند، بنابراین کاربر می‌تواند زیر آن‌را ببیند.
هنگامی که ویژگی android:windowIsTranslucent بر روی theme اکتیویتی اعمال می‌شود، نمودار کمی تغییر می‌کند: اکتیویتی پس‌زمینه هرگز متوقف نمی‌شود، فقط نگه‌داشته می‌شود بنابراین همچنان می‌تواند بروزرسانی‌های Ui را دریافت کند.
همچنین، وقتی که به task بازمی‌گردید، هر دو اکتیویتی دوباره ساخته شده و فقط اکتیویتی شفاف از سرگرفته می‌شود.
Launch Modes
روش پیشنهادی برای معامله با task و BackStack این است که، نباید رفتار پیش‌فرض را اتخاذ کنید.
اگر واقعا نیاز به استفاده از SINGLE_TOP دارید، نمودار آن در زیر آمده است:
بخاطر مقایسه در زیر شِماتیک SINGLE_TASK آمده است (اما احتمالا از آن استفاده نمی‌کنید).
نکته: اگر از Navigation Architecture Component در Jetpack استفاده می‌کنید، از پشتیبانی از Single Top و همچنین BackStack خودکار بهره‌مند می‌شوید.
مجموعه مقالات چرخه‌ی زندگی اندروید به پایان رسید، امیدوارم که این مفاهیم را درک کرده باشید و پروژه‌های بهتری را با این مفاهیم توسعه دهید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید