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

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

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

לסווג כל פעולה לפני שמתכננים

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

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

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

שמירה מקומית: מה יורד לטלפון מראש, ולכמה זמן הוא תקף

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

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

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

פעולות שנכתבות בלי רשת: תור, מזהה ייחודי וסטטוס גלוי

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

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

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

סנכרון נתונים והתנגשויות: מי גובר כששניים שינו את אותה רשומה

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

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

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

כניסה, הרשאות ועדכוני גרסה כשהמכשיר מנותק

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

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

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

אפליקציה לעובדי שטח: מה לבקש באפיון ובהצעה

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

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

בדיקת קבלה לאפליקציה שעובדת בלי אינטרנט, לפני פיילוט

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

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

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