תאריך פרסום: 2 בדצמבר 2020
מאז שהושקה פעילות Trusted Web, צוות Chrome הפך את השימוש בה לקל יותר באמצעות Bubblewrap. הוספנו תכונות נוספות, כמו שילוב עם חיוב ב-Google Play, ואפשרנו להפעיל אותה בפלטפורמות נוספות, כמו ChromeOS.
תכונות של Bubblewrap ופעילות Trusted Web
Bubblewrap עוזר לכם ליצור אפליקציות שמפעילות את ה-PWA שלכם בתוך פעילות Trusted Web, בלי שתצטרכו להכיר את הכלים הספציפיים לפלטפורמה.
תהליך הגדרה פשוט יותר
בעבר, כדי להשתמש ב-Bubblewrap היה צריך להגדיר באופן ידני את Java Development Kit ואת Android SDK, שניהם מועדים לשגיאות. עכשיו הכלי מציע להוריד באופן אוטומטי את יחסי התלות החיצוניים כשמפעילים אותו בפעם הראשונה.
אם אתם מעדיפים, אתם עדיין יכולים להשתמש בהתקנה קיימת של יחסי התלות. הפקודה החדשה doctor עוזרת למצוא בעיות וממליצה על תיקונים להגדרה, שאותה אפשר עכשיו לעדכן משורת הפקודה באמצעות הפקודה updateConfig.
אשף משופר
כשיוצרים פרויקט באמצעות init, צריך לספק ל-Bubblewrap מידע כדי ליצור את אפליקציית Android. הכלי מחלץ ערכים מקובץ המניפסט של אפליקציית האינטרנט ומספק ערכי ברירת מחדל כשאפשר.
אפשר לשנות את הערכים האלה כשיוצרים פרויקט חדש, אבל בעבר המשמעות של כל שדה לא הייתה ברורה. תיבות הדו-שיח של ההפעלה נבנו מחדש עם תיאורים טובים יותר ואימות לכל שדה להזנת קלט.
תמיכה במסך מלא ובכיוון המסך
במקרים מסוימים, יכול להיות שתרצו שהאפליקציה תשתמש בכמה שיותר שטח מסך. כשמפתחים אפליקציות אינטרנט מתקדמות, אפשר לעשות את זה על ידי הגדרת השדה display מקובץ המניפסט של אפליקציית האינטרנט לערך fullscreen.
כשהכלי Bubblewrap מזהה את האפשרות fullscreen בקובץ מניפסט של אפליקציית האינטרנט, הוא מגדיר את אפליקציה ל-Android כך שגם היא תופעל במסך מלא, או במצב אימרסיבי, במונחים ספציפיים של Android.
השדה orientation במניפסט של אפליקציית האינטרנט קובע אם האפליקציה תופעל במצב לאורך, במצב לרוחב או בכיוון שבו המכשיר נמצא כרגע. עכשיו Bubblewrap קורא את השדה של קובץ מניפסט של אפליקציה ומשתמש בו כברירת מחדל כשיוצרים את אפליקציית Android.
אפשר להתאים אישית את שתי ההגדרות כחלק מתהליך bubblewrap init.
פלט של AppBundles
App Bundle הוא פורמט פרסום לאפליקציות שמעביר את היצירה והחתימה הסופית של ה-APK ל-Play. בפועל, זה מאפשר להציג למשתמשים קבצים קטנים יותר כשהם מורידים את האפליקציה מהחנות.
עכשיו Bubblewrap אורז את האפליקציה כ-App Bundle, בקובץ שנקרא app-release-bundle.aab. מומלץ להשתמש בפורמט הזה כשמפרסמים אפליקציות בחנות Play, כי החנות דורשת את זה החל משנת 2021.
הענקת הרשאה למיקום גיאוגרפי
המשתמשים מצפים שהאפליקציות שמותקנות במכשירים שלהם יפעלו באופן עקבי, בלי קשר לטכנולוגיה. כשמשתמשים בהרשאת GeoLocation בתוך פעילות Trusted Web, אפשר עכשיו להעביר אותה למערכת ההפעלה. כשההרשאה מופעלת, המשתמשים רואים את אותן תיבות דו-שיח כמו באפליקציות שנוצרו באמצעות Kotlin או Java, ומוצאים אמצעי בקרה לניהול ההרשאה באותו מקום.
אפשר להוסיף את התכונה באמצעות Bubblewrap. מכיוון שהיא מוסיפה עוד יחסי תלות לפרויקט Android, כדאי להפעיל אותה רק כשאפליקציית האינטרנט משתמשת בהרשאת המיקום הגיאוגרפי.
קובצי בינארי שעברו אופטימיזציה
מכשירים עם נפח אחסון מוגבל נפוצים באזורים מסוימים בעולם, והבעלים של המכשירים האלה מעדיפים לעיתים קרובות אפליקציות קטנות יותר. אפליקציות שמשתמשות בפעילות Trusted Web מייצרות קבצים בינאריים קטנים, מה שמפחית את החשש של המשתמשים.
הכלי Bubblewrap עבר אופטימיזציה על ידי צמצום רשימת ספריות Android הנדרשות, וכתוצאה מכך הקבצים הבינאריים שנוצרו קטנים ב-800k. בפועל, זה פחות מחצי מהגודל הממוצע שנוצר בגרסאות קודמות. כדי ליהנות מהיתרונות של קובצי הבינארי הקטנים יותר, צריך רק לעדכן את האפליקציה באמצעות הגרסה העדכנית של Bubblewrap.
איך מעדכנים אפליקציה קיימת
אפליקציה שנוצרה על ידי Bubblewrap מורכבת מאפליקציית אינטרנט וממעטפת קלה ל-Android שפותחת את ה-PWA. למרות שה-PWA שנפתחה בתוך פעילות Trusted Web פועלת לפי אותם מחזורי עדכון כמו כל אפליקציית אינטרנט, אפשר וצריך לעדכן את ה-wrapper המקורי.
כדאי לעדכן את האפליקציה כדי לוודא שהיא משתמשת בגרסה העדכנית ביותר של ה-wrapper, עם תיקוני הבאגים והתכונות העדכניים ביותר. אחרי שמתקינים את הגרסה העדכנית של Bubblewrap, הפקודה update מחילה את הגרסה העדכנית של ה-wrapper על פרויקט קיים:
npm update -g @bubblewrap/cli
bubblewrap update
bubblewrap build
סיבה נוספת לעדכן את האפליקציות האלה היא לוודא שהשינויים במניפסט של האפליקציה לאינטרנט חלים על האפליקציה. כדי לעשות את זה, משתמשים בפקודה החדשה merge:
bubblewrap merge
bubblewrap update
bubblewrap build
עדכונים בקריטריונים לאיכות
בגרסה 86 של Chrome בוצעו שינויים בקריטריונים לאיכות של פעילות Trusted Web. השינויים האלה מוסברים במלואם במאמר שינויים בקריטריונים לאיכות של אפליקציות Progressive Web App (PWA) שמשתמשות בפעילות Trusted Web.
בקצרה, כדי למנוע קריסות של האפליקציות, צריך לוודא שהן מטפלות בתרחישים הבאים:
- אימות Digital Asset Links נכשל בהשקת האפליקציה
- לא הוחזר קוד 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 Worker. לחלופין, אפשר להשתמש בפלאגין של 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,
});
}
}