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

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

סקירה כללית

אפליקציות 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> חלופה טובה ההתנהגות כשהקישוריות של האפליקציה מוגבלת או שאין לה קישוריות כלל. סיבה נוספת היא שאחזור והצגה מדיה עם XMLHttpRequest וכתובות URL של blob לא מאפשרת כרגע סטרימינג או אגירת נתונים חלקית.

כדי לספק 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,
  ...
}

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

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

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

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

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

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

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

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

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

בדיקה

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

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

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