אפליקציית Progressive Web App הראשונה שלך

עדכון אחרון: 2019-04-30

מה הופך אפליקציית אינטרנט ל-Progressive Web App?

Progressive Web Apps מספקות חוויה דמוית אפליקציה שניתן להתקין, במחשב ובנייד, שנבנתה והועברה ישירות דרך האינטרנט. הן אפליקציות אינטרנט מהירות ומהימנות. והכי חשוב, הן אפליקציות אינטרנט שפועלות בכל דפדפן. אם אתם בונים היום אפליקציית אינטרנט, אתם כבר נמצאים בדרך לבניית Progressive Web App.

מהיר &אמין; אמין

כל חוויית אינטרנט חייבת להיות מהירה, ועובדה זו נכונה במיוחד לגבי אפליקציות מסוג Progressive Web App. המשמעות של ' בזריזות' היא הזמן שלוקח להציג תוכן משמעותי במסך ולספק חוויה אינטראקטיבית.

בנוסף, היא חייבת להיות מהירה ומהימנה. קשה להכביד על מידת הביצועים המהימנים יותר. כדאי לחשוב על זה כך: הטעינה הראשונה של אפליקציה מקורית היא מתסכלת. היא מוגבלת על ידי חנות אפליקציות והורדה ענקית, אבל כשתגיעו לשלב שבו מתקינים את האפליקציה, העלות ההתחלתית הזו מהופחת בכל הפעלות האפליקציה, ואחריה לא משתנה עיכוב. כל התחלה של אפליקציה היא מהירה כמו האחרונה, ללא שונות. אפליקציית Progressive Web App צריכה לספק ביצועים אמינים שהמשתמשים מצפים לקבל מכל חוויה מותקנת.

התקנה

אפליקציות Progressive Web App יכולות לפעול בכרטיסייה 'דפדפן', אבל ניתן להתקין אותן גם. הוספת סימנייה לאתר רק מוסיפה קיצור דרך, אבל Progressive Web App (PWA) מותקנת ופועלת כמו כל האפליקציות המותקנות. הוא יופעל מאותו מקום שבו מופעלות אפליקציות אחרות. ניתן לשלוט בחוויית ההפעלה, כולל מסך פתיחה בהתאמה אישית, סמלים ועוד. הוא פועל כאפליקציה, בחלון אפליקציה ללא סרגל כתובות או ממשק משתמש אחר של דפדפן. בדומה לכל שאר האפליקציות המותקנות, זוהי אפליקציה ברמה העליונה במעבר בין המשימות.

חשוב לזכור שחובה להשתמש במכשיר PWA מהיר ואמין. משתמשים שהתקינו את PWA מצפים שהאפליקציות שלהם יפעלו, בלי קשר לסוג החיבור שלהם לאינטרנט. זוהי ציפייה לבסיס שכל אפליקציה מותקנת חייבת לעמוד בה.

Mobile &מחשב

באמצעות טכניקות עיצוב רספונסיביות, אפשר להשתמש באפליקציות PWA גם במחשבים וגם במחשבים בנייד באמצעות בסיס קוד יחיד בין פלטפורמות. אם אתם שוקלים לכתוב אפליקציה מקורית, בדקו את היתרונות של PWA.

מה תיצור

בשיעור Lab זה, אתם בונים אפליקציית אינטרנט למזג אוויר באמצעות טכניקות PWA. האפליקציה שלך:

  • עליכם להשתמש בעיצוב רספונסיבי, כדי שהוא יפעל גם במחשבים וגם בניידים.
  • יש לפעול במהירות באמצעות קובץ שירות (service worker) כדי לשמור מראש את משאבי האפליקציה (HTML , CSS , JavaScript, תמונות) הנדרשים להפעלה ולשמירה של נתוני מזג האוויר בזמן הריצה כדי לשפר את הביצועים.
  • ניתן להתקנה, באמצעות מניפסט של אפליקציית אינטרנט והאירוע של beforeinstallprompt, כדי ליידע את המשתמש שניתן להתקין.

מה תלמדו

  • איך יוצרים ומוסיפים מניפסט של אפליקציית אינטרנט
  • כיצד לספק חוויה פשוטה במצב אופליין
  • כיצד לספק חוויה מלאה במצב אופליין
  • איך להתקין את האפליקציה

שיעור Lab זה מתמקד באפליקציות Progressive Web App. קונספטים ובלוקים של קוד שאינם רלוונטיים יותר מובלטים, והם ניתנים כדי פשוט להעתיק ולהדביק אותם.

מה צריך?

  • גרסה עדכנית של Chrome (גרסה 74 ואילך). אפשר להשתמש באפליקציות PWA בכל הדפדפנים, אבל נשתמש במספר תכונות של כלי הפיתוח של Chrome כדי להבין טוב יותר מה קורה ברמת הדפדפן ולהשתמש בהן כדי לבדוק את חוויית ההתקנה.
  • ידע ב-HTML, CSS, JavaScript וכלי פיתוח של Chrome.

קבלת מפתח ל-Dark Sky API

נתוני מזג האוויר מגיעים מ-Dark Sky API. כדי להשתמש בו, עליך לבקש מפתח API. זהו כלי קל לשימוש ובחינם, בחינם לפרויקטים לא מסחריים.

הרשמה למפתח API

מוודאים שמפתח ה-API פועל באופן תקין

כדי לבדוק שמפתח ה-API פועל כראוי, יש לשלוח בקשת HTTP אל DarkSky API. עליך לעדכן את כתובת ה-URL שלמטה כדי להחליף את DARKSKY_API_KEY במפתח ה-API שלך. אם הכול פועל, אמורה להופיע תחזית מזג האוויר העדכנית ביותר עבור העיר ניו יורק.

https://api.darksky.net/forecast/DARKSKY_API_KEY/40.7720232,-73.9732319

מקבלים את הקוד

העברנו את כל מה שצריך לפרויקט הזה אל מאגר Git. כדי להתחיל, עליך לקחת את הקוד ולפתוח אותו בסביבת הפיתוח המועדפת עליך. ב-Codelab הזה מומלץ להשתמש ב-Glitch.

מומלץ מאוד: משתמשים ב-Glitch כדי לייבא את חנות ה-Repo

השימוש ב-Glitch הוא השיטה המומלצת לעבודה באמצעות מעבדת קוד זו.

  1. פותחים כרטיסייה חדשה בדפדפן ועוברים אל הכתובת https://glitch.com.
  2. אם אין לך חשבון, עליך להירשם.
  3. לוחצים על פרויקט חדש ואז על שכפול מ-Git Repo.
  4. שכפול https://github.com/googlecodelabs/your-first-pwapp.git ולוחצים על 'אישור'.
  5. לאחר טעינת ה-Repo, יש לערוך את הקובץ .env ולעדכן אותו עם המפתח DarkSky API.
  6. לוחצים על הלחצן הצגה ובוחרים באפשרות בחלון חדש כדי לראות את ה-PWA בפעולה.

חלופה: הורדת הקוד & עבודה מקומי

אם אתם רוצים להוריד את הקוד ולעבוד באופן מקומי, עליכם להתקין גרסה עדכנית של Node.js ולהגדיר את עורך הקוד באופן מוכן.

להורדת קוד המקור

  1. פותחים את הקובץ הדחוס.
  2. מריצים את npm install כדי להתקין את התלות הנדרשות כדי להפעיל את השרת.
  3. עליך לערוך את server.js ולהגדיר את מפתח ה-API של DarkSky.
  4. יש להריץ את node server.js כדי להפעיל את השרת ביציאה 8000.
  5. פותחים כרטיסיית דפדפן לכתובת http://localhost:8000

מהי נקודת ההתחלה שלנו?

נקודת ההתחלה שלנו היא אפליקציית מזג אוויר בסיסית המיועדת למעבדת קוד זו. הקוד פשוט יותר כדי להציג את הקונספטים במעבד הקוד הזה, והוא קודש מעט שגיאות. אם תבחרו לעשות שימוש חוזר בקוד זה באפליקציית ייצור, ודאו שתטפלו בשגיאות ותבדקו באופן מלא את כל הקוד.

יש כמה דברים שאפשר לנסות...

  1. מוסיפים עיר חדשה עם לחצן ה-+ הכחול בפינה השמאלית התחתונה.
  2. מרעננים את הנתונים באמצעות לחצן הרענון שבפינה השמאלית העליונה.
  3. מוחקים עיר באמצעות x בפינה השמאלית העליונה של כל כרטיס עיר.
  4. בעזרת סרגל הכלים של המכשיר להחלפת המצב של כלי הפיתוח של Chrome, תוכלו לראות איך זה עובד במחשב ובנייד.
  5. השתמשו בחלונית רשת בכלי הפיתוח של Chrome כדי לבדוק מה קורה במצב אופליין.
  6. באמצעות החלונית Network בכלי הפיתוח ל-Chrome, ניתן לראות מה קורה כשהויסות של הרשת מווסתת ל-3G האיטי.
  7. יש להוסיף עיכוב לשרת התחזית על ידי שינוי הערך של FORECAST_DELAY ב-server.js

ביקורת באמצעות Lighthouse

Lighthouse הוא כלי קל לשימוש שעוזר לשפר את האיכות של האתרים והדפים שלכם. ב-Lighthouse מבצעים ביקורות לגבי ביצועים, נגישות, אפליקציות מסוג Progressive Web App ועוד. לכל ביקורת יש מסמך עזר שמסביר למה הביקורת חשובה ואיך לפתור בעיות.

אנחנו נשתמש ב-Lighthouse כדי לבדוק את אפליקציית מזג האוויר ולאמת את השינויים שביצענו.

הפעלה של Lighthouse

  1. פותחים את הפרויקט בכרטיסייה חדשה.
  2. פותחים את כלי הפיתוח של Chrome ועוברים לחלונית ביקורות. כל סוגי הביקורת מופעלים.
  3. לוחצים על הפעלת ביקורות. לאחר מכן, תקבלו מ-Lighthouse דוח בדף.

הביקורת של Progressive Web App

אנחנו מתמקדים בתוצאות של הביקורת על Progressive Web App.

ויש הרבה אדום כדי להתמקד:

  • ❗FAILED: הדף הנוכחי לא מגיב בסטטוס 200 כשהוא במצב אופליין.
  • ❗FAILED: start_url אינו מגיב בסטטוס 200 כשהוא במצב אופליין.
  • ❗FAILED: אין רישום של קובץ שירות (service worker) ששולט בדף וב-start_url.
  • ❗FAILED: מניפסט של אפליקציית אינטרנט אינו עומד בדרישות ההתקנה.
  • ❗FAILED: אינו מוגדר עבור מסך פתיחה מותאם אישית.
  • ❗FAILED: אינו מגדיר את צבע העיצוב של סרגל הכתובות.

הגיע הזמן להתחיל לתקן חלק מהבעיות האלה!

עד סוף הקטע הזה, אפליקציית מזג האוויר תעבור את הביקורות הבאות:

  • קובץ המניפסט של אפליקציית האינטרנט אינו עומד בדרישות ההתקנה.
  • לא מוגדר עבור מסך פתיחה מותאם אישית.
  • לא מוגדר צבע עיצוב של סרגל הכתובות.

יצירת מניפסט של אפליקציית אינטרנט

מניפסט של אפליקציית אינטרנט הוא קובץ JSON פשוט שנותן לכם, למפתח, שליטה באופן שבו האפליקציה מוצגת למשתמש.

באמצעות המניפסט של אפליקציית האינטרנט, אפליקציית האינטרנט יכולה:

  • אומרים לדפדפן שרוצים שהאפליקציה תפתח בחלון עצמאי (display).
  • הגדרת הדף שנפתח עם השקת האפליקציה (start_url).
  • עליך להגדיר איך האפליקציה תופיע באביזר העגינה או במפעיל האפליקציות (short_name, icons).
  • יצירת מסך פתיחה (name, icons, colors).
  • מבקשים מהדפדפן לפתוח את החלון בפריסה לרוחב או במצב תצוגה לאורך (orientation).
  • ועוד שפע.

יש ליצור קובץ בשם public/manifest.json בפרויקט. מעתיקים את התוכן הבא ומדביקים אותו:

public/manifest.json

{
  "name": "Weather",
  "short_name": "Weather",
  "icons": [{
    "src": "/images/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-256x256.png",
      "sizes": "256x256",
      "type": "image/png"
    }, {
      "src": "/images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }],
  "start_url": "/index.html",
  "display": "standalone",
  "background_color": "#3E4EB8",
  "theme_color": "#2F3BA2"
}

המניפסט תומך במגוון של סמלים המיועדים לגודלי מסך שונים. ב-Codelab הזה, כללנו כמה אפליקציות אחרות לשילוב iOS.

בשלב הבא, אנחנו צריכים לדווח לדפדפן על המניפסט שלנו על ידי הוספת <link rel="manifest"... לכל דף באפליקציה. יש להוסיף את השורה הבאה לרכיב <head> בקובץ index.html.

public/index.html

<!-- CODELAB: Add link rel manifest -->
<link rel="manifest" href="/manifest.json">

עקיפה של כלי הפיתוח

כלי הפיתוח מספקים דרך מהירה וקלה לבדוק את קובץ ה-manifest.json שלך. פותחים את החלונית מניפסט בחלונית אפליקציה. אם הוספת את פרטי המניפסט בצורה נכונה, תוכל לנתח אותם ולהציג אותם בפורמט ידידותי לבני אדם בחלונית זו.

הוספת מטא תגים מסוג &amp ל-iOS

Safari ב-iOS אינו תומך במניפסט של אפליקציית האינטרנט (עדיין), לכן עליך להוסיף את התגים הרגילים של meta ל-<head> של קובץ index.html:

public/index.html

<!-- CODELAB: Add iOS meta tags and icons -->
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black">
<meta name="apple-mobile-web-app-title" content="Weather PWA">
<link rel="apple-touch-icon" href="/images/icons/icon-152x152.png">

בונוס: תיקונים פשוטים ב-Lighthouse

בביקורת שלנו ב-Lighthouse היו כמה דברים ש די קל לתקן, בואו נטפל בהם בזמן שאנחנו כאן.

הגדרת תיאור מטא

בבדיקה של אופטימיזציה למנועי חיפוש, ב-Lighthouse ציינו את הפרמטר "למסמך אין תיאור מטא." תיאורים יכולים להופיע בתוצאות החיפוש ב-Google. תיאורים איכותיים וייחודיים יכולים להפוך את התוצאות לרלוונטיות יותר למשתמשים בחיפוש ולהגדיל את תנועת החיפוש.

כדי להוסיף תיאור, יש להוסיף את התג meta הבא ל-<head> במסמך:

public/index.html

<!-- CODELAB: Add description here -->
<meta name="description" content="A sample weather app">

הגדרת צבע העיצוב של סרגל הכתובות

בביקורת של PWA, ב-Lighthouse ציינו את האפליקציה שלנו &&quotלא מגדירה צבע עיצוב בסרגל הכתובות". בחירת סרגל הכתובות של הדפדפן כך שתתאים לצבעי המותג שלך תאפשר לך לספק חוויית משתמש סוחפת יותר.

כדי להגדיר את צבע העיצוב לנייד, יש להוסיף את התג הבא (meta) למסמך <head>:

public/index.html

<!-- CODELAB: Add meta theme-color -->
<meta name="theme-color" content="#2F3BA2" />

אימות שינויים באמצעות Lighthouse

מפעילים שוב את Lighthouse (על ידי לחיצה על הסימן + בפינה הימנית העליונה של חלונית הביקורות) ומאמתים את השינויים.

ביקורת על אופטימיזציה למנועי חיפוש

  • 👋 עבר: למסמך יש תיאור מטא.

ביקורת של Progressive Web App

  • ❗FAILED: הדף הנוכחי לא מגיב בסטטוס 200 כשהוא במצב אופליין.
  • ❗FAILED: start_url אינו מגיב בסטטוס 200 כשהוא במצב אופליין.
  • ❗FAILED: אין רישום של קובץ שירות (service worker) ששולט בדף וב-start_url.
  • עבר בהצלחה: מניפסט אפליקציית האינטרנט עומד בדרישות ההתקנה.
  • עבר בהצלחה: מוגדר למסך פתיחה מותאם אישית.
  • הרצת לעבור: הגדרת צבע עיצוב בסרגל הכתובות.

יש ציפייה ממשתמשים שהתקינו אפליקציות תמיד ליהנות מחוויה בסיסית אם הם במצב אופליין. לכן חשוב מאוד שאפליקציות אינטרנט שניתן להתקין אף פעם לא יציגו את משחק הדינוזאורים במצב אופליין של Chrome. החוויה במצב אופליין יכולה לנוע בין דף פשוט במצב אופליין, לחוויית קריאה בלבד עם נתונים שנשמרו בעבר במטמון, ועד חוויה לא מקוונת שעובדת באופן מלא ומסתנכרנת באופן אוטומטי כאשר החיבור לרשת משוחזר.

בקטע הזה נוסיף דף פשוט במצב אופליין לאפליקציית מזג האוויר שלנו. אם המשתמש ינסה לטעון את האפליקציה במצב אופליין, הוא יציג את הדף המותאם אישית שלנו במקום את הדף הלא מקוון הרגיל שמוצג בדפדפן. עד סוף הקטע הזה, אפליקציית מזג האוויר תעבור את הביקורות הבאות:

  • דף זה לא מגיב בסטטוס 200 כשהוא במצב אופליין.
  • start_url לא מגיב בסטטוס 200 כשהוא במצב אופליין.
  • לא רושם קובץ שירות (service worker) ששולט בדף וב-start_url.

בקטע הבא, נחליף את הדף הלא מקוון המותאם אישית שלנו לחוויה מלאה במצב אופליין. המידע הזה ישפר את החוויה אופליין, אבל חשוב מכך: הוא ישפר באופן משמעותי את הביצועים שלנו, מפני שרוב הנכסים שלנו (HTML , CSS ו-JavaScript) יאוחסנו ולא יוצגו באופן מקומי, וכך נמנע מצב של צוואר בקבוק.

עזרה בתהליך העבודה

אם אינכם מכירים את קובצי השירות (service worker), תוכלו לקבל הבנה בסיסית לגבי הפעולות שהם יכולים לבצע, מחזור החיים שלהם ועוד. לשם כך, קראו את המאמר מבוא לעובדי השירות.

תכונות המסופקות באמצעות קובצי שירות (service worker) צריכות להיחשב כשיפור מתקדם, ולהוסיף אותן רק אם הן נתמכות על ידי הדפדפן. לדוגמה, באמצעות קובצי שירות (service worker), אפשר לשמור את מעטפת האפליקציה ונתונים של האפליקציה במטמון, כדי שיהיו זמינים גם כשהרשת זמינה. כשה-worker לא נתמך, הקוד לא מחובר לאינטרנט והמשתמש לא מקבל חוויית שימוש בסיסית. השימוש בזיהוי תכונות לצורך שיפור מתקדם הוא עם תקורה נמוכה, והוא לא מתנתק בדפדפנים ישנים שלא תומכים בתכונה זו.

רישום קובץ השירות (service worker)

השלב הראשון הוא לרשום את קובץ השירות (service worker). יש להוסיף את הקוד הבא לקובץ index.html שלך:

public/index.html

// CODELAB: Register service worker.
if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/service-worker.js')
        .then((reg) => {
          console.log('Service worker registered.', reg);
        });
  });
}

קוד זה בודק אם ממשק ה-API של קובץ השירות (service worker) זמין, ואם כן, קובץ השירות (service worker) ב-/service-worker.js רשום לאחר שהדף נטען.

חשוב לשים לב שה-worker של השירות מוצג מספריית הבסיס (root) ולא מספריית /scripts/. זו הדרך הקלה ביותר להגדיר את scope של קובץ השירות (service worker). ה-scope של קובץ השירות (service worker) קובע באילו קבצים (service worker) שולט ה-Service worker, ובאיזה נתיב יעבד קובץ השירות (service worker). ברירת המחדל scope היא המיקום של קובץ ה-service worker, והוא חל על כל הספריות שבהמשך. לכן, אם הדומיין service-worker.js נמצא בספריית הבסיס, ה-service worker יקבע בקשות מכל דפי האינטרנט בדומיין הזה.

דף אופליין לשמירה במטמון

תחילה, עלינו להגיד ל-service worker מה למטמון. כבר יצרנו דף לא מקוון פשוט (public/offline.html) שאותו נציג בכל פעם שאין חיבור לרשת.

ב-service-worker.js, מוסיפים את '/offline.html', למערך FILES_TO_CACHE, והתוצאה הסופית צריכה להיראות כך:

public/service-worker.js

// CODELAB: Add list of files to cache here.
const FILES_TO_CACHE = [
  '/offline.html',
];

בשלב הבא, עלינו להוסיף את הקוד הבא לאירוע install כדי ליידע את קובץ השירות (service worker) לשמירה מראש של הדף הלא מקוון:

public/service-worker.js

// CODELAB: Precache static resources here.
evt.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      console.log('[ServiceWorker] Pre-caching offline page');
      return cache.addAll(FILES_TO_CACHE);
    })
);

אירוע install שלנו פותח עכשיו את המטמון עם caches.open() ומספק שם למטמון. כשנותנים שם מטמון אפשר לתרגם קבצים או להפריד נתונים מהמשאבים השמורים במטמון כדי שנוכל לעדכן בקלות אחד מהשניים אבל לא להשפיע על השני.

כשהמטמון פתוח, אנחנו יכולים לקרוא ל-cache.addAll(), שלוקח רשימה של כתובות URL ומאחזר אותן מהשרת ומוסיף את התגובה למטמון. הערה: cache.addAll() נכשל באחת מהבקשות הנפרדות. כלומר, אתם מבטיחים שאם שלב ההתקנה יסתיים בהצלחה, המטמון שלכם יהיה במצב עקבי. אבל אם הוא נכשל מסיבה כלשהי, הוא ינסה שוב באופן אוטומטי בפעם הבאה ש-service worker יופעל.

עקיפה של כלי הפיתוח

בואו נראה איך אפשר להשתמש בכלי הפיתוח כדי להבין את קובצי השירות (service worker) לניפוי באגים. לפני טעינה מחדש של הדף, יש לפתוח את כלי הפיתוח ולעבור לחלונית Service Workers בחלונית האפליקציה. הוא אמור להיראות כך:

אם מופיע דף ריק כזה, פירוש הדבר הוא שבדף הפתוח הנוכחי אין קובצי שירות רשומים.

עכשיו, טוענים מחדש את הדף. עכשיו חלונית השירות (service worker) אמורה להיראות כך:

אם מופיע מידע כזה, המשמעות היא שבדף פועל קובץ שירות (service worker).

לצד תווית הסטטוס, יש מספר (34251 במקרה הזה). שימו לב למספר הזה בזמן שאתם עובדים עם קובצי שירות (service worker). זוהי דרך קלה לדעת אם קובץ השירות (service worker) עודכן.

ניקוי דפים ישנים במצב אופליין

נשתמש באירוע activate כדי לנקות נתונים ישנים במטמון שלנו. הקוד הזה מבטיח ש-worker יעדכן את המטמון שלו בכל שינוי של קובצי מעטפת של אפליקציה. כדי לעשות זאת, צריך להוסיף את המשתנה CACHE_NAME בחלק העליון של קובץ ה-worker (service worker).

צריך להוסיף את הקוד הבא לאירוע activate:

public/service-worker.js

// CODELAB: Remove previous cached data from disk.
evt.waitUntil(
    caches.keys().then((keyList) => {
      return Promise.all(keyList.map((key) => {
        if (key !== CACHE_NAME) {
          console.log('[ServiceWorker] Removing old cache', key);
          return caches.delete(key);
        }
      }));
    })
);

עקיפה של כלי הפיתוח

כשחלונית קובצי השירות (service worker) פתוחה, מרעננים את הדף. קובץ ה-service worker החדש יופיע ומספר הסטטוס יגדל.

קובץ השירות (service worker) המעודכן שולט באופן מיידי כי האירוע install שלנו מסתיים עם self.skipWaiting(), והאירוע activate מסתיים בשעה self.clients.claim(). בלעדיו, קובץ השירות הישן ימשיך לשלוט בדף כל עוד יש כרטיסייה פתוחה בדף.

טיפול בבקשות רשת שנכשלו

לבסוף, עלינו לטפל באירועי fetch. נתבסס על אסטרטגיה של חזרה לרשת למטמון. קובץ השירות (service worker) מנסה תחילה לאחזר את המשאב מהרשת. אם זה לא מצליח, קובץ השירות (service worker) מחזיר את הדף הלא מקוון מהמטמון.

public/service-worker.js

// CODELAB: Add fetch event handler here.
if (evt.request.mode !== 'navigate') {
  // Not a page navigation, bail.
  return;
}
evt.respondWith(
    fetch(evt.request)
        .catch(() => {
          return caches.open(CACHE_NAME)
              .then((cache) => {
                return cache.match('offline.html');
              });
        })
);

ה-handler של fetch צריך לטפל רק בניווטים לדפים, כך שבקשות אחרות יכולות להשליך מה-handler ולטפל בהן כרגיל באמצעות הדפדפן. לעומת זאת, אם הבקשה .mode היא navigate, צריך להשתמש ב-fetch כדי לקבל את הפריט מהרשת. אם הסריקה תיכשל, ה-handler של catch ייפתח את המטמון ב-caches.open(CACHE_NAME) וייעשה שימוש ב-cache.match('offline.html') כדי להוריד את הדף השמור מראש במצב אופליין. לאחר מכן התוצאה מועברת לדפדפן באמצעות evt.respondWith().

עקיפה של כלי הפיתוח

בואו לוודא שהכול פועל כמו שצריך. כשחלונית Service Workers פתוחה, מרעננים את הדף. קובץ ה-service worker החדש יופיע ומספר הסטטוס יגדל.

אנחנו יכולים גם לבדוק מה נשמר במטמון. בחלונית אחסון מטמון בחלונית אפליקציה של כלי הפיתוח. לוחצים לחיצה ימנית על אחסון מטמון, בוחרים באפשרות רענון מטמון ומרחיבים את הקטע. השם של המטמון הסטטי אמור להופיע בצד ימין. כדי לראות את כל הקבצים שנשמרו במטמון, לוחצים על שם המטמון.

עכשיו ננסה את המצב אופליין. חוזרים לחלונית Service Workers בחלונית Application של כלי הפיתוח ומסמנים את התיבה Offline. לאחר הבדיקה, אתה אמור לראות סמל אזהרה קטן צהוב לצד הכרטיסייה 'רשת' רשת. הסמל הזה מציין שאין חיבור לאינטרנט.

טען מחדש את הדף ו... זה עובד! אנחנו מקבלים הפנדה שלנו במצב אופליין, במקום הדינו אופליין של Chrome!

טיפים לבדיקת קובצי שירות (service worker)

ניפוי באגים ב-service worker יכול להיות אתגר, ואם הוא כולל שמירה במטמון, הדברים יכולים להיות עוד יותר מסובכים אם המטמון לא יתעדכן כפי שציפיתם. בין מחזור החיים הרגיל של קובץ השירות (service worker) לבאג בקוד, ייתכן שתסכל אתכם במהירות. אבל לא.

שימוש בכלי הפיתוח

בחלונית Service Workers בחלונית Application יש מספר תיבות סימון שיעזרו לכם להקל על החיים.

  • אופליין – כשהאפשרות הזו מסומנת, היא מדמה חוויה אופליין ומונעת מכל הבקשות לעבור לרשת.
  • עדכון בזמן טעינה מחדש – כשהאפשרות הזו מסומנת, תקבלו את קובץ השירות (service worker) האחרון, שתתקינו אותו ותפעיל אותו מיד.
  • עקיפה של רשת - כשהאפשרות הזו מסומנת, הבקשות יעקפו את קובץ השירות (service worker) ונשלחות ישירות לרשת.

התחלה מחדש

במקרים מסוימים, ייתכן שתגלו שאתם טוענים נתונים שנשמרו במטמון או שדברים לא מתעדכנים כפי שציפיתם. כדי לנקות את כל הנתונים השמורים (localStorage, dataDB, קבצים שנשמרו במטמון) ולהסיר את כל קובצי השירות (service worker), לוחצים על Clear Storage בחלונית Application. לחלופין, אפשר לעבוד גם בחלון אנונימי.

טיפים נוספים:

  • לאחר ביטול הרישום של קובץ שירות (service worker), ייתכן שהוא יישאר רשום עד שחלון הדפדפן המכיל שלו ייסגר.
  • אם פתוחים מספר חלונות לאפליקציה שלכם, קובץ שירות (service worker) חדש לא ייכנס לתוקף עד שכל החלונות ייטענו מחדש ויעודכנו ל-worker האחרון.
  • ביטול הרישום של קובץ שירות (service worker) לא מנקה את המטמון!
  • אם קיים קובץ שירות (service worker) ו-service worker חדש רשום, ה-Service Worker החדש לא יקבל שליטה עד שהדף ייטען מחדש, אלא אם תבוצע שליטה מיידית.

אימות שינויים באמצעות Lighthouse

מפעילים שוב את Lighthouse ומאמתים את השינויים. אל תשכחו לבטל את סימון התיבה של 'לא מקוון' לפני שתאמתו את השינויים שלכם!

ביקורת על אופטימיזציה למנועי חיפוש

  • 👋 עבר: למסמך יש תיאור מטא.

ביקורת של Progressive Web App

  • אישור עבר: הדף הנוכחי מגיב בסטטוס 200 כשהוא במצב אופליין.
  • עבר בהצלחה: start_url מגיב בסטטוס 200 כשהוא במצב אופליין.
  • שובר עבר: רישום של קובץ שירות (service worker) ששולט בדף וב-start_url.
  • עבר בהצלחה: מניפסט אפליקציית האינטרנט עומד בדרישות ההתקנה.
  • עבר בהצלחה: מוגדר למסך פתיחה מותאם אישית.
  • הרצת לעבור: הגדרת צבע עיצוב בסרגל הכתובות.

כדאי להקדיש כמה רגעים כדי להעביר את הטלפון למצב טיסה, ואז לנסות להפעיל כמה מהאפליקציות האהובות עליך. כמעט בכל המקרים, הם מספקים חוויה יציבה למדי במצב אופליין. המשתמשים מצפים שחוויית השימוש באפליקציות שלהם תהיה חזקה. והאינטרנט לא אמור להיות שונה. סביבת Progressive Web App צריכה להיות מוגדרת כתרחיש ליבה.

מחזור חיים של קובץ שירות (service worker)

מחזור החיים של קובץ השירות (service worker) הוא החלק המורכב ביותר. אם לא ידוע לך מה זה מנסה לעשות ומהם היתרונות, אפשר להרגיש כאילו זה נלחם בך. אבל כשיודעים איך זה עובד, אפשר לשלוח למשתמשים עדכונים בצורה חלקה ולא פולשנית, תוך שילוב של המיטב באינטרנט ותבניות מקוריות.

install אירוע

האירוע הראשון שמקבל קובץ השירות (service worker) הוא install. היא מופעלת מיד לאחר שה-worker מופעל, והיא מתבצעת פעם אחת בלבד לכל קובץ שירות (service worker). אם תשנו את הסקריפט של קובץ השירות (service worker), הדפדפן יתייחס אליו כ-service worker אחר ויקבל install אירוע משלו.

בדרך כלל האירוע install משמש לשמירה במטמון של כל מה שדרוש לאפליקציה כדי לפעול.

activate אירוע

קובץ השירות (service worker) יקבל אירוע activate בכל פעם שהוא יופעל. המטרה העיקרית של האירוע activate היא להגדיר את אופן הפעולה של קובץ השירות (service worker)&לנקות, לנקות את כל המשאבים שנותרו מההפעלות הקודמות (למשל, מטמון ישן), ולהכין את ה-service worker לטיפול בבקשות רשת (לדוגמה, אירוע fetch שבהמשך).

fetch אירוע

אירוע האחזור מאפשר ל-service worker לעכב בקשות ברשת ולטפל בבקשות. היא יכולה לעבור לרשת כדי לקבל את המשאב, היא יכולה לשלוף אותה מהמטמון שלה, ליצור תגובה מותאמת אישית או כל מספר של אפשרויות שונות. באוסף הפתרונות אופליין תוכלו לקרוא אסטרטגיות שונות שבהן תוכלו להשתמש.

עדכון קובץ שירות (service worker)

הדפדפן בודק אם יש גרסה חדשה של קובץ השירות (service worker) בכל טעינה של דף. אם המערכת מזהה גרסה חדשה, היא מורידה ומתקינים ברקע, אבל היא לא מופעלת. הגרסה החדשה של קובץ השירות (service worker) נמצאת במצב המתנה, עד שלא ייפתחו עוד דפים שמשתמשים ב-worker הישן. לאחר סגירת כל החלונות של קובץ השירות (service worker) החדש, קובץ השירות (service worker) החדש יופעל ויקבל שליטה. פרטים נוספים מופיעים בקטע עדכון קובץ השירות (service worker) במסמך מחזור החיים של קובץ השירות (service worker).

בחירת האסטרטגיה המתאימה לשמירה במטמון

בחירת אסטרטגיית השמירה במטמון תלויה בסוג המשאב שאתם מנסים לשמור במטמון, וייתכן שתצטרכו לגשת אליו מאוחר יותר. באפליקציית מזג האוויר, אנחנו נפצל את המשאבים שאנחנו צריכים לשמור במטמון לשתי קטגוריות: משאבים שאנחנו רוצים לשמור במטמון מראש והנתונים שאנחנו נשמור במטמון בזמן ריצה.

שמירת משאבים סטטיים

העברת המשאבים היא קונספט דומה לזה שמתרחש כשמשתמש מתקין אפליקציה במחשב או בנייד. המשאבים החשובים ביותר כדי שהאפליקציה תפעל או יישמרו במטמון של המכשיר כדי שניתן יהיה לטעון אותם מאוחר יותר, בין אם יש חיבור לרשת או לא.

עבור האפליקציה שלנו, אנחנו נשמור מראש את כל המשאבים הסטטיים שלנו כאשר קובץ השירות (service worker) מותקן, כדי שכל מה שצריך כדי להפעיל את האפליקציה מאוחסן במכשיר של המשתמש. כדי להבטיח שהאפליקציה שלנו תיטען במהירות הבזק, אנחנו נשתמש בשיטה ראשית, במקום לעבור לרשת כדי לקבל את המשאבים, הם נשלפו מהמטמון המקומי. רק אם הם לא זמינים שם, ננסה להשיג אותם מהרשת.

שליפה מהמטמון המקומי מבטלת את השונות ברשת. לא משנה מה סוג הרשת של המשתמש (Wi-Fi, 5G, 3G, או אפילו 2G), המשאבים העיקריים שאנחנו צריכים לניהול יהיו זמינים כמעט מיד.

שמירה של נתוני האפליקציה במטמון

השיטה אימות בזמן אימות היא אידיאלית לסוגים מסוימים של נתונים והיא פועלת היטב עבור האפליקציה שלנו. היא מקבלת נתונים על המסך במהירות האפשרית, ומעודכנת ברגע שהרשת מחזירה את הנתונים העדכניים ביותר. תהליך האימות בזמן אמת אינו מאפשר לנו לשלוח שתי בקשות אסינכרוניות, אחת לשמירה במטמון ואחת לרשת.

בנסיבות רגילות, הנתונים המאוחסנים במטמון יוחזרו באופן כמעט מיידי ויספקו לאפליקציה את הנתונים האחרונים שבהם היא יכולה להשתמש. לאחר מכן, כשבקשת הרשת תחזור, האפליקציה תעודכן באמצעות הנתונים האחרונים מהרשת.

באפליקציה שלנו, החוויה הזו טובה יותר מהרשת, וחוזרת לאסטרטגיית המטמון כי המשתמש לא צריך לחכות עד שיפוג הזמן הקצוב לבקשת הרשת כדי לראות משהו במסך. ייתכן שבהתחלה יוצגו נתונים ישנים יותר, אבל כשבקשת הרשת תוחזר, האפליקציה תתעדכן בנתונים העדכניים ביותר.

עדכון הלוגיקה של האפליקציה

כפי שצוין קודם לכן, האפליקציה צריכה להפעיל שתי בקשות אסינכרוניות, אחת למטמון ואחת לרשת. האפליקציה משתמשת באובייקט caches הזמין ב-window כדי לגשת למטמון ולאחזר את הנתונים העדכניים. זוהי דוגמה מצוינת לשיפור הדרגתי, מכיוון שהאובייקט caches עשוי להיות לא זמין בכל הדפדפנים, ואם הוא לא פועל, בקשת הרשת עדיין אמורה לפעול.

יש לעדכן את הפונקציה getForecastFromCache() כדי לבדוק אם האובייקט caches זמין באובייקט window הגלובלי, ואם הוא זמין, לבקש את הנתונים מהמטמון.

public/scripts/app.js

// CODELAB: Add code to get weather forecast from the caches object.
if (!('caches' in window)) {
  return null;
}
const url = `${window.location.origin}/forecast/${coords}`;
return caches.match(url)
    .then((response) => {
      if (response) {
        return response.json();
      }
      return null;
    })
    .catch((err) => {
      console.error('Error getting data from cache', err);
      return null;
    });

אז צריך לשנות את הערך של updateData() כך שיבוצע שתי שיחות, אחת ל-getForecastFromNetwork() כדי לקבל את התחזית מהרשת, ואחת ל-getForecastFromCache() כדי לקבל את התחזית העדכנית ביותר למטמון:

public/scripts/app.js

// CODELAB: Add code to call getForecastFromCache.
getForecastFromCache(location.geo)
    .then((forecast) => {
      renderForecast(card, forecast);
    });

אפליקציית מזג האוויר שלנו שולחת עכשיו שתי בקשות אסינכרוניות לנתונים, אחת מהמטמון ואחת באמצעות fetch. אם יש נתונים במטמון, הם יוחזרו ויעובדו במהירות רבה (באלפיות השנייה). לאחר מכן, כשהתגובה של fetch תתקבל, הכרטיס יתעדכן בנתונים העדכניים ביותר ישירות מ-API של מזג האוויר.

שימו לב איך הבקשה במטמון או הבקשה fetch מסתיימות בקריאה לעדכון כרטיס התחזית. איך האפליקציה יודעת אם היא מציגה את הנתונים העדכניים ביותר? מתבצע זאת בקוד הבא מ-renderForecast():

public/scripts/app.js

// If the data on the element is newer, skip the update.
if (lastUpdated >= data.currently.time) {
  return;
}

בכל פעם שכרטיס מתעדכן, האפליקציה שומרת את חותמת הזמן של הנתונים במאפיין מוסתר בכרטיס. האפליקציה פוטרת אם חותמת הזמן שכבר קיימת בכרטיס חדשה יותר מהנתונים שהועברו לפונקציה.

שמירה מראש של משאבי האפליקציות.

בקובץ השירות (service worker), יש להוסיף DATA_CACHE_NAME כדי שנוכל להפריד את נתוני האפליקציה מהמעטפת של האפליקציה. כשהמעטפת של האפליקציה מתעדכנת ומטמון ישן נמחק לצמיתות, הנתונים שלנו לא יאופסו, הם מוכנים לטעינה מהירה במיוחד. חשוב לזכור שאם פורמט הנתונים שלכם ישתנה בעתיד, תצטרכו דרך לטפל בזה ולוודא שמעטפת האפליקציה והתוכן יישארו מסונכרנים.

public/service-worker.js

// CODELAB: Update cache names any time any of the cached files change.
const CACHE_NAME = 'static-cache-v2';
const DATA_CACHE_NAME = 'data-cache-v1';

אל תשכחו לעדכן גם את CACHE_NAME; אנחנו נשנה גם את כל המשאבים הסטטיים שלנו.

כדי שהאפליקציה שלנו תפעל במצב אופליין, עלינו לשמור מראש את כל המשאבים הנחוצים לה. גם זה יעזור לביצועים שלנו. במקום לקבל את כל המשאבים מהרשת, האפליקציה תוכל לטעון את כל המשאבים מהמטמון המקומי, וכך למנוע חוסר יציבות ברשת.

עדכון מערך FILES_TO_CACHE בעזרת רשימת הקבצים:

public/service-worker.js

// CODELAB: Add list of files to cache here.
const FILES_TO_CACHE = [
  '/',
  '/index.html',
  '/scripts/app.js',
  '/scripts/install.js',
  '/scripts/luxon-1.11.4.js',
  '/styles/inline.css',
  '/images/add.svg',
  '/images/clear-day.svg',
  '/images/clear-night.svg',
  '/images/cloudy.svg',
  '/images/fog.svg',
  '/images/hail.svg',
  '/images/install.svg',
  '/images/partly-cloudy-day.svg',
  '/images/partly-cloudy-night.svg',
  '/images/rain.svg',
  '/images/refresh.svg',
  '/images/sleet.svg',
  '/images/snow.svg',
  '/images/thunderstorm.svg',
  '/images/tornado.svg',
  '/images/wind.svg',
];

אנחנו מייצרים באופן ידני את רשימת הקבצים לשמירה במטמון, ולכן בכל פעם שאנחנו מעדכנים קובץ צריך לעדכן את CACHE_NAME. הצלחנו להסיר את offline.html מרשימת הקבצים השמורים שלנו כי האפליקציה שלנו כוללת את כל המשאבים הדרושים כדי לעבוד במצב אופליין, והיא לא תציג שוב את הדף במצב אופליין.

עדכון הגורם המטפל באירועים

כדי לוודא שהאירוע activate לא ימחק בטעות את הנתונים שלנו, יש להחליף את if (key !== CACHE_NAME) { באירוע activate באירוע service-worker.js:

public/service-worker.js

if (key !== CACHE_NAME && key !== DATA_CACHE_NAME) {

עדכון הגורם המטפל באירועים של אחזור

עלינו לשנות את קובץ השירות (service worker) כדי ליירט בקשות ל-API של מזג אוויר ולאחסן את התשובות שלהן במטמון, כדי שנוכל לגשת אליהן בקלות מאוחר יותר. בשיטה הזו, בזמן האימות מחדש, אנחנו צופים שהתגובה לרשת תהיה 'מקור האמת'. המידע הזה תמיד יספק לנו את המידע העדכני ביותר. אם הרשת לא מצליחה להיכשל מפני שאנחנו כבר מאחזרים את הנתונים השמורים העדכניים ביותר באפליקציה שלנו.

יש לעדכן את handler האירוע fetch כדי לטפל בבקשות ל-API של הנתונים בנפרד מבקשות אחרות.

public/service-worker.js

// CODELAB: Add fetch event handler here.
if (evt.request.url.includes('/forecast/')) {
  console.log('[Service Worker] Fetch (data)', evt.request.url);
  evt.respondWith(
      caches.open(DATA_CACHE_NAME).then((cache) => {
        return fetch(evt.request)
            .then((response) => {
              // If the response was good, clone it and store it in the cache.
              if (response.status === 200) {
                cache.put(evt.request.url, response.clone());
              }
              return response;
            }).catch((err) => {
              // Network request failed, try to get it from the cache.
              return cache.match(evt.request);
            });
      }));
  return;
}
evt.respondWith(
    caches.open(CACHE_NAME).then((cache) => {
      return cache.match(evt.request)
          .then((response) => {
            return response || fetch(evt.request);
          });
    })
);

הקוד מיירט את הבקשה ובודק אם הוא כולל תחזית מזג אוויר. אם כן, יש להשתמש ב-fetch כדי לשלוח את הבקשה. לאחר שהתשובה מוחזרת, פותחים את המטמון, משכפלים את התגובה, מאחסנים אותה במטמון ומחזירים את התגובה למגיש הבקשה המקורי.

אנחנו צריכים להסיר את הבדיקה של evt.request.mode !== 'navigate' מפני שאנחנו רוצים שעובד השירות שלנו יטפל בכל הבקשות (כולל תמונות, סקריפטים, קובצי CSS וכו'), ולא רק בניווט. אם משאירים את הצ'ק-אין הזה, רק ה-HTML יוצג מהמטמון של קובץ השירות (service worker). כל השאר יבקש את הרשת.

רוצים לנסות?

האפליקציה אמורה להיות תקינה לחלוטין במצב אופליין. מרעננים את הדף כדי לוודא שהתקנתם את קובץ השירות (service worker) העדכני ביותר. לאחר מכן שומרים שתי ערים ולוחצים על לחצן הרענון באפליקציה כדי לקבל נתוני מזג אוויר עדכניים.

לאחר מכן עוברים לחלונית מטמון האחסון בחלונית אפליקציה של כלי הפיתוח. מרחיבים את הקטע והשם של המטמון הסטטי ושל מטמון הנתונים אמור להופיע בצד ימין. פתיחת מטמון הנתונים אמורה להציג את הנתונים המאוחסנים לכל עיר.

עוברים לחלונית Service Workers ומסמנים את התיבה אופליין. יש לנסות לטעון את הדף מחדש, ואז לעבור למצב אופליין ולטעון מחדש את הדף.

אם יש לך רשת מהירה וברצונך לראות איך הנתונים של תחזית מזג האוויר מעודכנים בחיבור איטי, יש להגדיר את הנכס FORECAST_DELAY ב-server.js כ-5000. כל הבקשות ל-API של התחזית יתעכבו ב-5,000 אלפיות השנייה.

אימות שינויים באמצעות Lighthouse

כדאי גם להפעיל את Lighthouse שוב.

ביקורת על אופטימיזציה למנועי חיפוש

  • 👋 עבר: למסמך יש תיאור מטא.

ביקורת של Progressive Web App

  • אישור עבר: הדף הנוכחי מגיב בסטטוס 200 כשהוא במצב אופליין.
  • עבר בהצלחה: start_url מגיב בסטטוס 200 כשהוא במצב אופליין.
  • שובר עבר: רישום של קובץ שירות (service worker) ששולט בדף וב-start_url.
  • עבר בהצלחה: מניפסט אפליקציית האינטרנט עומד בדרישות ההתקנה.
  • עבר בהצלחה: מוגדר למסך פתיחה מותאם אישית.
  • הרצת לעבור: הגדרת צבע עיצוב בסרגל הכתובות.

כשמתקינים Progressive Web App, היא נראית ומתנהגת כמו כל האפליקציות האחרות שמותקנות. הוא יופעל מאותו מקום שבו אפליקציות אחרות מופעלות. הוא פועל באפליקציה ללא סרגל כתובות או ממשק משתמש אחר של דפדפן. וכמו כל אפליקציה מותקנת אחרת, היא גם אפליקציה ברמה העליונה במעבר בין המשימות.

ב-Chrome, אפשר להתקין אפליקציית Progressive Web App דרך תפריט ההקשר של שלוש נקודות. לחלופין, אפשר לספק למשתמש לחצן או רכיב אחר בממשק המשתמש, שיבקש מהם להתקין את האפליקציה.

ביקורת באמצעות Lighthouse

כדי שהמשתמש יוכל להתקין את Progressive Web App, האפליקציה צריכה לעמוד בקריטריונים מסוימים. הדרך הקלה ביותר לבדוק היא להשתמש ב-Lighthouse ולוודא שהוא עומד בקריטריונים להתקנה.

אם עבדתם בעבר על קוד ה-Lab הזה, ה-PWA כבר אמור לעמוד בקריטריונים האלה.

הוספה של Install.js ל-index.html

קודם כל, נוסיף את install.js לקובץ index.html שלנו.

public/index.html

<!-- CODELAB: Add the install script here -->
<script src="/scripts/install.js"></script>

beforeinstallprompt אירועים

אם משתמשים בקריטריון להוספה למסך הבית, Chrome יפעיל אירוע beforeinstallprompt שאפשר להשתמש בו כדי לציין שהאפליקציה יכולה להיות 'מותקנת ב-#39; ואז לבקש מהמשתמש להתקין אותה. צריך להוסיף את הקוד בהמשך כדי להאזין לאירוע beforeinstallprompt:

public/scripts/install.js

// CODELAB: Add event listener for beforeinstallprompt event
window.addEventListener('beforeinstallprompt', saveBeforeInstallPromptEvent);

שמירת האירוע והצגת לחצן ההתקנה

בפונקציה saveBeforeInstallPromptEvent אנחנו נשמור הפניה לאירוע beforeinstallprompt כדי שנוכל להתקשר אליו אל prompt() מאוחר יותר ולעדכן את ממשק המשתמש כדי להציג את לחצן ההתקנה.

public/scripts/install.js

// CODELAB: Add code to save event & show the install button.
deferredInstallPrompt = evt;
installButton.removeAttribute('hidden');

הצגת הבקשה והסתרת הלחצן

כשהמשתמש לוחץ על לחצן ההתקנה, אנחנו צריכים להתקשר אל .prompt() באירוע beforeinstallprompt שנשמר. עלינו גם להסתיר את לחצן ההתקנה, מפני שניתן להתקשר אל .prompt() רק פעם אחת בכל אירוע שמור.

public/scripts/install.js

// CODELAB: Add code show install prompt & hide the install button.
deferredInstallPrompt.prompt();
// Hide the install button, it can't be called twice.
evt.srcElement.setAttribute('hidden', true);

שיחה אל .prompt() תציג תיבת דו-שיח של חלון העזר למשתמש, שבה הוא יתבקש להוסיף את האפליקציה למסך הבית.

רושמים את התוצאות

אפשר לבדוק איך המשתמש הגיב לתיבת הדו-שיח של ההתקנה על ידי האזנה להבטחה שהוחזר בנכס userChoice של האירוע השמור beforeinstallprompt. ההבטחה מחזירה אובייקט עם מאפיין outcome לאחר שמוצגת בקשה והמשתמש השיב לה.

public/scripts/install.js

// CODELAB: Log user response to prompt.
deferredInstallPrompt.userChoice
    .then((choice) => {
      if (choice.outcome === 'accepted') {
        console.log('User accepted the A2HS prompt', choice);
      } else {
        console.log('User dismissed the A2HS prompt', choice);
      }
      deferredInstallPrompt = null;
    });

הערה אחת על userChoice: המפרט מגדיר את הנכס הזה, ולא פונקציה כפי שציפיתם.

תיעוד של כל אירועי ההתקנה

בנוסף לכל ממשק משתמש שמוסיפים כדי להתקין את האפליקציה, משתמשים יכולים להתקין את ה-PWA גם בדרכים אחרות, למשל תפריט שלוש הנקודות של Chrome. כדי לעקוב אחר האירועים האלה, יש להאזין לאירוע המותקן באפליקציה.

public/scripts/install.js

// CODELAB: Add event listener for appinstalled event
window.addEventListener('appinstalled', logAppInstalled);

לאחר מכן, נצטרך לעדכן את הפונקציה logAppInstalled. עבור קוד Lab זה, נשתמש בconsole.log בלבד, אבל באפליקציית ייצור כנראה תרצו לתעד אותו כאירוע עם תוכנת הניתוח שלכם.

public/scripts/install.js

// CODELAB: Add code to log the event
console.log('Weather App was installed.', evt);

עדכון קובץ השירות (service worker)

חשוב לזכור לעדכן את CACHE_NAME בקובץ service-worker.js כי ביצעת שינויים בקבצים שכבר שמורים במטמון. הפעלה של תיבת הסימון מעקף לרשת בחלונית Works שבחלונית Application ב-Devtools, תפעל בפיתוח, אבל לא תעזור בעולם האמיתי.

רוצים לנסות?

אנחנו מזמינים אותך לראות את שלב ההתקנה. ליתר ביטחון, יש להשתמש בלחצן ניקוי נתוני האתר בחלונית האפליקציה של כלי הפיתוח כדי לנקות את כל הנתונים ולוודא שאנחנו מתחילים מחדש. אם התקנתם את האפליקציה בעבר, הקפידו להסיר אותה. אם לא, סמל ההתקנה לא יופיע שוב.

מוודאים שלחצן ההתקנה גלוי

קודם צריך לאמת שסמל ההתקנה שלנו מופיע כמו שצריך. חשוב לנסות את זה גם במחשב וגם בנייד.

  1. פותחים את כתובת ה-URL בכרטיסייה חדשה ב-Chrome.
  2. פותחים את תפריט שלוש הנקודות של Chrome& (ליד סרגל הכתובות).
    ▬ לאמת שרואים את &&rd;התקנת מזג האוויר..." בתפריט.
  3. מרעננים את נתוני מזג האוויר באמצעות לחצן הרענון בפינה השמאלית העליונה, כדי להבטיח שאנחנו עומדים בהיוריסטיקה של מעורבות המשתמשים.
    ▸ מוודאים שסמל ההתקנה מופיע בכותרת האפליקציה.

מוודאים שלחצן ההתקנה פועל

בשלב הבא, נוודא שהכול מותקן כמו שצריך והאירועים שלנו מופעלים באופן תקין. ניתן לעשות זאת במחשב או בנייד. אם ברצונך לבדוק את הפעולה בנייד, יש לוודא שנעשה שימוש בניפוי באגים מרחוק כדי שניתן יהיה לראות מה מחובר למסוף.

  1. פותחים את Chrome, ועוברים לכרטיסייה חדשה של מזג אוויר בכרטיסייה 'דפדפן'.
  2. פותחים את כלי הפיתוח ועוברים לחלונית Console.
  3. לוחצים על לחצן ההתקנה בפינה השמאלית העליונה.
    הוספה. מאמתים את לחצן ההתקנה
  4. לוחצים על 'ביטול'.
    MCA אימות ומירכאות;המשתמש סגר את הבקשה מ-A2HS" מופיע בפלט של המסוף.
    ▸ אימות לחצן ההתקנה מופיע שוב.
  5. לוחצים שוב על לחצן ההתקנה ולוחצים על לחצן ההתקנה בתיבת הדו-שיח של חלון העזר.
    ▸ אימות ומירכאות;המשתמש אישר את הבקשה מ-A2HS"
    בפלט של המסוף.
    ▢ אימות וציטוט;האפליקציה לתחזית מזג האוויר מופיעה בפלט של המסוף.
    ▬ לאמת שאפליקציית מזג האוויר מתווספת למקום שבו בדרך כלל מתבצע חיפוש אפליקציות.
  6. מפעילים את 'תחזית מזג האוויר' (PWA).
    MCA מוודאים שהאפליקציה נפתחת כאפליקציה נפרדת, בחלון של האפליקציה במחשב או במסך מלא בנייד.

.

איך לוודא שהתקנת iOS פועלת כראוי

בודקים את ההתנהגות ב-iOS. אם יש לכם מכשיר iOS, תוכלו להשתמש ב-כדאי להפעיל את סימולטור iOS הזמין ב-Xcode.

  1. פותחים את Safari בכרטיסייה חדשה בדפדפן ועוברים אל מזג האוויר PWA.
  2. לוחצים על הלחצן שיתוף .
  3. גוללים שמאלה ולוחצים על הלחצן הוספה למסך הבית.
    ▬ לאמת את הכותרת, כתובת ה-URL והסמל נכונים.
  4. לוחצים על הוספה.
    ▚ מוודאים שסמל האפליקציה נוסף למסך הבית.
  5. מפעילים את אפליקציית PWA של מזג האוויר ממסך הבית.
    ▬ לאמת שהאפליקציה מפעילה את המסך המלא.

בונוס: בדיקה אם האפליקציה מופעלת ממסך הבית

שאילתת המדיה של display-mode מאפשרת להחיל סגנונות בהתאם לאופן ההפעלה של האפליקציה, או לקביעת האופן שבו היא הופעלה באמצעות JavaScript.

@media all and (display-mode: standalone) {
  body {
    background-color: yellow;
  }
}

אפשר גם לבדוק את שאילתת המדיה של display-mode ב-JavaScript ולבדוק אם אתה פועל באופן עצמאי.

בונוס: הסרת האפליקציה מסוג PWA

זכרו, המכשיר beforeinstallevent לא מופעל אם האפליקציה כבר מותקנת, לכן סביר להניח שתרצו להתקין ולהסיר את האפליקציה כמה פעמים כדי לוודא שהכול פועל כמו שצריך.

Android

ב-Android, מתבצעת הסרה של אפליקציות מסוג PWA באותה דרך שבה מוסרות אפליקציות מותקנות אחרות.

  1. פותחים את חלונית ההזזה לאפליקציות.
  2. גוללים למטה כדי למצוא את סמל מזג האוויר.
  3. גוררים את סמל האפליקציה לחלק העליון של המסך.
  4. בוחרים באפשרות הסרת ההתקנה.

Chrome OS

ב-Chrome OS, ניתן להסיר בקלות אפליקציות PWA מתיבת החיפוש של מרכז האפליקציות.

  1. פותחים את מרכז האפליקציות.
  2. מקלידים "Weather" בתיבת החיפוש אמורה להופיע התוצאות של PWA של מזג האוויר בתוצאות.
  3. לוחצים לחיצה ימנית (alt-click) על ערוץ מזג האוויר.
  4. לוחצים על הסרה מ-Chrome...

macOS ו-Windows

ב-Mac וב-Windows, ניתן להסיר אפליקציות PWA דרך Chrome:

  1. בכרטיסייה חדשה בדפדפן, פותחים את chrome://apps .
  2. לוחצים לחיצה ימנית (alt-click) על ערוץ מזג האוויר.
  3. לוחצים על הסרה מ-Chrome...

אתם יכולים גם לפתוח את ה-PWA המותקן, ללחוץ על תפריט ההקשר של שלוש נקודות בפינה השמאלית העליונה ולבחור באפשרות "הסרת מזג האוויר PWA..."

מזל טוב, הצלחת ליצור את Progressive Web App הראשונה שלך!

הוספתם מניפסט של אפליקציית אינטרנט כדי לאפשר את ההתקנה שלה והוספתם קובץ שירות (service worker) כדי לוודא שה-PWA תמיד יהיה מהיר ואמין. למדתם איך להשתמש בכלי הפיתוח כדי לערוך ביקורת על אפליקציה ואיך היא יכולה לשפר את חוויית המשתמש.

עכשיו אנחנו יודעים את השלבים העיקריים הנדרשים כדי להפוך כל אפליקציית אינטרנט לאפליקציית Progressive Web App.

מה השלב הבא?

הנה כמה ממעבדות הקוד האלה...

קריאה נוספת

מסמכי עזר