למה Offline הוא לא מקרה קצה
מוצר חכם שמפסיק לעבוד כשאין אינטרנט הוא מוצר שנתפס כמקולקל. אפליקציה במצב offline היא לכן דרישה בסיסית כמעט בכל מוצר מחובר: המשתמש נמצא במרתף, בטיסה, בשטח בלי קליטה — או שפשוט הראוטר הביתי נפל. ההחלטה אילו יכולות ימשיכו לעבוד בלי רשת אינה פרט טכני; היא הגדרת מוצר שצריכה להיקבע כבר באפיון, כפי שמוסבר במאמר אפיון אפליקציה.
ההפרדה הקריטית: ערוץ מקומי מול ענן
ברוב מוצרי החומרה יש שני מסלולי תקשורת, וההבנה של ההבדל ביניהם היא הבסיס לתכנון Offline:
- ערוץ ישיר מקומי — בלוטות' (BLE) או Wi-Fi ברשת הביתית. עובד גם כשאין אינטרנט בכלל. שליטה במוצר, קריאת סטטוס ושינוי הגדרות יכולים ורצוי שיעברו כאן. על המימוש ראו איך אפליקציה מתחברת למוצר בבלוטות'.
- ערוץ ענן — שליטה מרחוק, היסטוריה, שיתוף בין משתמשים והתראות Push. דורש אינטרנט בשני הצדדים — ראו שרת וענן למוצר מחובר.
כלל אצבע: כל פעולה שהמשתמש עושה כשהוא ליד המוצר צריכה לעבוד בערוץ המקומי, בלי תלות בענן. אפליקציה שמנתבת הדלקת מנורה דרך שרת מעבר לים — ונכשלת כשהאינטרנט איטי — היא טעות ארכיטקטונית נפוצה ומתסכלת.
מה נדרש בצד האפליקציה
- אחסון מקומי מסודר. מסד נתונים מקומי (SQLite או דומיו) ששומר את מצב המוצר, הגדרות ומדידות אחרונות. האפליקציה נפתחת ומציגה מידע — גם בלי רשת.
- תור פעולות ממתינות. פעולה שדורשת ענן (שינוי אוטומציה, שיתוף) נרשמת בתור ומבוצעת כשהחיבור חוזר. המשתמש מקבל חיווי ברור: "יסונכרן כשיהיה חיבור".
- סנכרון דו-כיווני חכם. כשהרשת חוזרת, צריך למזג: נתונים שהמוצר צבר, שינויים שנעשו מהאפליקציה, ושינויים שנעשו ממכשיר אחר. סנכרון לפי חותמות זמן וגרסאות — לא "האחרון דורס".
- פתרון קונפליקטים מוגדר. מה קורה כששני בני בית שינו את אותה הגדרה במקביל? חייבת להיות מדיניות מוגדרת מראש, אחרת יתקבלו באגים שקשה מאוד לשחזר.
- ממשק שמשקף מצב. אינדיקציה עדינה ל"לא מחובר לענן", נתונים עם ציון מתי עודכנו, וכפתורים שלא מבטיחים מה שאי אפשר לקיים כרגע.
מה נדרש בצד המוצר
Offline הוא לא רק בעיה של האפליקציה. הקושחה צריכה לאגור מדידות בזיכרון המקומי כשאין חיבור, ולשדר את הצבר בסנכרון הבא — אחרת ההיסטוריה מתמלאת חורים. מוצר עם חיישנים צריך הקצאת זיכרון לאגירה של שעות עד ימים, ופרוטוקול העברה יעיל של נתונים היסטוריים. העיקרון דומה לזה שמתואר במאמר סנכרון נתונים במוצר לביש — לאגור מקומית, לסנכרן בחוכמה.
Offline כהחלטת מוצר: שלוש רמות
לא כל מוצר צריך את אותו עומק תמיכה. הגדירו באפיון לאיזו רמה אתם מכוונים:
- צפייה בלבד — בלי רשת רואים נתונים אחרונים והגדרות, אך לא שולטים. מספיק למוצרי ניטור שהערך שלהם ממילא בענן.
- שליטה מקומית מלאה — כל הפעולות ליד המוצר עובדות בערוץ הישיר; רק היסטוריה ושליטה מרחוק דורשות ענן. הרמה הנכונה לרוב מוצרי הבית החכם.
- אוטונומיה מלאה — המוצר מתפקד לאורך זמן בלי ענן בכלל, כולל אוטומציות מקומיות. נדרש במוצרי בטיחות, חקלאות ותעשייה.
ככל שהרמה גבוהה יותר, המורכבות בקושחה ובסנכרון עולה — אבל איתה גם האמינות הנתפסת של המוצר כולו.
איך בודקים את זה נכון
- מצב טיסה באמצע פעולה — האם האפליקציה מתאוששת או קורסת?
- רשת איטית ומקוטעת (לא רק "אין רשת") — התרחיש הקשה באמת.
- שני מכשירים שעורכים במקביל וחוזרים לרשת יחד.
- ניתוק של שבוע — האם הסנכרון מתמודד עם צבר גדול?
- עדכון גרסת אפליקציה — האם המטמון המקומי שורד את השדרוג, או שהמשתמש מתחיל מאפס?
תרחישים אלה צריכים להיכנס לתוכנית הבדיקות מהתחלה — ראו בדיקות ואיכות באפליקציה.
שורה תחתונה
אפליקציה במצב offline טובה נבנית מהארכיטקטורה, לא נתפרת בסוף: ערוץ מקומי לפעולות ליד המוצר, אחסון מקומי, תור סנכרון ומדיניות קונפליקטים. מוצר שממשיך לתפקד בלי אינטרנט משדר אמינות — וזה בדיוק מה שמבדיל מוצר חכם טוב ממוצר שמחזירים לחנות.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
