תאריך פרסום: 2 בדצמבר 2020
מאז ההשקה של פעילות אינטרנט מהימנה, צוות Chrome ייעל את השימוש בה באמצעות Bubblewrap. הוספנו תכונות נוספות, כמו שילוב של חיוב ב-Google Play, והפעלנו את התכונה בפלטפורמות נוספות, כמו ChromeOS.
התכונות Bubblewrap ו-Trusted Web
Bubblewrap עוזר ליצור אפליקציות שמפעילות את ה-PWA שלכם בתוך פעילות אינטרנט מהימנה, בלי צורך בידע בכלים ספציפיים לפלטפורמה.
תהליך הגדרה פשוט יותר
בעבר, כדי להשתמש ב-Bubblewrap היה צריך להגדיר באופן ידני את ערכת הפיתוח של Java ואת Android SDK, ושתיהן נוטות לשגיאות. עכשיו הכלי מציע להוריד את יחסי התלות החיצוניים באופן אוטומטי כשמריצים אותו בפעם הראשונה.
עדיין אפשר להשתמש בהתקנה קיימת של יחסי התלות, אם אתם מעדיפים לעשות זאת, והפקודה החדשה doctor עוזרת למצוא בעיות ולהמליץ על תיקונים לתצורה, שאפשר לעדכן עכשיו משורת הפקודה באמצעות הפקודה updateConfig.
אשף משופר
כשיוצרים פרויקט באמצעות init, ל-Bubblewrap נדרש מידע כדי ליצור את אפליקציית Android. הכלי מחלץ ערכים ממניפסט אפליקציית האינטרנט ומספק ברירת מחדל במקרים שבהם הדבר אפשרי.
אפשר לשנות את הערכים האלה כשיוצרים פרויקט חדש, אבל בעבר לא היה ברור מה המשמעות של כל שדה. תיבת הדו-שיח של האימות נבנתה מחדש עם תיאורים ותיקוף טובים יותר לכל שדה קלט.
תמיכה בתצוגה במסך מלא ובכיוון המסך
במקרים מסוימים, יכול להיות שתרצו שהאפליקציה שלכם תשתמש בחלק הגדול ביותר של המסך האפשרי. כשמפתחים אפליקציות ל-PWA, כדי להטמיע את האפשרות הזו מגדירים את השדה display מתוך המניפסט של אפליקציית האינטרנט לערך fullscreen.
כש-Bubblewrap מזהה את האפשרות של מסך מלא במניפסט של אפליקציית האינטרנט, הוא מגדיר את אפליקציית Android כך שתופעל גם במסך מלא, או במצב immersive, במונחים ספציפיים ל-Android.
השדה orientation מתוך המניפסט של אפליקציית האינטרנט קובע אם האפליקציה צריכה להתחיל במצב לאורך, במצב לרוחב או בכיוון שבו המכשיר פועל כרגע. Bubblewrap קורא עכשיו את השדה Web App Manifest ומשתמש בו כברירת מחדל כשיוצרים את אפליקציית Android.
אפשר להתאים אישית את שתי ההגדרות האלה כחלק מתהליך bubblewrap init.
פלט של AppBundles
חבילות App Bundle הן פורמט פרסום לאפליקציות שמעניק ל-Play את הגישה ליצירה ולחתימה על קובץ ה-APK הסופי. בפועל, כך אפשר להציג למשתמשים קבצים קטנים יותר כשהם מורידים את האפליקציה מהחנות.
Bubblewrap מעכשיו אורז את האפליקציה כ-App Bundle, בקובץ שנקרא app-release-bundle.aab. מומלץ להשתמש בפורמט הזה כשמפרסמים אפליקציות ב-Play Store, כי החל משנת 2021 חובה להשתמש בו בחנות.
הענקת גישה למיקום גיאוגרפי
המשתמשים מצפים שהאפליקציות שמותקנות במכשירים שלהם יפעלו באופן עקבי, ללא קשר לטכנולוגיה. כשמשתמשים בהרשאה GeoLocation בפעילות אינטרנט מהימנה, אפשר להעביר אותה למערכת ההפעלה. כשהיא מופעלת, המשתמשים רואים את אותם תיבת דו-שיח כמו באפליקציות שנוצרו ב-Kotlin או ב-Java, ומוצגים להם אמצעי בקרה לניהול ההרשאה באותו מקום.
אפשר להוסיף את התכונה באמצעות Bubblewrap, ומכיוון שהיא מוסיפה יחסי תלות נוספים לפרויקט Android, צריך להפעיל אותה רק כשאפליקציית האינטרנט משתמשת בהרשאת המיקום הגיאוגרפי.
קובצי בינארי שהותאמו
מכשירים עם נפח אחסון מוגבל נפוצים באזורים מסוימים בעולם, ובעלי המכשירים האלה בדרך כלל מעדיפים אפליקציות קטנות יותר. אפליקציות שמשתמשות ב-Trusted Web Activity יוצרות קובצי בינארי קטנים, שמפחיתים את החששות של המשתמשים האלה.
ב-Bubblewrap בוצעה אופטימיזציה על ידי צמצום רשימת הספריות הנדרשות ל-Android, וכתוצאה מכך קובצי הבינארי שנוצרו קטנים ב-800,000. בפועל, זהו פחות ממחצית מהגודל הממוצע שנוצר בגרסאות קודמות. כדי ליהנות מהקובצי הבינארי הקטנים יותר, צריך רק לעדכן את האפליקציה באמצעות הגרסה האחרונה של Bubblewrap.
איך מעדכנים אפליקציה קיימת
אפליקציה שנוצרה על ידי Bubblewrap מורכבת מאפליקציית אינטרנט ומעטפת קלה ל-Android שפותחת את ה-PWA. למרות ש-PWA שנפתח בפעילות אינטרנט מהימנה עוקב אחרי אותם מחזורי עדכון כמו כל אפליקציית אינטרנט, אפשר לעדכן את המעטפת המקורית ורצוי לעשות זאת.
כדאי לעדכן את האפליקציה כדי לוודא שהיא משתמשת בגרסה האחרונה של המעטפת, עם התכונות והתיקונים האחרונים של הבאגים. אחרי שתתקינו את הגרסה האחרונה של Bubblewrap, תוכלו להשתמש בפקודה update כדי להחיל את הגרסה האחרונה של המעטפת על פרויקט קיים:
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,
});
}
}