Live Activities در iOS چیست؟ تفاوت با پوش نوتیفیکیشن
پاسخ کوتاه: Live Activities یک سطح نمایشی بومی در اپلیکیشن iOS برای دنبال‌کردن وضعیت یک رویداد در حال انجام است؛ مثلاً امتیاز مسابقه، زمان رسیدن خودرو یا مرحله سفارش. پوش نوتیفیکیشن یک اعلان گسسته برای اطلاع‌دادن از یک رویداد است و وب‌پوش نیز به وب‌سایت یا وب‌اپ وابسته است. بنابراین Live Activities جایگزین عمومی پوش نوتیفیکیشن یا وب‌پوش نیست و فقط برای رویدادهایی مناسب است که وضعیت آن‌ها در یک بازه محدود تغییر می‌کند.
در این مقاله:
- Live Activities دقیقاً چیست؟
- تفاوت با پوش نوتیفیکیشن و وب‌پوش
- چه رویدادهایی برای آن مناسب‌اند؟
- مراحل پیاده‌سازی با ActivityKit
- چرخه عمر و محدودیت‌های سیستم
- راهنمای انتخاب و طراحی مسیر ارسال
- پرسش‌های متداول
این قابلیت با چارچوب ActivityKit در اپ بومی iOS پیاده‌سازی می‌شود. داشتن یک سرویس ارسال پوش، به‌تنهایی ActivityKit را به اپ اضافه نمی‌کند؛ اپ باید ساختار فعالیت، رابط نمایش و چرخه عمر آن را خودش تعریف کند.
Live Activities دقیقاً چیست؟
Live Activity نمایی است که اپ برای یک رویداد مشخص ایجاد می‌کند و سیستم آن را در بخش‌هایی مانند صفحه قفل یا، روی دستگاه‌های سازگار، Dynamic Island نشان می‌دهد. محتوای این نما شامل داده‌های ثابت فعالیت و وضعیت جاری آن است؛ برای نمونه شماره سفارش می‌تواند ثابت بماند، اما وضعیت از «در حال آماده‌سازی» به «در مسیر» تغییر کند.
تفاوت مهم آن با اعلان معمولی، مدل ذهنی کاربر است: اعلان می‌گوید «چیزی رخ داده»، اما Live Activity می‌گوید «این رویداد اکنون در چه وضعیتی است». بااین‌حال، کلمه «زنده» به معنی به‌روزرسانی نامحدود یا تضمین نمایش دائمی نیست. سیستم‌عامل و تنظیمات کاربر درباره زمان نمایش، به‌روزرسانی و پایان فعالیت تصمیم نهایی را دارند.
Live Activities به یک اپ بومی iOS و معمولاً یک Widget Extension نیاز دارد. رابط آن با SwiftUI تعریف می‌شود و داده‌های فعالیت باید کوچک، روشن و مناسب نگاه سریع باشند. این قابلیت برای صفحه‌ای طولانی، فهرست کامل سفارش یا جایگزین‌کردن یک اپلیکیشن طراحی نشده است.
تفاوت با پوش نوتیفیکیشن و وب‌پوش
| موضوع | Live Activities | پوش نوتیفیکیشن | وب‌پوش |
|---|---|---|---|
| هدف | نمایش وضعیت یک رویداد فعال | اعلام یک رویداد یا پیام | اعلام پیام از وب‌سایت یا وب‌اپ |
| سطح نمایش | صفحه قفل و نواحی پشتیبانی‌شده iOS | مرکز اعلان و بنرهای سیستم | اعلان سیستم پس از عضویت وب‌اپ |
| نیاز اصلی | اپ iOS با ActivityKit | اپ موبایل یا سرویس اعلان مربوط به پلتفرم | سرویس‌ورکر و اشتراک وب |
| مدل محتوا | وضعیت قابل تغییر در همان فعالیت | پیام‌های مستقل | پیام‌های مستقل وب |
| کاربرد نمونه | زمان رسیدن خودرو | «سفارش شما ثبت شد» | «مقاله جدید منتشر شد» |
در یک اپ سفارش غذا، می‌توان پس از ثبت سفارش یک اعلان معمولی فرستاد، سپس برای مراحل آماده‌سازی و ارسال یک Live Activity ساخت و در پایان فعالیت را بست. اگر فقط یک تغییر مهم وجود دارد، اعلان معمولی ساده‌تر و مناسب‌تر است. اگر کاربر وب‌سایت است، این مسیر به ActivityKit تبدیل نمی‌شود و باید از وب‌پوش استفاده شود.
برای آشنایی با تفاوت‌های کلی اعلان‌های اپلیکیشن در دو سیستم‌عامل، مقایسه پوش نوتیفیکیشن اندروید و iOS را ببینید. وب‌پوش iOS نیز شرایط جداگانه‌ای دارد؛ در iOS و iPadOS 16.4 به بعد، درخواست مجوز وب‌پوش برای وب‌اپی مطرح می‌شود که کاربر آن را به صفحه اصلی افزوده باشد، نه هر زبانه معمولی مرورگر. توضیح WebKit درباره وب‌پوش در iOS و iPadOS این تفاوت را شرح می‌دهد.
چه رویدادهایی برای آن مناسب‌اند؟
پیش از انتخاب Live Activities، باید بپرسید آیا کاربر واقعاً لازم است وضعیت رویداد را چند بار در یک بازه محدود ببیند یا یک اعلان و لینک کافی است.
سناریوهای مناسب
- حمل‌ونقل: زمان تقریبی رسیدن خودرو یا تغییر مرحله سفر.
- ورزش: نتیجه و وضعیت مسابقه‌ای که کاربر آن را دنبال کرده است.
- سفارش: مرحله سفارش از آماده‌سازی تا تحویل.
- رویداد محدود به زمان: شمارش معکوس یا وضعیت یک جلسه در حال برگزاری.
سناریوهای نامناسب
- تبلیغات، خبررسانی عمومی و پیام‌هایی که فقط یک‌بار باید دیده شوند.
- اطلاعاتی که دائماً تغییر می‌کند اما هر تغییر برای کاربر ارزش ندارد.
- داده‌های حساس که نمایش آن‌ها روی صفحه قفل بدون طراحی حریم خصوصی مناسب است.
- رویدادهایی که پایان مشخصی ندارند یا ممکن است هفته‌ها ادامه داشته باشند.
مثال زیر صرفاً یک الگوی طراحی فرضی است: برای سفارش «۴۸۲۱»، فعالیت با وضعیت «در حال آماده‌سازی» آغاز می‌شود، هنگام خروج پیک به «در مسیر» تغییر می‌کند و پس از تحویل پایان می‌یابد. در کنار آن، فقط برای رخدادهایی مانند تأخیر قابل‌توجه می‌توان اعلان جداگانه فرستاد؛ لازم نیست هر تغییر کوچک هم اعلان صوتی ایجاد کند.
مراحل پیاده‌سازی با ActivityKit
- مدل داده را محدود کنید. ویژگی‌های ثابت مانند شناسه سفارش را از وضعیت متغیر مانند مرحله و زمان تقریبی جدا کنید. داده‌ای را وارد فعالیت کنید که برای نگاه سریع ضروری است.
- رابط نمایش را در Widget Extension بسازید. حالت‌های صفحه قفل و ناحیه‌های پشتیبانی‌شده را در نظر بگیرید. ظاهر فعالیت روی همه مدل‌ها یکسان نیست؛ Dynamic Island فقط در دستگاه‌های سازگار وجود دارد.
- فعالیت را از داخل اپ آغاز کنید. اپ پس از اقدام مشخص کاربر یا ایجاد رویداد معتبر، فعالیت را با وضعیت اولیه درخواست می‌کند. نمونه ساده زیر فقط الگوی بومی ActivityKit است و جایگزین طراحی کامل Attributes و رابط SwiftUI نیست:
let attributes = OrderAttributes(orderID: "4821")
let state = OrderAttributes.ContentState(status: "در حال آماده‌سازی")
let activity = try? Activity<OrderAttributes>.request(
attributes: attributes,
contentState: state,
pushType: .token
)اگر فعالیت با توکن پوش ساخته شود، اپ می‌تواند توکن مربوط به همان فعالیت را به سرور خود منتقل کند. سرور سپس باید مسیر اختصاصی اعلان‌های Live Activities اپل را جدا از سرویس عمومی ارسال اعلان پیاده‌سازی کند. این فرایند، با ارسال یک پیام وب‌پوش یا اعلان معمولی یکسان نیست.
- به‌روزرسانی را کنترل کنید. تغییرات معنادار را ارسال کنید، نه داده‌ای که هر ثانیه تغییر می‌کند. برای به‌روزرسانی از داخل اپ از APIهای ActivityKit و برای به‌روزرسانی از راه دور از سازوکار اختصاصی APNs استفاده می‌شود.
- پایان فعالیت را مدیریت کنید. پس از تحویل سفارش، پایان مسابقه یا اتمام سفر، فعالیت را با وضعیت نهایی ببندید. در صورت خطا یا لغو نیز وضعیت را روشن کنید تا کارت قدیمی باقی نماند.
پوشفا امکاناتی مانند FCM، توکن‌های مشترک، موضوع‌ها، گزارش ارسال و کلیک و APIهای سرور برای پوش‌های پشتیبانی‌شده خود دارد؛ اما نباید فرض کرد اتصال پوشفا به‌طور خودکار ActivityKit را برای اپ فعال می‌کند. اگر تیم شما به این قابلیت نیاز دارد، پیاده‌سازی اپل و سرور مربوط به Live Activities باید جداگانه بررسی و توسعه داده شود.
چرخه عمر و محدودیت‌های سیستم
فعالیت زنده یک صفحه دائمی و بدون محدودیت نیست. کاربر می‌تواند نمایش Live Activities را در تنظیمات کنترل کند و سیستم‌عامل نیز با توجه به نسخه iOS، دستگاه، وضعیت فعالیت و سیاست‌های خود درباره نمایش و به‌روزرسانی تصمیم می‌گیرد. نباید برای تعداد ثابت فعالیت‌های هم‌زمان، مدت نمایش مشخص یا نرخ به‌روزرسانی تضمین‌شده وعده داد.
همچنین، ارسال موفق داده به سرویس انتقال به معنی دیده‌شدن آن توسط انسان نیست. حتی در اعلان‌های معمولی، تحویل یا نمایش موفق با خواندن، لمس‌کردن یا انجام اقدام توسط کاربر تفاوت دارد. در طراحی محصول، وضعیت‌های «ارسال شد»، «نمایش داده شد» و «کاربر اقدام کرد» را جداگانه تحلیل کنید.
به‌روزرسانی‌های زیاد می‌توانند تجربه کاربر و مصرف منابع را بدتر کنند. برای هر رویداد یک حداقل فاصله یا قاعده تغییر تعریف کنید؛ برای نمونه، زمان رسیدن را فقط وقتی تغییر دهید که اختلاف آن برای کاربر معنادار باشد. داده‌های خصوصی مانند جزئیات کامل سفارش یا اطلاعات مکانی دقیق را روی صفحه قفل نمایش ندهید، مگر اینکه نیاز و طراحی حریم خصوصی آن روشن باشد.
در وب‌پوش نیز محدودیت مشابهی با ActivityKit وجود ندارد، اما قواعد خودش را دارد. اعلان وب باید به شکل قابل‌مشاهده نمایش داده شود؛ بنابراین نباید برای Safari توصیه کرد پیام را بی‌صدا دریافت و از نمایش اعلان جلوگیری کنید. برای بررسی ریشه‌های فنی تحویل اعلان، مقاله زیرساخت فنی وب‌پوش مفید است.
راهنمای انتخاب و طراحی مسیر ارسال
این چک‌لیست را پیش از شروع توسعه بررسی کنید:
- آیا رویداد شروع و پایان مشخص دارد؟ اگر نه، Live Activities احتمالاً انتخاب خوبی نیست.
- آیا کاربر به وضعیت جاری نیاز دارد یا یک پیام کافی است؟ برای پیام، پوش معمولی را انتخاب کنید.
- آیا مخاطب اپ بومی iOS دارد؟ کاربران وب‌سایت به مسیر وب‌پوش نیاز دارند.
- آیا تیم شما می‌تواند ActivityKit، Widget Extension، توکن فعالیت و مسیر APNs را نگهداری کند؟
- آیا برای توقف، لغو، خطای سرور و تغییر نظر کاربر وضعیت مشخص دارید؟
- آیا در تست، مدل‌های مختلف آیفون، نسخه‌های مختلف iOS و حالت‌های محدودیت سیستم بررسی شده‌اند؟
معماری پیشنهادی می‌تواند دو مسیر مستقل داشته باشد: مسیر اپل برای فعالیت زنده و مسیر اعلان معمولی یا وب‌پوش برای پیام‌های رویدادی. این دو را در لایه تصمیم‌گیری کسب‌وکار هماهنگ کنید، اما آن‌ها را یک فناوری واحد در نظر نگیرید. برای نمونه، آغاز سفارش می‌تواند اعلان عادی و فعالیت زنده داشته باشد، ولی هر دو باید قواعد لغو، زمان پایان و حریم خصوصی مشترکی داشته باشند.
پرسش‌های متداول
آیا Live Activities همان پوش نوتیفیکیشن است؟
خیر. هر دو می‌توانند از انتقال فشاری استفاده کنند، اما Live Activities محتوای یک فعالیت موجود را به‌روزرسانی می‌کند و پوش معمولی یک اعلان مستقل می‌سازد.
آیا می‌توان با وب‌پوش یک Live Activity ساخت؟
خیر. وب‌پوش برای وب‌سایت یا وب‌اپ است و ActivityKit به اپ بومی iOS و اجزای مرتبط آن نیاز دارد.
آیا Live Activity همیشه روی صفحه می‌ماند؟
خیر. کاربر و سیستم‌عامل می‌توانند نمایش یا ادامه فعالیت را محدود کنند و برنامه نیز باید هنگام پایان رویداد آن را خاتمه دهد.
آیا سرویس پوش به‌تنهایی ActivityKit را فعال می‌کند؟
خیر. سرویس ارسال می‌تواند بخشی از زیرساخت انتقال باشد، اما مدل داده، رابط، چرخه عمر و مسیر اختصاصی Live Activities باید در اپ و سرور شما پیاده‌سازی شود.