תאריך פרסום: 2 בדצמבר 2020
מאז ההשקה של פעילות אינטרנט מהימנה, צוות Chrome ייעל את השימוש בה באמצעות Bubblewrap. הוספנו תכונות נוספות, כמו שילוב של חיוב ב-Google Play, והפעלנו את התכונה בפלטפורמות נוספות, כמו ChromeOS.
התכונות Bubblewrap ו-Trusted Web
בעזרת בועות אפשר ליצור אפליקציות שמפעילות את אפליקציות ה-PWA במסגרת פעילות אמינה באינטרנט, בלי צורך בידע על כלים ספציפיים לפלטפורמה.
תהליך הגדרה פשוט יותר
בעבר, כדי להשתמש ב-Bubblewrap היה צריך להגדיר באופן ידני את ערכת הפיתוח של Java ואת Android SDK, ושתיהן נוטות לשגיאות. הכלי מציע עכשיו הורדה אוטומטית של יחסי התלות החיצוניים כשמפעילים אותו בפעם הראשונה.
אם אתם מעדיפים לעשות זאת, תוכלו להמשיך להשתמש בהתקנה קיימת של יחסי התלות, והפקודה החדשה doctor תעזור לאתר בעיות ותמליץ על תיקונים להגדרות, שאותם תוכלו לעדכן עכשיו משורת הפקודה באמצעות הפקודה updateConfig.
אשף משופר
כשיוצרים פרויקט עם init, ל-Fuawrap נדרש מידע כדי ליצור את האפליקציה ל-Android. הכלי מחלץ ערכים מהמניפסט של אפליקציית האינטרנט ומספק ברירות מחדל כשזה אפשרי.
אפשר לשנות את הערכים האלה כשיוצרים פרויקט חדש, אבל בעבר המשמעות של כל שדה לא הייתה ברורה. תיבת הדו-שיח של האימות נבנתה מחדש עם תיאורים ותיקוף טובים יותר לכל שדה קלט.
הצגת תמיכה במסך מלא ובכיוון
בחלק מהמקרים כדאי שהאפליקציה תשתמש בכמה שיותר מהמסך. כשמפתחים אפליקציות PWA, צריך להגדיר את השדה display במניפסט של אפליקציית האינטרנט לערך fullscreen.
כש-Bubblewrap מזהה את האפשרות של מסך מלא במניפסט של אפליקציית האינטרנט, הוא מגדיר שהאפליקציה ל-Android תופעל גם במסך מלא, או במצב immersive, במונחים ספציפיים ל-Android.
השדה orientation מתוך המניפסט של אפליקציית האינטרנט קובע אם האפליקציה צריכה להיפתח במצב לאורך, במצב לרוחב או בכיוון שבו המכשיר פועל כרגע. Bubblewrap קורא עכשיו את השדה Web App Manifest ומשתמש בו כברירת מחדל כשיוצרים את אפליקציית Android.
יש לך אפשרות להתאים אישית את שתי ההגדרות במסגרת התהליך של bubblewrap init.
פלט של AppBundles
חבילות App Bundle הן פורמט פרסום לאפליקציות, שבו מערכת Play אחראית ליצירה ולחתימה על קובץ ה-APK הסופי. בפועל, כך אפשר להציג למשתמשים קבצים קטנים יותר כשהם מורידים את האפליקציה מהחנות.
עכשיו wrapwrap נארז את האפליקציה כ-App Bundle, בקובץ בשם app-release-bundle.aab. מומלץ להשתמש בפורמט הזה כשמפרסמים אפליקציות ב-Play Store, כי החל משנת 2021 חובה להשתמש בו בחנות.
הענקת גישה למיקום גיאוגרפי
המשתמשים מצפים שהאפליקציות שמותקנות במכשירים שלהם יפעלו באופן עקבי, ללא קשר לטכנולוגיה. כשמשתמשים בהרשאה מיקום גיאוגרפי בפעילות מהימנה באינטרנט, אפשר להעביר אותה למערכת ההפעלה. כשהיא מופעלת, המשתמשים רואים את אותם תיבת דו-שיח כמו באפליקציות שנוצרו ב-Kotlin או ב-Java, ומוצגים להם אמצעי בקרה לניהול ההרשאה באותו מקום.
אפשר להוסיף את התכונה באמצעות Bubblewrap, ומכיוון שהיא מוסיפה יחסי תלות נוספים לפרויקט Android, צריך להפעיל אותה רק כשאפליקציית האינטרנט משתמשת בהרשאת המיקום הגיאוגרפי.
קובצי בינארי שהותאמו
מכשירים עם נפח אחסון מוגבל נפוצים באזורים מסוימים בעולם, ובעלי המכשירים האלה בדרך כלל מעדיפים אפליקציות קטנות יותר. אפליקציות שמשתמשות ב-Trusted Web Activity יוצרות קובצי בינארי קטנים, שמפחיתים את החששות של המשתמשים האלה.
ב-Bubblewrap בוצעה אופטימיזציה על ידי צמצום רשימת הספריות הנדרשות ל-Android, וכתוצאה מכך קובצי הבינארי שנוצרו קטנים ב-800,000. בפועל, זהו פחות ממחצית מהגודל הממוצע שנוצר בגרסאות קודמות. כדי ליהנות מהקובצי הבינארי הקטנים יותר, צריך רק לעדכן את האפליקציה באמצעות הגרסה האחרונה של Bubblewrap.
איך מעדכנים אפליקציה קיימת
אפליקציה שנוצרה על ידי Bubblewrap מורכבת מאפליקציית אינטרנט ומעטפת קלה ל-Android שפותחת את ה-PWA. למרות ש-PWA שנפתח בפעילות אינטרנט מהימנה עוקב אחרי אותם מחזורי עדכון כמו כל אפליקציית אינטרנט, אפשר לעדכן את המעטפת המקורית ורצוי לעשות זאת.
כדאי לעדכן את האפליקציה כדי לוודא שהיא משתמשת בגרסה האחרונה של המעטפת, עם התכונות והתיקונים האחרונים של הבאגים. לאחר התקנת הגרסה האחרונה של wrapper, הפקודה update מחילה את הגרסה האחרונה של ה-wrapper על פרויקט קיים:
npm update -g @bubblewrap/cli
bubblewrap update
bubblewrap build
עוד סיבה לעדכן את האפליקציות האלה היא לוודא שהשינויים במניפסט האינטרנט יחולו על האפליקציה. משתמשים בפקודה החדשה merge:
bubblewrap merge
bubblewrap update
bubblewrap build
עדכונים בקריטריונים של איכות
ב-Chrome 86 הוספנו שינויים לקריטריונים של איכות הפעילות המהימנה באינטרנט. אפשר לקרוא הסבר מלא על השינויים במאמר שינויים בקריטריונים של איכות באפליקציות PWA המשתמשות בפעילות מהימנה באינטרנט.
סיכום קצר: כדי למנוע קריסה של האפליקציות, צריך לוודא שהן מטפלות בתרחישים הבאים:
- אימות של קישורים לנכסים דיגיטליים נכשל במהלך השקת האפליקציה
- החזרת HTTP 200 נכשלה עבור בקשת משאב רשת אופליין
- החזרת שגיאת HTTP 404 או 5xx באפליקציה.
בנוסף לוודא שהאפליקציה עוברת את אימות Digital Asset Links, אפשר להשתמש ב-service worker כדי לטפל בתרחישים הנותרים:
self.addEventListener('fetch', event => {
event.respondWith((async () => {
try {
return await fetchAndHandleError(event.request);
} catch {
// Failed to load from the network. User is offline or the response
// has a status code that triggers the Quality Criteria.
// Try loading from cache.
const cachedResponse = await caches.match(event.request);
if (cachedResponse) {
return cachedResponse;
}
// Response was not found on the cache. Send the error / offline
// page. OFFLINE_PAGE should be pre-cached when the service worker
// is activated.
return await caches.match(OFFLINE_PAGE);
}
})());
});
async function fetchAndHandleError(request) {
const cache = await caches.open(RUNTIME_CACHE);
const response = await fetch(request);
// Throw an error if the response returns one of the status
// that trigger the Quality Criteria.
if (response.status === 404 ||
response.status >= 500 && response.status < 600) {
throw new Error(`Server responded with status: ${response.status}`);
}
// Cache the response if the request is successful.
cache.put(request, response.clone());
return response;
}
כשמשתמשים ב-Workbox, המערכת משתמשת בשיטות מומלצות ומסירת סטנדרטי (בוילרפלייט) כשמשתמשים ב-Service Workers. לחלופין, אפשר להשתמש בפלאגין של Workbox כדי לטפל בתרחישים האלה:
export class FallbackOnErrorPlugin {
constructor(offlineFallbackUrl, notFoundFallbackUrl, serverErrorFallbackUrl) {
this.notFoundFallbackUrl = notFoundFallbackUrl;
this.offlineFallbackUrl = offlineFallbackUrl;
this.serverErrorFallbackUrl = serverErrorFallbackUrl;
}
checkTrustedWebActivityCrash(response) {
if (response.status === 404 || response.status >= 500 && response.status <= 600) {
const type = response.status === 404 ? 'E_NOT_FOUND' : 'E_SERVER_ERROR';
const error = new Error(`Invalid response status (${response.status})`);
error.type = type;
throw error;
}
}
// This is called whenever there's a network response,
// but we want special behavior for 404 and 5**.
fetchDidSucceed({response}) {
// Cause a crash if this is a Trusted Web Activity crash.
this.checkTrustedWebActivityCrash(response);
// If it's a good response, it can be used as-is.
return response;
}
// This callback is new in Workbox v6, and is triggered whenever
// an error (including a NetworkError) is thrown when a handler runs.
handlerDidError(details) {
let fallbackURL;
switch (details.error.details.error.type) {
case 'E_NOT_FOUND': fallbackURL = this.notFoundFallbackUrl; break;
case 'E_SERVER_ERROR': fallbackURL = this.serverErrorFallbackUrl; break;
default: fallbackURL = this.offlineFallbackUrl;
}
return caches.match(fallbackURL, {
// Use ignoreSearch as a shortcut to work with precached URLs
// that have _WB_REVISION parameters.
ignoreSearch: true,
});
}
}