۱. نقطهٔ شروع را با نسخهٔ وب مشخص کن
پیش از تغییر کد، نسخهٔ وب را باز کن و یک دور مسیر بازی را ببین: شروع بازی، نمایش نقش خودت و رسیدن به تعامل با بازیکن‌های دیگر. این کار برای تأیید کیفیت نهایی وب نیست؛ می‌خواهی بدانی کدام رفتارها را بعداً باید در اندروید هم ببینی. در نمونهٔ این پروژه، هر بازیکن غیرانسانی عامل جداگانه‌ای برای تصمیم‌گیری دارد. بازی برای دریافت پاسخ هوش مصنوعی به اتصال نیاز دارد، اما در وضعیت نشان‌داده‌شده، بازی چندنفرهٔ انسان‌ها ندارد. «آنلاین بودنِ سرویس» را با «بازی آنلاین با دوستان» یکی نگیر.
برای خودت یک فهرست کوتاه از رفتارهای قابل مشاهده بنویس: صفحهٔ شروع ظاهر می‌شود؟ نقش دوباره قابل دیدن است؟ آموزش و تنظیمات باز می‌شوند؟ اتصال سرویس چه وضعی نشان می‌دهد؟ این فهرست بعداً جلوی یک اشتباه رایج را می‌گیرد: اینکه نصب موفق برنامه را معادل سالم بودن تمام بازی بدانی. اگر از اجرای قبلی بازخوردی دربارهٔ باگ‌ها داری، هر مورد را جدا و با روش بازتولیدش ثبت کن؛ «بازی مشکل دارد» دستور مناسبی برای اصلاح نیست.
۲. تغییرات وب را پیش از رفتن سراغ اندروید مهار کن
در آغاز کار، بازخوردهای دریافت‌شده به Codex داده شده بود و عامل روی اصلاح و استقرار نسخهٔ تازهٔ وب کار می‌کرد. این روش برای شروع مفید است، ولی گزارش عامل مبنی بر انجام تغییر، جای بررسی خودت را نمی‌گیرد. نسخهٔ جدید وب را باز کن و همان موردهایی را که گزارش شده‌اند تکرار کن. اگر مثلاً مشکل در باز شدن تنظیمات بوده، دقیقاً همان مسیر را دوباره برو؛ فقط صفحهٔ نخست را نگاه نکن.
قبل از درخواست بعدی، وضعیت Git پروژه را بررسی کن و تغییرات مربوط به بازخورد وب را از کارهای خروجی اندروید جدا نگه دار. لازم نیست برای این تفکیک معماری پروژه را حدس بزنی: هدف این است که اگر اجرای اندروید خراب شد، بفهمی کدام دسته از تغییرات احتمالاً دخیل بوده‌اند. Git برای نگه‌داشتن تاریخچه و بازبینی تفاوت نسخه‌ها به کارت می‌آید؛ راهنمای رسمی آن در Git Book در دسترس است. نتیجهٔ این مرحله باید یک مبنای قابل مقایسه باشد: بدانی کدام اصلاحات بررسی شده‌اند و کدام‌ها هنوز فقط ادعای عامل‌اند.
۳. دستگاه آزمون را در Android Studio آماده کن
حالا پروژهٔ موجود KMP را در Android Studio باز کن و صبر کن همگام‌سازی پروژه تمام شود. KMP امکان اشتراک بخشی از کد بین پلتفرم‌ها را می‌دهد، نه تضمین یکسان بودن اجرای وب و اندروید. وابستگی‌ها، مجوزها، ورودی کاربر و رفتار رابط ممکن است در دو خروجی متفاوت باشند. به همین دلیل آزمون اندروید یک مرحلهٔ مستقل است.
از Device Manager یک شبیه‌ساز موجود را اجرا کن یا یک دستگاه مجازی جدید بساز. برای ساخت دستگاه جدید، باید تصویر سیستمیِ نسخهٔ اندروید انتخابی روی رایانه موجود باشد؛ اگر نیست، Android Studio برای دریافت آن راهنمایی‌ات می‌کند. در اجرای نمونه، یک Medium Phone با تصویر سیستمی موجود انتخاب شد. انتخاب تو لازم نیست همین باشد: دستگاهی را بردار که می‌توانی روان روی آن آزمون کنی. اگر شبیه‌ساز برای رایانه‌ات سنگین است، گوشی واقعیِ متصل با USB و تنظیمات اشکال‌زدایی اندروید هم گزینهٔ آزمون است؛ نخست مطمئن شو دستگاه در Android Studio شناخته می‌شود.
نسخهٔ اندروید شبیه‌ساز را با «حداقل نسخهٔ پشتیبانی‌شدهٔ برنامه» اشتباه نگیر. در همین پروژه، هنگام بررسی تنظیمات، حداقل نسخهٔ اندروید ۷ گزارش شد. برای پروژهٔ خودت مقدار تنظیم‌شده را بررسی کن و آن را در گزارش آزمون بنویس. نتیجهٔ مطلوب این مرحله ساده است: یک مقصد اجرا داری و می‌دانی آزمونت روی چه نسخه‌ای انجام می‌شود.
۴. از عامل بخواه برنامه را اجرا کند، نه اینکه موفقیت را اعلام کند
در اجرای نشان‌داده‌شده، از Codex خواسته شد نسخهٔ اندروید را آماده و روی شبیه‌ساز اجرا کند. درخواست خوب باید محدودهٔ کار و معیار گزارش را روشن کند. عامل می‌تواند بیلد و نصب را پیش ببرد، اما تو باید نتیجه را روی صفحه ببینی و خطاهایش را بخوانی. این متن، بازنویسی آموزشی پرامپت است و نقل‌قول لفظی از اجرای پروژه نیست:
در همین پروژهٔ KMP، بدون تغییر دادن رفتار نسخهٔ وب، هدف اجرای نسخهٔ اندروید روی دستگاهی است که اکنون در Android Studio آماده است. ابتدا تنظیمات مرتبط با اندروید و مقصد اجرا را بررسی کن. سپس برنامه را بیلد، نصب و اجرا کن. اگر خطا دیدی، متن خطا، علت محتمل و فایل‌هایی را که تغییر داده‌ای گزارش بده. تا وقتی صفحهٔ برنامه واقعاً باز نشده، کار را موفق اعلام نکن. خروجی انتشار یا کلید امضا نساز.
در نمونه، برنامه نصب و روی شبیه‌ساز باز شد. این خبر خوبی است، اما محدودهٔ نتیجه را دقیق نگه دار: اجرای صفحهٔ برنامه ثابت نمی‌کند که اتصال هوش مصنوعی، تمام نوبت‌های بازی یا ضبط صدا درست کار می‌کنند. اگر بیلد وب موفق است ولی اندروید خطا می‌دهد، اول متن خطای اندروید و آخرین تغییرات را کنار هم بگذار؛ پاک کردن بی‌هدف فایل‌ها یا تعویض هم‌زمان چند وابستگی، یافتن علت را سخت‌تر می‌کند.
۵. آزمون رابط را به مسیرهای قابل تکرار تبدیل کن
بعد از نصب، عامل با ابزار تعامل با اندروید، مسیرهایی مثل آموزش، تنظیمات و پنجرهٔ اتصال هوش مصنوعی را باز و بررسی کرد. مزیت چنین آزمونی فقط سرعت کلیک نیست: اگر مسیر و نتیجهٔ مورد انتظار مشخص باشد، دفعهٔ بعد می‌توانی بفهمی کدام بخش تغییر کرده است. ADB نیز می‌تواند برای تعامل و عیب‌یابی اندروید به کار بیاید، اما کلیک بر اساس جای تقریبی عناصر، به‌ویژه وقتی عنوان واضحی ندارند، ممکن است شکننده باشد.
مثال تکمیلی آموزشی: یک سناریوی دستی کوتاه بساز: برنامه را از حالت بسته باز کن، آموزش را باز و ببند، وارد تنظیمات شو، سپس پنجرهٔ اتصال را باز کن. کنار هر گام بنویس «انتظار داشتم چه ببینم» و «واقعاً چه دیدم». اگر عامل آزمون را اجرا می‌کند، همین سناریو را به او بده و از او بخواه مرحلهٔ ناموفق را با تصویر یا شرح وضعیت گزارش کند. نتیجهٔ این مرحله فهرستی از مشاهده‌هاست، نه جملهٔ کلی «همه‌چیز کار می‌کند».
یک مرز مهم نیز باقی ماند: در جریان آماده‌سازی انتشار، مشخص شد رفتار درخواست مجوز میکروفون هنگام ضبط صدا در خود بازی روی اندروید هنوز آزمون نشده است. پس حتی اگر صفحه‌های آموزش و تنظیمات درست باز می‌شوند، آزمون ورودی صوتی را «انجام‌نشده» ثبت کن. این صداقت بعداً از انتشار نسخه‌ای که در لحظهٔ صحبت کردن کاربر متوقف می‌شود جلوگیری می‌کند.
۶. پیش از خروجی نهایی، مرز امنیتی را بررسی کن
بازی برای پاسخ‌گرفتن از هوش مصنوعی به سرویس بیرونی متکی است. اینجا باید بین تنظیماتی که خود کاربر وارد می‌کند، اطلاعات عمومی برنامه و اعتبارنامه‌های محرمانهٔ متعلق به سازنده فرق بگذاری. کلید محرمانهٔ سازنده را داخل کد، مخزن Git یا بستهٔ اندروید قرار نده: فایل برنامه پس از انتشار در اختیار دیگران است و نباید آن را محل نگهداری راز فرض کنی. اگر مدل پرداخت یا اتصال سرویس هنوز نیازمند بازبینی است، آن را با پنهان کردن کلید در برنامه «حل» نکن.
از عامل می‌توانی برای پیدا کردن ریسک‌ها کمک بگیری، ولی تأیید نهایی با خودت است. بازنویسی آموزشی پرامپت زیر فقط درخواست بازبینی است:
پیش از ساخت خروجی انتشار، تغییرات فعلی را برای نشت اعتبارنامه و تنظیمات حساس بررسی کن. فایل‌های مشکوک، محل استفاده و ریسک هر مورد را گزارش بده؛ مقدار هیچ کلیدی را در پاسخ تکرار نکن. همچنین بگو کدام مسیرهای اندروید، به‌خصوص اتصال سرویس و مجوز میکروفون، هنوز آزمون نشده‌اند. بدون تأیید من چیزی را منتشر نکن.
در کار گروهی، همین تغییرات باید در درخواست بازبینی کد دیده شوند و آزمون‌های مربوط نیز اجرا شوند. خروجی عامل، حتی اگر برنامه را روی شبیه‌ساز باز کرده باشد، جای بازبینی کد و کنترل امنیت را نمی‌گیرد. نتیجهٔ این مرحله فهرست ریسک‌های حل‌شده و بازمانده است؛ اگر مورد حساسی باز مانده، خروجی انتشار را عقب بینداز.
۷. تفاوت خروجی آزمون و خروجی امضاشده را بفهم
وقتی آزمون‌های اولیه جلو رفت، درخواست ساخت خروجی اندروید مطرح شد. برای نصب و آزمون محلی، خروجیِ مناسب همان کار را می‌خواهی؛ برای ارائه به فروشگاه، باید قالب پذیرفته‌شده و امضای انتشار را هم در نظر بگیری. APK بستهٔ قابل نصب اندروید است و Android App Bundle یا AAB قالب دیگری برای توزیع از راه فروشگاه‌های پشتیبان است. تحویل بسته‌های متناسب با دستگاه به قابلیت‌های فروشگاه بستگی دارد؛ بنابراین از این توضیح نتیجه نگیر که هر فروشگاهی هر دو قالب را با روندی یکسان می‌پذیرد.
امضای انتشار نشان می‌دهد به‌روزرسانی‌ها به هویت امضاکنندهٔ مورد انتظار مربوط‌اند. در این اجرا، عامل بدون اینکه ابتدا مشخصات امضا پرسیده شود خروجی امضاشده ساخت؛ همین موضوع باعث شد مشخصات استفاده‌شده بررسی شود. اینجا بهتر است فرایند را متوقف و روشن کنی کلید چگونه ساخته شده، کجا نگهداری می‌شود و چه کسی به آن دسترسی دارد. کلید امضای انتشار را همراه فایل قابل آپلود، در گفت‌وگوی عمومی یا در Git قرار نده و از آن نسخهٔ پشتیبان امن داشته باش. اگر مالکیت و محل نگهداری کلید روشن نیست، «بسته آماده است» پایان کار نیست.
مثال تکمیلی آموزشی: برای ساخت دستی در Android Studio، مسیر Build > Generate Signed Bundle / APK را باز کن، قالب موردنیاز مقصد و ماژول اپ اندروید را انتخاب کن و keystore متعلق به خودت را معرفی کن. اگر این اولین انتشار است، ساخت کلید تازه را آگاهانه انجام بده؛ برای به‌روزرسانی اپ موجود، کلید تازهٔ تصادفی جای کلید قبلی را نمی‌گیرد. سپس variant انتشار و مسیر خروجی را انتخاب کن. گذرواژه و فایل کلید را خارج از مخزن نگه دار و APK حاصل را، اگر همین قالب را ساخته‌ای، روی دستگاه آزمایشی نصب کن. جزئیات امضای هر مسیر در راهنمای رسمی امضای برنامهٔ اندروید آمده است.
۸. خطای فروشگاه را با فایل‌های همان خروجی رفع کن
برای ثبت پیش‌نویس در کافه‌بازار، فایل آماده به همکار مسئول ثبت داده شد. در بار اول، پنل علاوه بر بستهٔ ارسالی، مرحله‌ای مرتبط با محافظت یا پردازش فایل و یک فایل همراه با پسوند .bin مطرح کرد. امضای معمول اندروید به‌تنهایی پاسخ همهٔ درخواست‌های آن مرحله نبود. متن دقیق پنل و راهنمای همان ابزار را باید مبنا قرار بدهی؛ از روی نام فایل حدس نزن که چه محتوایی لازم دارد یا آن را چگونه باید تولید کرد.
برای عیب‌یابی، متن خطا و راهنمای ارائه‌شده در پنل به عامل داده شد. سپس فایل‌های خروجی دوباره آماده و ارسال شدند. نکتهٔ قابل تعمیم این است که فایل‌های همراه باید به همان بسته‌ای تعلق داشته باشند که آپلود می‌کنی: اگر بستهٔ جدید تولید شد، فایل وابسته به بستهٔ قبلی را کنارش نگذار. در این تجربه نیز بستهٔ قبلی با فایل همراه جدید سازگار نبود و آپلود بسته از ابتدا تکرار شد. مثال تکمیلی آموزشی: در گزارش انتشار، برای هر تلاش فقط نام محلی بسته، زمان ساخت، نام فایل همراه و متن پاسخ پنل را ثبت کن؛ خود کلیدها و اطلاعات حساس را وارد گزارش نکن. نتیجهٔ مطلوب، عبور از خطای همان مرحله است، نه فرض اینکه کل فرایند انتشار تأیید شده است.
۹. صفحهٔ فروشگاه را با وضعیت واقعی محصول پر کن
بعد از پذیرش فایل‌ها، نوبت اطلاعات صفحهٔ بازی رسید: نام، دسته‌بندی، توضیح کوتاه و بلند، راه ارتباطی، آیکون و تصاویر برنامه. نام موقت «مافیای هوشمند» و دسته‌بندی معمایی برای پیش‌نویس انتخاب شدند. این‌ها تصمیم‌های محتواییِ قابل بازبینی‌اند، نه ویژگی فنی برنامه. تصاویر را از صفحه‌های واقعی همان نسخه‌ای بگیر که قرار است ارائه شود؛ اگر رابط تغییر کرد، دوباره بررسی‌شان کن. آیکون و توضیحات را نیز خودت فراهم می‌کنی، نه اینکه انتظار داشته باشی فروشگاه از داخل برنامه آن‌ها را بسازد.
در توضیحات، قولی بده که اکنون قابل انجام است: یک نفر می‌تواند بدون منتظر ماندن برای هم‌بازی انسانی با بازیکن‌های هوش مصنوعی تمرین کند. از عبارت «کاملاً رایگان» استفاده نکن، مگر شرایط استفاده و پرداخت واقعاً چنین چیزی را تأیید کند. قابلیت‌هایی مثل بازی چندنفره با دوستان یا راهنمای زندهٔ هوش مصنوعی در این مرحله ایده بودند، نه ویژگی آماده. همین دقت دربارهٔ پرداخت هم لازم است: پیش از ثبت نهایی باید مسیر شارژ و پرداخت درون‌برنامه‌ای را با الزامات جاری فروشگاهی که انتخاب کرده‌ای تطبیق بدهی؛ قوانین و جزئیات پنل ممکن است تغییر کنند.
۱۰. وضعیت ثبت را از انتشار جدا کن
در انتهای فرم، دربارهٔ مجوز ضبط صدا هم توضیح خواسته شد، چون بازی برای تبدیل گفتار کاربر به متن از ورودی صوتی استفاده می‌کند. توضیح مجوز باید با رفتار واقعی برنامه مطابق باشد. اگر هنوز مطمئن نیستی درخواست مجوز در لحظهٔ درست روی اندروید نمایش داده می‌شود، آن را به آزمون‌های بازمانده اضافه کن. سپس قبل از هر تأیید نهایی، دوباره اطلاعات صفحه، فایل ارسالی، وضعیت پرداخت و مسیر صوتی را مرور کن.
هنگام ارسال درخواست، پنل ابتدا خطایی نامشخص و سپس پیامی دربارهٔ پیدا نشدن پیش‌نویس نشان داد؛ با مراجعه به فهرست برنامه‌ها، مورد ثبت‌شده با وضعیت «در صف انتظار» دیده شد. از این مشاهده فقط می‌توان گفت یک مورد در پنل ثبت و وارد صف شده است. نمی‌توان نتیجه گرفت بررسی فروشگاه تمام شده، انتشار عمومی انجام شده یا برنامه روی گوشی کاربران بی‌اشکال خواهد بود.
تحویل واقعی تو پس از این آموزش یک پوشه یا یادداشت پروژه شامل سه چیز است: گزارش آزمون وب و اندروید با موارد انجام‌نشده، مشخصات غیرحساسِ بستهٔ امضاشده و فایل‌های همراه همان خروجی، و پیش‌نویس متن و تصاویر صفحهٔ فروشگاه. پیش از انتشار عمومی، موردهای باز ــ به‌ویژه مجوز و ضبط صدا، پرداخت و نگهداری کلید امضا ــ را ببند. نسخهٔ اولیه لازم نیست پر از قابلیت باشد؛ باید همان قابلیت‌های محدودی را که وعده می‌دهد، قابل اتکا اجرا کند.
مطالعهٔ مرتبط
طراحی بازی مافیای فارسی با KMP و هوش مصنوعی؛ قوانین، نقش‌ها و نمونهٔ اولیه
ویدیوی کامل
اگر می‌خواهی روند کار و آزمون‌ها را هم ببینی، ویدیوی کامل این آموزش اینجاست:
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.