مسئله‌ای که باید حل می‌کردم
تعویض سریع تب می‌تواند دو صفحه را هم‌زمان فعال کنه یا انیمیشن قبلی را نیمه‌کاره بگذارد. من می‌خواستم انتخاب نهایی و وضعیت ظاهری تب با هم هماهنگ بمانند.
پیاده‌سازی در نسخهٔ فعلی
TabGroupManager.SelectTab اندیس را بررسی می‌کنه و هنگام جابه‌جایی، انتخاب بعدی را در queuedIndex نگه می‌دارد. SwitchToRoutine خروج قبلی و ورود صفحهٔ بعد را پشت سر هم اجرا می‌کنه.
تصمیم و هزینهٔ طراحی
مختصات و مقیاس اصلی RectTransformها cache می‌شوند. تب‌های تو‌در‌تو می‌توانند به حالت پیش‌فرض برگردند و listener دکمه‌ها به صورت مشخص نگه داشته می‌شود.
مرزهای فعلی
این رفتار به ساختار صفحه و reference درست وابسته هست. پیدا کردن محتوای فرزند و انیمیشن آیتم‌ها برای هر چیدمان دلخواه تضمین عمومی نیست و باید در همان منو بررسی بشه.
سه لمس سریع و یک مقصد نهایی
کاربر می‌تواند هنگام خروج صفحهٔ بازی‌ها، فروشگاه و بلافاصله شخصی‌سازی را لمس کنه. SelectTab وقتی isSwitching فعال هست، درخواست تازه را در queuedIndex می‌گذارد؛ این یک صف بلند از همهٔ لمس‌ها نیست و مقدار تازه جای قبلی را می‌گیرد. پس سیاست فعلی حفظ آخرین مقصد در حال انتظار هست. بعد از پایان جابه‌جایی، اگر مقصد معتبری با currentIndex متفاوت مانده باشد، SelectTab دوباره اجرا می‌شود. این رفتار از انباشته شدن حرکت‌های بی‌هدف جلوگیری می‌کنه، اما نباید آن را اجرای تضمین‌شدهٔ تک‌تک لمس‌های میانی دانست.
SwitchToRoutine ابتدا AnimateOut صفحهٔ قبلی را تمام می‌کنه، آن صفحه را غیرفعال می‌کنه و transform را برمی‌گرداند؛ سپس currentIndex و ظاهر دکمه‌ها تغییر می‌کنند و صفحهٔ بعد وارد می‌شود. NotifyTargetSelected، OnSelected و TabChanged بعد از ورود اجرا می‌شوند. این ترتیب برای مصرف‌کننده‌ای که داده را با انتخاب تازه refresh می‌کنه اهمیت داره. تغییر اندیس و اعلام پایان بصری هم‌زمان نیستند، چون ورود صفحه ممکنه هنوز در جریان باشد. اگر کد دیگری به CurrentIndex تکیه می‌کنه، باید بداند این مقدار مقصد انتخاب‌شده را توصیف می‌کنه و لزوماً نشانهٔ تمام شدن همهٔ حرکت‌ها نیست.
موقعیت و مقیاس اولیه از RectTransform ذخیره می‌شوند تا آفست انیمیشن به جای اصلی طراحی اضافه بشه و پس از پایان پاک بشه. useUnscaledTime نیز امکان ادامهٔ زمان‌بندی رابط مستقل از timeScale بازی را فراهم می‌کنه. گروه‌های تو در تو می‌توانند با انتخاب والد به پیش‌فرض برگردند؛ این تصمیم بر حفظ صفحهٔ داخلی کاربر اثر داره و باید با انتظار محصول هماهنگ باشد. listenerهای دکمه هم cache می‌شوند تا هنگام OnDestroy همان delegate حذف بشه. این جزئیات چرخهٔ عمر را روشن می‌کنند، ولی به‌تنهایی صحت تمام چیدمان‌های arbitrary یا ارجاع‌های ناقص Inspector را ثابت نمی‌کنند.
چیزی که از این مرحله یاد گرفتم
برای من، تب فقط تغییر رنگ دکمه نبود. صفحهٔ فعال، وضعیت فرزندها و حرکت ورود و خروج باید یک انتخاب واحد را بیان کنن، مخصوصاً وقتی بازیکن پشت سر هم لمس می‌کنه.
مثال عملی تغییر تب رابط
برای فهم عملی تغییر تب رابط، یک مثال آموزشی را قدم‌به‌قدم دنبال کنیم. بازیکن سریع از فروشگاه به تنظیمات می‌رود و قبل از پایان حرکت، تب دیگری را انتخاب می‌کند. پیش از اجرا، وضعیت آغاز را روی کاغذ بنویس؛ مشخص کن چه چیزی می‌تواند تغییر کند و چه چیزی باید ثابت بماند. بعد فقط همین مسیر را اجرا کن. این مثال گزارشی از آمار کاربران یا قابلیت تازهٔ منتشرشدهٔ دلو نیست؛ تمرینی برای روشن کردن تصمیم طراحی همین مطلب است.
خطای رایج و علت آن
چند انتقال هم‌زمان می‌تواند دو صفحهٔ فعال یا وضعیت انتخاب ناسازگار بسازد. این خطا معمولاً وقتی پنهان می‌ماند که فقط مسیر موفق و ظاهر نهایی را ببینیم. برای پیدا کردن علت، آخرین وضعیت درست را از نخستین وضعیت نادرست جدا کن و ببین تغییر دقیقاً در کدام مرز رخ داده است. انیمیشن بخش نمایشی انتقال است؛ وضعیت فعال باید مرجع روشن داشته باشد. اگر این تفاوت در قرارداد مشخص نباشد، اصلاح یک نشانه ممکن است همان مسئله را در بخش دیگری دوباره ایجاد کند.
چطور نتیجه را بررسی کنیم؟
پس از آخرین درخواست، فقط یک تب و یک صفحه باید فعال بمانند. اجرای یک‌باره برای نتیجه‌گیری کافی نیست؛ یک بار مسیر معمول و بار دیگر همان موقعیت را با ورودی مرزی یا تکرار اقدام بررسی کن. اگر نتیجه فرق دارد، ورودی و شرایط اجرا را همراه خروجی نگه دار تا مقایسه قابل بازسازی باشد. جدول زیر خلاصهٔ مشخصات همین سناریو است و برای ثبت نتیجهٔ بررسی به کار می‌آید.
| بخش بررسی | آنچه باید ثبت شود |
|---|---|
| موقعیت آزمایشی | بازیکن سریع از فروشگاه به تنظیمات می‌رود و قبل از پایان حرکت، تب دیگری را انتخاب می‌کند. |
| ریسک اصلی | چند انتقال هم‌زمان می‌تواند دو صفحهٔ فعال یا وضعیت انتخاب ناسازگار بسازد. |
| روش بررسی | پس از آخرین درخواست، فقط یک تب و یک صفحه باید فعال بمانند. |
| مرز نتیجه‌گیری | انیمیشن بخش نمایشی انتقال است؛ وضعیت فعال باید مرجع روشن داشته باشد. |
پرسش‌های کاربردی دربارهٔ تغییر تب رابط
از کجا شروع کنم؟
از همان موقعیت محدود این مطلب شروع کن: بازیکن سریع از فروشگاه به تنظیمات می‌رود و قبل از پایان حرکت، تب دیگری را انتخاب می‌کند. ابتدا نتیجهٔ مورد انتظار را مشخص کن و بعد سراغ پیاده‌سازی یا ابزار برو. وقتی مسیر پایه قابل توضیح و بررسی شد، می‌توان حالت‌های بیشتری اضافه کرد. ساخت همهٔ حالت‌ها از ابتدا، فهم علت خطا را سخت‌تر می‌کند.
چه زمانی می‌توانم بگویم این بخش درست کار می‌کند؟
زمانی که رفتار در موقعیت تعریف‌شده با قرارداد سازگار باشد و محدودیت‌های آن روشن بمانند. پس از آخرین درخواست، فقط یک تب و یک صفحه باید فعال بمانند. موفقیت در این آزمون دربارهٔ همان سناریو شاهد می‌دهد؛ از آن نمی‌توان بدون بررسی دربارهٔ همهٔ دستگاه‌ها، همهٔ قوانین محلی یا همهٔ حجم‌های داده نتیجه گرفت. انیمیشن بخش نمایشی انتقال است؛ وضعیت فعال باید مرجع روشن داشته باشد.
برای ادامهٔ همین موضوع، هستهٔ مشترک دلو؛ یک میز برای چند بازی و بازی دلو را ببین. زمینهٔ ساخت این پروژه‌ها و معرفی سازنده در صفحهٔ کیان پاک نعمت آمده است.
