Live Updates اندروید؛ طراحی رهگیری سفارش در کنار Live Activities
کاربری که منتظر پیک غذاست معمولاً یک سؤال دارد: «سفارشم الآن کجاست؟» Live Updates اندروید برای نمایش وضعیت یک فعالیت جاری طراحی شده است. نمایش وضعیت باید پایان مشخص و اطلاعات قابل اعتماد داشته باشد.
Live Updates چیست و چه مسئلهای را حل میکند؟
اندروید ۱۶، Notification.ProgressStyle را برای نمایش پیشرفت و نقاط مهم یک مسیر معرفی کرد. تحویل غذا، سفر با خودرو و مسیریابی از نمونههای مناسب آن هستند. این سبک، نمایش مراحل را ممکن میکند؛ داشتن نوار پیشرفت، نمایش برجسته را تضمین نمیکند. مستند اعلانهای مبتنی بر پیشرفت اندروید اجزای این نمایش را توضیح میدهد.
طبق راهنمای رسمی Live Updates، فعالیت باید جاری، آغازشده با خواست کاربر و حساس به زمان باشد. کمپین تخفیف و پیام تبلیغاتی کاربرد مناسبی نیستند. حتی رهگیری بستهای که چند روز در راه است، به مشاهده مداوم نیاز ندارد. برای فروشگاه، مرز کاربرد را روشن کنید: ثبت خرید یک رویداد است؛ حرکت پیک در مسیر کوتاهِ تحویل، یک فعالیت قابل رهگیری.
مقایسه Live Updates اندروید و Live Activities آیفون
برای آشنایی جداگانه با سمت اپل، راهنمای Live Activities در iOS را بخوانید.
| موضوع | اندروید | iOS |
|---|---|---|
| نمایش | اعلان واجد شرایط با امکان برجستهشدن توسط سیستم | رابط Live Activity با ActivityKit و افزونه ویجت |
| ساخت رابط | APIهای اعلان اپلیکیشن؛ ProgressStyle برای مراحل پیشرفت | SwiftUI و WidgetKit در مسیر ActivityKit |
| بهروزرسانی از سرور | داده وضعیت به اپ میرسد و اپ اعلان را بهروز میکند | پوش مخصوص ActivityKit از طریق APNs |
| نیاز مشترک | شناسه فعالیت، وضعیت معتبر، مدیریت پایان و مسیر جایگزین | |
در مسیر اپل، توکن Live Activity را باید از ActivityKit دریافت و تغییرات آن را مدیریت کرد؛ توکن معمول اعلان جایگزین این قرارداد نیست. سرور برای بهروزرسانی و پایان، درخواست متناسب با ActivityKit به APNs میفرستد. جزئیات در مستند شروع و بهروزرسانی Live Activities آمده است. مدل وضعیت سفارش را میتوانید مشترک نگه دارید، ولی تبدیل آن به رابط و پیام هر سیستمعامل را جدا طراحی کنید.
شرایط نمایش برجسته در اندروید را جدا بررسی کنید
برای واجد شرایط بودن، اعلان باید عنوان و وضعیت ongoing داشته باشد، از سبک پشتیبانیشده استفاده کند و درخواست برجستهشدن بدهد. RemoteViews سفارشی و کانال با اهمیت IMPORTANCE_MIN مناسب این مسیر نیستند. سازنده دستگاه میتواند شرط اضافه بگذارد؛ کاربر نیز میتواند اعلان را به حالت معمول برگرداند یا کنار بگذارد. جزئیات در شرایط رسمی Live Updates آمده است.
در مرجع مجوزهای اندروید، POST_PROMOTED_NOTIFICATIONS از API نسخه ۳۶٫۱ اضافه شده است. این مجوز در Manifest اعلام میشود و جای POST_NOTIFICATIONS را نمیگیرد. نسخه API و وضعیت دسترسی اعلان را جدا بررسی کنید.
بنابراین «پیام به گوشی رسید» و «Live Update برجسته شد» را یک نتیجه حساب نکنید. وضعیت قابلیت دستگاه و انتخاب کاربر باید وارد تصمیم نمایش شود. پیشنیازهای عمومی را در راهنمای پوش اندروید و تنظیمات دسته اعلان را در راهنمای Notification Channel دنبال کنید.
نمونه چرخه سفارش: از آمادهسازی تا پایان
مثال زیر یک طراحی پیشنهادی برای سفارش غذای فرضی است، نه گزارش عملکرد یک کسبوکار. ابتدا مشخص کنید کدام بخش واقعاً نیازمند مشاهده لحظهای است. اگر زمان آمادهسازی طولانی و نامعلوم است، صفحه سفارش و یک اعلان معمول ممکن است کافی باشد؛ رهگیری زنده را برای بازهای شروع کنید که اطلاعات مرتب و کاربردی دارید.
- ثبت سفارش: رسید را در صفحه سفارش نشان دهید. این مرحله بهتنهایی دلیل ساخت فعالیت زنده نیست. توضیح دهید رهگیری در زمان مناسب در دسترس قرار میگیرد.
- آمادهسازی: متن «سفارش در حال آمادهسازی است» از درصد ساختگی دقیقتر است. اگر تخمین معتبر ندارید، زمان قطعی نسازید.
- حرکت پیک: مرحله و بازه رسیدن را نمایش دهید؛ مثلاً «پیک در مسیر؛ حدود ۱۰ تا ۱۵ دقیقه». عدد این مثال صرفاً نمونه متن است.
- تأخیر: وضعیت را صریح به «زمان رسیدن در حال محاسبه است» تغییر دهید. کاربر نباید همچنان وعده قبلی را ببیند.
- تحویل یا لغو: فعالیت را وارد وضعیت پایانی کنید. لغو نباید تا رسیدن پیام بعدی، پشت نمایش «پیک در مسیر» پنهان بماند.
برای هر مرحله یک اقدام اصلی داشته باشید: مشاهده سفارش، تماس با پشتیبانی یا اصلاح نشانی در زمانی که هنوز امکانش وجود دارد. اقدام منقضی را حذف کنید. کاربر نباید پس از تحویل، دکمهای ببیند که تغییر نشانی را وعده میدهد.
مدل وضعیت سرور را پیش از رابط طراحی کنید
در طراحی پیشنهادی، هر فعالیت یک شناسه مستقل از شناسه دستگاه دارد و به سفارش و مالک آن متصل است. کنار وضعیت، نسخه تغییر، زمان ثبت داده و پایان فعالیت را ذخیره کنید. هدف این است که پیام دیررسِ «آمادهسازی» نتواند وضعیت جدیدترِ «تحویل شد» را برگرداند. قانون تقدم را در مدل کسبوکار تعیین کنید؛ ترتیب رسیدن پیامها را مبنای حقیقت نگذارید.
برای بهروزرسانیهای معمول، جدیدترین وضعیت معتبر را بفرستید و تغییرات بیاهمیت را تجمیع کنید. هر حرکت پیک نباید هشدار تازه بسازد. این تفکیک در راهنمای طراحی Live Updates هم پیشنهاد شده است. در مقابل، لغو سفارش یا تغییر مهم مقصد باید مسیر روشن و اولویت متناسب داشته باشد. صفحه سفارش همواره مرجع نهایی باشد تا کاربر پس از بازکردن اپ بتواند اطلاعات جاری را بگیرد.
قطع ارتباط را نیز به یک وضعیت طراحیشده تبدیل کنید: «آخرین بهروزرسانی در ساعت…» بهتر از نمایش تخمینی است که معلوم نیست هنوز معتبر باشد. برای سفارش پایانیافته، درخواستهای بهروزرسانی معمول را متوقف کنید و پایان را در سرور ثبت نگه دارید.
حریم خصوصی و کنترل کاربر در صفحه قفل
نشانی کامل و دستور ورود به ساختمان برای یک نگاه سریع لازم نیستند. جزئیات را پشت ورود معتبر به صفحه سفارش قرار دهید. شناسه فعالیت باید به همان حساب و سفارش محدود شود؛ دانستن شناسه، مجوز مشاهده سفارش دیگران نیست.
اگر کاربر رهگیری را کنار گذاشت، همان فعالیت را با هر تغییر کوچک دوباره به او تحمیل نکنید. مسیر توقف رهگیری را روشن نگه دارید. همچنین وضعیت زنده را به فضای فروش مکمل تبدیل نکنید: پیشنهاد غذای بعدی کنار پیکی که الآن در راه است، مسئله دیگری را وارد تجربهای میکند که کاربر برای دریافت سفارش شروع کرده است.
از کجا شروع کنیم و موفقیت را چگونه بسنجیم؟
شروع مناسب، یک جریان محدود با پایان مشخص است؛ مثلاً تحویل نزدیک به مقصد، نه همه انواع سفارش. برای دستگاه یا حساب فاقد شرایط، صفحه رهگیری و اعلان معمولِ رویدادهای مهم را آماده نگه دارید. SDK وب پوش بهتنهایی این رابط بومی را در اندروید یا آیفون ایجاد نمیکند؛ پروژه اپلیکیشن و مسیر سرور مربوط به هر پلتفرم لازم است.
معیارهای پیشنهادی را بر مسئله واقعی بگذارید: تماسهای «سفارشم کجاست؟»، اختلاف تخمین و زمان واقعی، نمایش داده کهنه و توقف رهگیری توسط کاربر. کاهش تعداد کلیک لزوماً شکست نیست؛ ممکن است کاربر پاسخ را بدون بازکردن اپ دیده باشد.
پرسشهای رایج
آیا Live Updates همان پوش نوتیفیکیشن است؟
Live Updates نوعی تجربه نمایش برای فعالیت جاری در اندروید است. پوش میتواند یکی از راههای رساندن داده وضعیت باشد؛ دریافت پیام بهتنهایی این تجربه را ایجاد نمیکند.
آیا ارسال وب پوش پوشفا، Live Activity آیفون میسازد؟
خیر. Live Activity به پیادهسازی ActivityKit در اپ و مسیر بهروزرسانی مخصوص آن نیاز دارد. اعلان مرورگر را نباید معادل این قابلیت معرفی کرد.
آیا میتوان تخفیف روزانه را به Live Update تبدیل کرد؟
این انتخاب با کاربرد تعریفشده برای فعالیت جاری کاربر سازگار نیست. برای تبلیغ، پیام معمول با رضایت و تناوب مناسب انتخاب کنید و رهگیری زنده را برای وضعیت واقعاً مورد انتظار نگه دارید.