وب پوش در حالت آفلاین؛ TTL و شرایط تحویل پس از اتصال
اگر دستگاه هنگام ارسال آفلاین باشد، تحویل بعدی ممکن است، اما تضمینشده نیست. نگهداری پیام به TTL، نوع پیام و سیاست سرویس پوش بستگی دارد. آنلاینشدن دستگاه پس از انقضا پیام را زنده نمیکند و آنلاینشدن قبل از انقضا نیز بهتنهایی نمایش را تضمین نمیکند.
TTL مدت اعتبار است، نه وعده تحویل
TTL یا Time To Live مشخص میکند سرویس ارسال تا چه مدت اجازه دارد پیام را برای تحویل نگه دارد. برای تخفیفی که دو ساعت دیگر تمام میشود، پیام نباید چند روز بعد با همان پیشنهاد برسد. اعتبار محتوا و تنظیم زمان نگهداری را هماهنگ کنید و مقدار نهایی ارسالشده به سرویس پوش را ملاک بگیرید.
طبق مستندات FCM، TTL صفر باعث میشود پیام برای تحویل بعدی ذخیره نشود. امکان نگهداری طولانیتر نیز به معنای ذخیره همیشگی یا تحویل همه پیامها نیست. مقدار پیشفرض و محدودیت هر پلتفرم را در تنظیمات مسیر ارسال بررسی کنید؛ عددی مثل ۲۸ روز را برای همه پیامها تضمین نکنید.
چند نمونه روشن
| وضعیت | نتیجه قابل انتظار |
|---|---|
| TTL دو ساعت است و دستگاه پس از نیم ساعت وصل میشود | در صورت باقیبودن پیام و معتبر بودن مسیر، امکان تحویل وجود دارد؛ تضمین نیست. |
| دستگاه پس از سه ساعت وصل میشود | پیام دو ساعته منقضی شده؛ انتظار تحویل همان پیام درست نیست. |
| TTL صفر و دستگاه غیرقابل دسترس است | نباید انتظار نگهداری برای اتصال بعدی داشت. |
| پیامهای وضعیت با سیاست جایگزینی ارسال شدهاند | ممکن است فقط آخرین وضعیت باقی بماند، نه همه نسخههای قبلی. |
چرا پس از اتصال هم ممکن است پیام دیده نشود؟
- مجوز مرورگر یا سیستم لغو شده است.
- اشتراک نامعتبر شده یا داده برنامه حذف شده است.
- پیام منقضی، جایگزین یا طبق محدودیت سرویس کنار گذاشته شده است.
- دستگاه به اینترنت دسترسی دارد اما به زیرساخت پوش مربوط متصل نمیشود.
- محدودیت باتری، پسزمینه یا تنظیمات نمایش اثر گذاشته است.
- رویداد دریافت اجرا شده اما نمایش یا گزارش با خطا مواجه شده است.
داخلیبودن سرور سایت یا پنل، وابستگی دستگاه به شبکه پوش را حذف نمیکند. هنگام اختلال اینترنت بینالملل نباید وعده داد مسیر عادی حتماً پیام را تحویل میدهد. پذیرش ارسال در سرور و اتصال دوباره دستگاه، دو شرط کافی برای نمایش قطعی نیستند.
پیام را برای تأخیر طراحی کنید
برای پیشنهاد زماندار، TTL را با پایان پیشنهاد هماهنگ کنید و اعتبار آن را در مقصد نیز بررسی کنید. برای وضعیت سفارش، صفحه مقصد باید تازهترین وضعیت را نشان دهد، حتی اگر متن پیام قدیمی باشد. در سامانهای که تاریخچه همه رویدادها اهمیت دارد، آن را در حساب کاربری نگه دارید؛ پوش نوتیفیکیشن بهتنهایی آرشیو قابل اتکای رویدادها نیست.
ارسال دوباره کورکورانه نیز میتواند پیام تکراری بسازد. وضعیت تلاش قبلی و شناسه رویداد را بررسی کنید و برای پیام مهم، مسیر جایگزین متناسب با رضایت و اطلاعات تماس مخاطب طراحی کنید. سنجش موفقیت را بر گزارشهای قابل ثبت بنا کنید و دریافت قطعی برای همه افراد را فرض نگیرید.