سوالات متداول اعلان‌های فشاری

چرا وقتی مرورگر بسته است، فشار کار نمی‌کند؟

این سوال تا حد زیادی مطرح می شود، عمدتاً به این دلیل که چند سناریو وجود دارد که استدلال و درک آن را دشوار می کند.

بیایید با اندروید شروع کنیم. سیستم عامل اندروید برای گوش دادن به پیام‌های فشار طراحی شده است و پس از دریافت آن، بدون در نظر گرفتن بسته بودن یا نبودن برنامه، برنامه اندروید مناسب را برای مدیریت پیام فشار بیدار کنید.

این دقیقاً در مورد هر مرورگر اندرویدی مشابه است، هنگامی که یک پیام فشار دریافت می‌شود، مرورگر بیدار می‌شود و مرورگر سرویس‌کار شما را بیدار می‌کند و رویداد فشار را ارسال می‌کند.

در سیستم‌عامل‌های دسکتاپ، تفاوت‌های ظریف‌تری دارد و توضیح آن در Mac OS X ساده‌تر است، زیرا یک نشانگر بصری برای کمک به توضیح سناریوهای مختلف وجود دارد.

در Mac OS X، با علامت گذاری زیر نماد برنامه در داک می توانید متوجه شوید که برنامه در حال اجرا است یا نه.

اگر دو نماد Chrome را در داک زیر مقایسه کنید، نماد سمت چپ در حال اجرا است، همانطور که با علامت گذاری زیر نماد نشان داده شده است، در حالی که Chrome در سمت راست اجرا نمی شود ، بنابراین علامت گذاری در زیر وجود ندارد.

نمونه ای از OS X

در زمینه دریافت پیام های فشار روی دسکتاپ، زمانی که مرورگر در حال اجرا است، پیام هایی دریافت خواهید کرد، یعنی علامت گذاری در زیر نماد وجود دارد.

این بدان معناست که مرورگر نمی‌تواند هیچ پنجره‌ای باز نداشته باشد، و شما همچنان پیام فشار را در سرویس‌کار خود دریافت خواهید کرد، زیرا مرورگر در پس‌زمینه در حال اجرا است.

تنها زمانی که یک فشار دریافت نمی شود زمانی است که مرورگر کاملاً بسته است، یعنی اصلاً کار نمی کند (بدون علامت گذاری). همین امر در مورد ویندوز نیز صدق می‌کند، اگرچه تعیین اینکه آیا کروم در پس‌زمینه اجرا می‌شود یا نه، کمی پیچیده‌تر است.

چگونه می توانم برنامه وب صفحه اصلی خود را با فشار تمام صفحه باز کنم؟

در Chrome for Android، یک برنامه وب را می توان به صفحه اصلی اضافه کرد و هنگامی که برنامه وب از صفحه اصلی باز می شود، می تواند در حالت تمام صفحه بدون نوار URL اجرا شود، همانطور که در زیر نشان داده شده است.

نماد صفحه اصلی به حالت تمام صفحه

برای ثابت نگه داشتن این تجربه، توسعه‌دهندگان می‌خواهند اعلان‌های کلیک‌شده آن‌ها برنامه وب آن‌ها را به صورت تمام صفحه نیز باز کند.

کروم "نوعی" این را اجرا کرده است، اگرچه ممکن است برای شما غیر قابل اعتماد و استدلال کردن با آن مشکل باشد. جزئیات اجرایی مربوطه عبارتند از:

این بدان معنی است که مگر اینکه کاربر شما به طور منظم از طریق نماد صفحه اصلی از سایت شما بازدید کند، اعلان های شما در رابط کاربری معمولی مرورگر باز می شوند.

روی این موضوع بیشتر کار خواهد شد.

چرا این بهتر از سوکت های وب است؟

هنگامی که پنجره مرورگر بسته است، می توان یک سرویس دهنده را زنده کرد. یک سوکت وب فقط تا زمانی زنده خواهد ماند که مرورگر و صفحه وب باز بماند.

معامله با GCM، FCM، Web Push و Chrome چیست؟

این سؤال جنبه‌های مختلفی دارد و ساده‌ترین راه برای توضیح آن، قدم گذاشتن در تاریخچه وب پوش و کروم است. (نگران نباشید، کوتاه است.)

دسامبر 2014

زمانی که کروم برای اولین بار فشار وب را اجرا کرد، کروم از Google Cloud Messaging (GCM) برای ارسال نیرو از سرور به مرورگر استفاده کرد.

این فشار وب نبود . چند دلیل وجود دارد که این راه‌اندازی اولیه کروم و GCM تحت وب «واقعی» نبود.

  • GCM از برنامه نویسان می خواهد که یک حساب کاربری در کنسول توسعه دهندگان گوگل راه اندازی کنند.
  • Chrome و GCM به شناسه فرستنده خاصی نیاز داشتند تا توسط یک برنامه وب به اشتراک گذاشته شود تا بتوانند پیام رسانی را به درستی تنظیم کنند.
  • سرورهای GCM یک درخواست API سفارشی را پذیرفتند که استاندارد وب نبود.

جولای 2016

در ماه ژوئیه، یک ویژگی جدید در وب فشار وارد شد - کلیدهای سرور برنامه (یا VAPID، همانطور که مشخصات شناخته شده است). وقتی کروم از این API جدید پشتیبانی کرد، از Firebase Cloud Messaging (همچنین به عنوان FCM شناخته می شود) به جای GCM به عنوان یک سرویس پیام رسانی استفاده کرد. این به چند دلیل مهم است:

  • Chrome و Application Sever Keys برای راه‌اندازی با Google یا Firebase نیازی به هیچ پروژه‌ای ندارند . این فقط کار خواهد کرد.
  • FCM از پروتکل فشار وب پشتیبانی می کند، که API است که همه سرویس های فشار وب از آن پشتیبانی می کنند. این بدان معنی است که صرف نظر از اینکه یک مرورگر از چه سرویس فشاری استفاده می کند، شما فقط همان نوع درخواست را ارسال می کنید و آن پیام را ارسال می کند.

چرا امروز گیج کننده است؟

اکنون که مطالبی با موضوع فشار وب نوشته شده است، سردرگمی زیادی وجود دارد که بیشتر آن به GCM یا FCM اشاره دارد. اگر محتوا به GCM ارجاع می‌دهد، احتمالاً باید آن را به‌عنوان نشانه‌ای تلقی کنید که یا محتوای قدیمی است یا تمرکز بیش از حد روی Chrome. (من مقصر این کار در تعدادی از پست های قدیمی هستم.)

در عوض، وب فشار را به عنوان متشکل از یک مرورگر در نظر بگیرید، که از یک سرویس فشار برای مدیریت ارسال و دریافت پیام ها استفاده می کند، جایی که سرویس فشار یک درخواست "پروتکل فشار وب" را می پذیرد. اگر به این شرایط فکر می کنید، می توانید نادیده بگیرید که از کدام مرورگر و کدام سرویس فشار استفاده می کند و دست به کار شوید.

این راهنما برای تمرکز بر رویکرد استانداردهای وب فشار نوشته شده است و به طور هدفمند هر چیز دیگری را نادیده می گیرد.

Firebase دارای JavaScript SDK است. چی و چرا؟

برای کسانی از شما که Firebase web SDK را پیدا کرده‌اند و متوجه شده‌اند که یک API پیام‌رسانی برای جاوا اسکریپت دارد، ممکن است تعجب کنید که تفاوت آن با web push چیست.

SDK پیام (معروف به Firebase Cloud Messaging JS SDK) چند ترفند در پشت صحنه انجام می دهد تا اجرای فشار وب را آسان تر کند.

  • به جای نگرانی در مورد PushSubscription و زمینه های مختلف آن، فقط باید نگران یک توکن FCM (رشته) باشید.
  • با استفاده از نشانه ها برای هر کاربر، می توانید از API اختصاصی FCM برای راه اندازی پیام های فشار استفاده کنید. این API نیازی به رمزگذاری محموله‌ها ندارد. شما می توانید یک بار متن ساده را در یک بدنه درخواست POST ارسال کنید.
  • API اختصاصی FCM از ویژگی‌های سفارشی پشتیبانی می‌کند، به عنوان مثال FCM Topics (این برنامه در وب نیز کار می‌کند، اگرچه مستندات ضعیفی دارد).
  • در نهایت، FCM از اندروید، iOS و وب پشتیبانی می‌کند، بنابراین برای برخی تیم‌ها کار کردن در پروژه‌های موجود آسان‌تر است.

این از فشار وب در پشت صحنه استفاده می کند، اما هدف آن انتزاع آن است.

همانطور که در سوال قبلی گفتم، اگر وب پوش را فقط یک مرورگر و یک سرویس فشار در نظر بگیرید، می توانید SDK پیام رسانی در Firebase را به عنوان یک کتابخانه برای ساده سازی اجرای وب فشار در نظر بگیرید.

بعد کجا بریم

آزمایشگاه های کد