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

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

סקירה כללית

אפליקציות Chrome מקבלות את הדברים הבאים בחינם:

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

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

כדאי להשתמש בנתונים מקומיים כשאפשר.
כשמשתמשים במשאבים מהאינטרנט, צריך להשתמש ב-XMLHttpRequest כדי לקבל אותם, ולאחר מכן לשמור את הנתונים באופן מקומי. כדי לשמור נתונים באופן מקומי, אפשר להשתמש ב-Chrome Storage API, ב-IndexedDB או ב-Filesystem API.
הפרידו בין ממשק המשתמש של האפליקציה לבין הנתונים שלה.
הפרדה של ממשק המשתמש והנתונים לא רק משפרת את עיצוב האפליקציה ומקלה על המשימה של הפעלת שימוש אופליין, אלא גם מאפשרת לספק תצוגות אחרות של נתוני המשתמש. מסגרת MVC יכולה לעזור לך לשמור על הפרדה בין ממשק המשתמש לבין הנתונים.
אפשר להניח שהאפליקציה יכולה להיות סגורה בכל שלב.
שמירה של מצב האפליקציה (גם באופן מקומי וגם מרחוק, במידת האפשר) כדי שהמשתמשים יוכלו להמשיך מהנקודה שבה הפסיקו.
בודקים את האפליקציה ביסודיות.
חשוב לוודא שהאפליקציה פועלת היטב בתרחישים נפוצים וגם בתרחישים מורכבים.

הגבלות אבטחה

יש הגבלה על המקומות שבהם ניתן למקם את המשאבים של אפליקציות Chrome:

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

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

עם זאת, אתם יכולים לטעון משאבי מדיה גדולים כמו סרטונים וצלילים מאתרים חיצוניים. אחת הסיבות לחריגה מהכלל הזה היא שלרכיבים <video> ו-<audio> יש התנהגות חלופית טובה אם הקישוריות של האפליקציה מוגבלת או כשאין בה קישוריות. סיבה נוספת היא שבשלב הזה, אחזור והצגה של מדיה באמצעות כתובות URL של blob ו-XMLHttpRequest לא מאפשרים סטרימינג או אגירת נתונים חלקית.

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

חלק מההגבלות על אפליקציות Chrome נאכפות על ידי Content Security Policy (CSP). המדיניות הזו תמיד חלה על אפליקציות Chrome, ואי אפשר לשנות אותה:

default-src 'self';
connect-src * data: blob: filesystem:;
style-src 'self' blob: data: filesystem: 'unsafe-inline';
img-src 'self' blob: data: filesystem:;
frame-src 'self' blob: data: filesystem:;
font-src 'self' blob: data: filesystem:;
media-src * data: blob: filesystem:;

ציון אופליין_enabled

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

{
  "name": "My app",
  ...
  "offline_enabled": false,
  ...
}

שמירת נתונים באופן מקומי

בטבלה הבאה מוצגות האפשרויות לשמירת נתונים באופן מקומי (ראו גם ניהול נתונים).

APIהשימוש הטוב ביותרהערות
ממשק API של Chrome Storageכמויות קטנות של נתוני מחרוזותמצוין להגדרות ולמצב. קל לסנכרן מרחוק (אבל לא צריך). לא מתאים לכמויות גדולות יותר של נתונים בגלל מכסות.
ממשק API של IndexedDBנתונים מובְניםהפעלת חיפושים מהירים של נתונים. לשימוש עם ההרשאה unlimitedStorage.
API של מערכת הקבציםרוצה להוסיף משהו?יש אזור ארגז חול שבו אפשר לאחסן קבצים. לשימוש עם ההרשאה unlimitedStorage.

שמירת נתונים מרחוק

באופן כללי, אתם קובעים איך לשמור נתונים מרחוק, אבל חלק מה-frameworks וממשקי ה-API יכולים לעזור (מידע נוסף זמין בארכיטקטורת MVC). אם משתמשים ב-Chrome Storage API, כל הנתונים שניתן לסנכרן מסתנכרנים באופן אוטומטי בכל פעם שהאפליקציה מחוברת לאינטרנט והמשתמש מחובר ל-Chrome. אם המשתמש לא מחובר, הוא יתבקש להיכנס. עם זאת, חשוב לדעת שהנתונים המסונכרנים של המשתמש נמחקים אם המשתמש מסיר את ההתקנה של האפליקציה. {QUESTION: true?}

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

הפרדת ממשק המשתמש מנתונים

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

אם האפליקציה מתקשרת אל שרת מותאם אישית, השרת צריך לספק לכם נתונים, ולא קטעי HTML. צריך לחשוב במונחים של ממשקי API ל-RESTful.

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

בדיקה

חשוב לוודא שהאפליקציה פועלת בצורה תקינה בנסיבות הבאות:

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

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