Silent Push چیست؟ تفاوت پوش بی‌صدا در وب و اپلیکیشن
پاسخ کوتاه این است: Silent Push در اپلیکیشن بومی ممکن است برای همگام‌سازی یا پردازش محدود پس‌زمینه قابل استفاده باشد، اما در وب یک قابلیت عمومی و قابل‌حمل برای دریافت پیام بدون نمایش نیست. در Safari و WebKit باید فرض را بر حفظ اعلان قابل مشاهده بگذارید؛ بازبودن صفحه، بی‌صدا بودن اعلان یا استفاده از پیام داده‌ای، این الزام را به‌طور عمومی حذف نمی‌کند.
در این مقاله:
- پوش بی‌صدا دقیقاً به چه معناست؟
- رفتار پوش پس‌زمینه در اپلیکیشن بومی
- چرا وب Silent Push قابل‌حمل نیست؟
- الزام WebKit و تفاوت وب‌اپ آیفون با تب معمولی
- وقتی صفحه باز است چه سیاستی مناسب است؟
- الگوی عملی طراحی و عیب‌یابی
- پرسش‌های رایج
در این مقاله، «پوش بی‌صدا» را از دو مفهوم جدا می‌کنیم: اعلانی که نمایش داده می‌شود اما صدا یا لرزش ندارد، و پیامی که کاربر چیزی نمی‌بیند و برنامه در پس‌زمینه آن را پردازش می‌کند. این دو از نظر فنی و سیاست پلتفرم یکسان نیستند.
پوش بی‌صدا دقیقاً به چه معناست؟
یک اعلان می‌تواند از نظر صوتی بی‌صدا باشد، ولی همچنان در مرکز اعلان یا روی صفحه قفل دیده شود. در این حالت، کاربر از دریافت پیام آگاه می‌شود و فقط صدای اعلان پخش نمی‌شود؛ کنترل صدا، لرزش و نمایش معمولاً در اختیار سیستم‌عامل و تنظیمات کاربر است.
در معنای دوم، Silent Push پیامی است که برای اجرای منطق برنامه، تازه‌کردن داده یا علامت‌گذاری وضعیت ارسال می‌شود و قرار نیست رابط اعلان به کاربر نشان دهد. این رفتار به نوع پیام، مجوزها، وضعیت برنامه، انرژی دستگاه و تصمیم سیستم‌عامل بستگی دارد. بنابراین «ارسال موفق» به‌تنهایی به معنای «اجرای حتمی کد در پس‌زمینه» نیست.
رفتار پوش پس‌زمینه در اپلیکیشن بومی
اپلیکیشن بومی می‌تواند در برخی پلتفرم‌ها از پیام‌های داده‌ای یا پس‌زمینه برای کارهایی مانند تازه‌کردن محتوای محدود استفاده کند. بااین‌حال، سیستم‌عامل زمان اجرا، منابع پردازنده، شبکه و تعداد دفعات اجرای چنین کاری را کنترل می‌کند. حالت ذخیره انرژی، فعالیت کم‌کاربرد برنامه، محدودیت شبکه یا تنظیمات کاربر می‌تواند اجرا را به تعویق بیندازد یا مانع آن شود.
پس این مسیر جایگزین اجرای دائمی، همگام‌سازی فوری یا صف پردازش تضمین‌شده نیست. برای کار مهم، داده را روی سرور مرجع نگه دارید و اپلیکیشن را طوری بسازید که هنگام بازشدن، وضعیت نهایی را دوباره دریافت و بررسی کند. پوش باید محرک احتمالی برای تازه‌سازی باشد، نه تنها محل نگهداری داده.
در اندروید نیز اجازه اعلان و کانال اعلان جداگانه اهمیت دارد. از اندروید ۱۳، کاربر برای اعلان‌ها مجوز زمان اجرا دارد و در اندروید ۸ به بعد، کانال و تنظیمات هر کانال می‌تواند بر رفتار اعلان اثر بگذارد. جزئیات رسمی این دو موضوع در مستندات مجوز اعلان اندروید و راهنمای کانال‌های اعلان توضیح داده شده است.
چرا وب Silent Push قابل‌حمل نیست؟
در وب، سرویس‌ورکر به مرورگر اجازه می‌دهد رویداد پوش را خارج از صفحه فعال دریافت کند، اما مرورگر درباره زمان اجرا، منابع و نحوه رفتار تصمیم می‌گیرد. هیچ قرارداد عمومی وجود ندارد که یک پیام نامرئی را در همه مرورگرها و سیستم‌عامل‌ها، با زمان‌بندی و نتیجه یکسان، تحویل دهد.
در نتیجه، طراحی وب‌پوش باید بر یک اعلان مرتبط و قابل مشاهده استوار باشد؛ نه بر این فرض که سرویس‌ورکر همیشه می‌تواند بدون اطلاع کاربر داده را تغییر دهد. اگر هدف شما فقط تازه‌کردن رابط در زمان حضور کاربر است، همان صفحه می‌تواند از درخواست شبکه، ارتباط زنده یا خواندن دوباره وضعیت از سرور استفاده کند.
در وب‌پوش، انقضای پیام نیز تضمین نگهداری نامحدود نیست. برای دستگاه آفلاین، زمان اعتبار یا TTL فقط بازه‌ای را مشخص می‌کند که پیام می‌تواند برای تحویل نگه داشته شود؛ پس از پایان آن، نباید دریافت دیرهنگام را قطعی فرض کرد. برای بررسی این موضوع، راهنمای طول عمر پیام در FCM را ببینید.
الزام WebKit و تفاوت وب‌اپ آیفون با تب معمولی
WebKit برای پوش وب به نمایش اعلان قابل مشاهده وابسته است؛ بنابراین نباید در Safari مسیر ارسال پیام نامرئی یا حذف عمدی اعلان را راهکار عمومی بدانید. این موضوع با «اعلان بدون صدا» فرق دارد: ممکن است اعلان نمایش داده شود اما کاربر صدا یا لرزش را خاموش کرده باشد.
در iOS و iPadOS، وب‌اپی که کاربر آن را به صفحه اصلی افزوده است می‌تواند از نسخه ۱۶.۴ به بعد، پس از یک اقدام مستقیم کاربر، درخواست مجوز پوش کند. این وضعیت را نباید به تب معمولی Safari تعمیم داد. توضیح WebKit درباره این شرط‌ها در راهنمای Web Push برای وب‌اپ‌های iOS و iPadOS آمده است.
چک‌لیست سازگاری Safari:
- بررسی کنید کاربر وب‌سایت را به صفحه اصلی افزوده و مجوز لازم را در مسیر درست صادر کرده باشد.
- برای پیام‌های دریافت‌شده در WebKit، نمایش اعلان را سرکوب نکنید.
- تب معمولی، وب‌اپ نصب‌شده و اپلیکیشن بومی را در گزارش آزمایش جداگانه ثبت کنید.
- در صورت شکست دریافت، مجوز، تنظیمات اعلان، وضعیت دستگاه و رخداد سرویس‌ورکر را جدا از یکدیگر بررسی کنید.
وقتی صفحه باز است چه سیاستی مناسب است؟
بازبودن صفحه یک استثنای عمومی برای حذف اعلان نیست. تیم محصول می‌تواند در حالت فعال‌بودن صفحه، پیام را داخل رابط نشان دهد تا کاربر یک پیام تکراری در صفحه و سیستم‌عامل نبیند؛ اما این تصمیم باید برای هر مرورگر، نوع payload و قرارداد سرویس‌ورکر آزمایش شود.
یک سیاست عملی می‌تواند چنین باشد: اگر صفحه فعال است و رویداد داخلی با موفقیت به رابط رسید، رابط را به‌روز کنید؛ اگر صفحه فعال نیست، اعلان قابل مشاهده و کوتاه نشان دهید؛ اگر وضعیت صفحه نامشخص است یا به‌روزرسانی داخلی شکست خورد، به‌جای مخفی‌کردن پیام، مسیر اعلان را حفظ کنید. در هیچ‌یک از این حالت‌ها، «بی‌صدا» را معادل «نامرئی» نگیرید.
گزارش تحویل نیز باید دقیق نام‌گذاری شود. موفقیت اجرای showNotification یا ثبت نمایش در کلاینت، در بهترین حالت نشانه نمایش فنی است و ثابت نمی‌کند انسان اعلان را دیده یا روی آن کلیک کرده است. برای تحلیل، نمایش، کلیک و اقدام نهایی کاربر را رویدادهای جداگانه در نظر بگیرید.
الگوی عملی طراحی و عیب‌یابی
برای به‌روزرسانی داده
- داده اصلی را در سرور نگه دارید و برای هر رکورد نسخه یا زمان آخرین تغییر داشته باشید.
- در پیام، فقط اطلاعات لازم برای شناسایی تغییر را بفرستید؛ کل وضعیت حساس یا اطلاعات شخصی را داخل اعلان و نشانی صفحه قرار ندهید.
- پس از بازشدن صفحه یا اپلیکیشن، وضعیت را از سرور بخوانید و امکان تکرار یا ازدست‌رفتن پیام را مدیریت کنید.
- اگر نمایش اعلان الزامی است، عنوان و متن را برای اطلاع‌رسانی واقعی طراحی کنید، نه یک پیام خالی که فقط اجرای پس‌زمینه را پنهان کند.
برای آزمایش
| سناریو | چیزی که باید ثبت شود | نتیجه قابل اتکا |
|---|---|---|
| صفحه فعال | وضعیت رابط، رخداد دریافت و نمایش | آیا پیام داخلی جایگزین مناسبی برای اعلان بود؟ |
| صفحه بسته یا دستگاه قفل | مجوز، اعلان سیستم و زمان دریافت | آیا اعلان قابل مشاهده نشان داده شد؟ |
| دستگاه آفلاین | زمان ارسال، TTL و زمان اتصال دوباره | آیا پیام هنوز معتبر بود یا باید وضعیت از سرور خوانده شود؟ |
| Safari وب‌اپ | افزوده‌شدن به صفحه اصلی، مجوز و نمایش | آیا مسیر WebKit را جداگانه رعایت کردید؟ |
اگر از Pushfa استفاده می‌کنید، سرویس‌ورکر و تنظیم نمایش را دقیقاً مطابق کدی نصب کنید که در پنل سرویس ارائه شده است؛ نام بسته، تابع یا فایل جایگزین را حدس نزنید. کلید عمومی سرویس برای اتصال کلاینت استفاده می‌شود و کلیدهای خصوصی باید فقط روی سرور بمانند. برای خطاهای عمومی دریافت، می‌توانید راهنمای چرا پوش ارسال می‌شود اما دریافت نمی‌شود؟ را هم بررسی کنید.
برای مقایسه رفتارهای متفاوت پیام و جلوگیری از نتیجه‌گیری عجولانه، لاگ‌های سرور، گزارش سرویس پوش، رخداد سرویس‌ورکر و اقدام کاربر را جدا نگه دارید. یک تست موفق روی کروم دسکتاپ، سازگاری با Safari، اندروید یا اپلیکیشن بومی را ثابت نمی‌کند.
پرسش‌های رایج
آیا Silent Push در Safari کاملاً غیرممکن است؟
نباید روی پیام نامرئی به‌عنوان قابلیت عمومی و قابل‌حمل حساب کرد. در مسیرهای WebKit که به رویداد پوش متکی هستند، اعلان قابل مشاهده را حفظ کنید و برای پردازش بی‌صدا وعده عمومی ندهید.
آیا اعلان بدون صدا همان Silent Push است؟
خیر. اعلان بدون صدا هنوز قابل مشاهده است؛ Silent Push در معنای رایج، پیامی است که بدون رابط اعلان برای پردازش پس‌زمینه به کار می‌رود.
آیا با بازبودن تب می‌توان اعلان را همیشه مخفی کرد؟
خیر. برای صفحه فعال می‌توان سیاست نمایش داخل رابط تعریف کرد، اما باید آن را در مرورگرها و وضعیت‌های مختلف آزمایش کرد و در صورت نامشخص‌بودن یا شکست پردازش، نمایش اعلان را حذف نکرد.
آیا دریافت پیام به معنی خواندن آن است؟
خیر. دریافت یا نمایش فنی فقط یک مرحله از زنجیره است. مشاهده انسانی، کلیک و اقدام نهایی باید با رویدادهای جداگانه سنجیده شوند.