פיתוח אפליקציית מובייל לשירותי שטח עם סנכרון אופליין
טכנאי שטח מגיע לאתר הלקוח, פותח את האפליקציה—ורואה מסך לבן כי אין רשת סלולרית. כרטיס התיקון, היסטוריית הציוד, רשימת הבדיקות—הכל קפוא. במשך 5 שנים, פיתחנו 20+ פתרונות לשירותי שטח שבהם מצב אופליין הוא דרישת בסיס. אבל זה לא רק על היעדר אינטרנט. שגיאות סנכרון, תמונות שאבדו, חתימות בלתי קריאות—כל אחת מהבעיות הללו פוגעת ב-SLA ופוגעת במוניטין. פיתוח אפליקציית מובייל לשירותי שטח עם סנכרון אופליין דורש הבנה עמוקה של הפרטים הספציפיים של עבודת השטח.
מדוע אפליקציית מובייל לשירותי שטח צריכה סנכרון אופליין?
ארכיטקטורת אופליין-פירסט מתוכננת היטב מפחיתה את זמן סגירת הכרטיס ב-30–40% ומקצצת בעלויות נתוני המובייל. החיסכון נובע מסנכרון נתונים רק כאשר יש רשת, במקום כל הזמן. לדוגמה, טכנאי המטפל ב-10–15 כרטיסים יומיים יכול לחסוך עד שעתיים ביום.
כיצד ליישם סנכרון אופליין באפליקציית שירותי שטח?
לסנכרון דו-כיווני, אנו משתמשים במסד נתונים מקומי (SQLite דרך Room או CoreData) ותור סנכרון. פעולות המשתמש נשמרות מקומית; כאשר מופיעה רשת, הנתונים נשלחים לשרת. קונפליקטים של גרסאות הם הנקודה הכואבת ביותר. אם שני טכנאים סוגרים את אותו כרטיס במצב אופליין, יש צורך באסטרטגיית מיזוג. בדרך כלל אנו משתמשים ב-כתיבה אחרונה מנצחת עם יומן פעולות או CRDTs עבור סוגי נתונים מסוימים (למשל, תגובות—הוספה בלבד). גישה זו מהירה פי 10 מהעלאה ישירה ב-HTTP—הטכנאי לא ממתין לתגובת השרת. למידע נוסף על CRDT. בפרויקט אחד, קיצרנו את זמן ההמתנה מ-30 שניות לפחות משנייה אחת.
דוגמה לפתרון קונפליקט סנכרון
שני טכנאים שינו בו-זמנית את הסטטוס של אותו כרטיס. אחד הגדיר אותו כ"בתהליך", השני כ"הושלם". האסטרטגיה שלנו: עדיפות לפי גרסת נתונים (כתיבה אחרונה מנצחת), הקונפליקט נרשם ביומן נפרד. המוקדן בממשק האינטרנט רואה את הפער ויכול לפתור ידנית או לקבל את ההחלטה האוטומטית.אילו בעיות טכניות פותרת אפליקציית מובייל לשירותי שטח?
תמונות ומדיה
דוח סיום עבודה דורש תמונות "לפני" ו"אחרי". באנדרואיד, WorkManager עם Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED) היא הדרך הסטנדרטית להעלאה דחויה. אבל הנה הניואנס: WorkManager אינו מבטיח סדר משימות במהלך העלאה בקבוצות. אם סדר התמונות חשוב—אנו ממספרים אותן בשם הקובץ ואוכפים סדר בשרת. כדי לחסוך בתעבורה, אנו דוחסים תמונות ל-720p—גודל ממוצע של 150 KB במקום 3 MB. במהלך יום, טכנאי מעלה עד 50 תמונות—חיסכון של כ-150 MB למכשיר. WorkManager הוא מימוש רשמי של תור משימות.
חתימה על המסך
Canvas API (אנדרואיד View.onDraw עם Path, iOS UIBezierPath דרך CAShapeLayer) ללכידת חתימות לקוחות הוא פשוט—עד שצריך ייצוא PDF באיכות גבוהה. אנו משתמשים ב-iText (אנדרואיד) או PDFKit (iOS) כדי ליצור את הדוח ישירות במכשיר. החתימה נשמרת כנתיב וקטורי—זה תופס פי 100 פחות מקום מתמונת רסטר ומתאים להדפסה בצורה מושלמת.
כיצד לייעל מסלולים ל-10–15 כרטיסים ביום
המוקדן רואה את כל טכנאי השטח על מפה בזמן אמת דרך WebSocket או MQTT מברוקר (mosquitto / EMQX) ללקוח הנייד. אנו שולחים קואורדינטות בקבוצות כל 30 שניות באמצעות FusedLocationProviderClient (אנדרואיד) או CLLocationManager עם desiredAccuracy: kCLLocationAccuracyNearestTenMeters (iOS)—לא כל שנייה, כדי לחסוך בסוללה. עם גישה זו, הטלפון מחזיק מעמד יום עבודה מלא (10–12 שעות). חיסכון בדלק מייעול מסלולים יכול להגיע ל-25% עבור צוות של 10 טכנאים.
ניתוב אופטימלי בין 10–15 כרטיסים יומיים הוא בעיית הסוכן הנוסע, שאינה נפתרת בלקוח הנייד. השרת (Google OR-Tools, Vroom) מחשב את האופטימיזציה; האפליקציה הניידת רק מציגה את המסלול דרך Google Maps SDK או MapKit עם ניווט פנייה-אחר-פנייה דרך קישור עמוק ל-Maps/Google Maps. דף המסלול נוצר אוטומטית על בסיס האופטימיזציה. בפרויקט אחד, זה הפחית את הקילומטראז' ב-25% ושחרר שעתיים מזמן הטכנאי ביום.
ערימת טכנולוגיות וארכיטקטורה
עבור אפליקציות שירותי שטח עם קוד בסיס יחיד ל-iOS ואנדרואיד, אנו בוחרים ב-Flutter או React Native עם Expo. Flutter מועדף כאשר נדרשים ווידג'טים מותאמים אישית (טופס בדיקה מותאם, גרירה ושחרור לפריטי שורה). React Native—אם צוות הלקוח יתחזק את הקוד ויש לו רקע ב-JavaScript.
ארכיטקטורה: MVVM + תבנית Repository. מסד נתונים מקומי—SQLite (sqflite עבור Flutter, Room עבור אנדרואיד מקורי). שכבת הסנכרון היא שירות נפרד, שאינו מעורב בלוגיקה העסקית.
| קריטריון | Flutter | React Native |
|---|---|---|
| שימוש חוזר בקוד | 95% | 80% |
| ביצועים | גבוהים (Impeller) | בינוניים (Hermes) |
| ווידג'טים מותאמים אישית | מצוינים | מספקים |
| רקע הצוות | Dart | JavaScript/TypeScript |
השוואת אסטרטגיות אופליין:
| אסטרטגיה | יישום |
|---|---|
| SQLite + כתיבה אחרונה מנצחת | כרטיסים, סטטוסי משימות |
| CRDT (הוספה בלבד) | תגובות, יומן פעולות |
| WorkManager + תור | תמונות, חתימות |
מה כלול (תוצרים)
- תיעוד מפורט: מודל נתונים אופליין, אסטרטגיית סנכרון, מפרט API.
- קוד מקור עם הערות ו-CI/CD (GitHub Actions / GitLab CI).
- הגדרת MDM להפצת אפליקציות ארגוניות.
- הכנת חומרים שיווקיים עבור App Store ו-Google Play.
- הדרכה למנהלים וטכנאים (2–3 מפגשים).
- 3 חודשי תמיכה טכנית לאחר השחרור.
המומחיות שלנו
אנו עובדים כבר למעלה מ-5 שנים והשלמנו 22 פרויקטים של שירותי שטח, כולל אפליקציה לתחזוקת מכונות אוטומטיות (200 טכנאים, 8–15 מיקומים ביום). ממוצע NPS בפרויקטים הוא 9.2. אנו משתמשים רק בתוכנה מורשית ו-SDK מוסמכים. הצוות שלנו מחזיק בהסמכות ב-AWS, Google Cloud ו-Flutter.
מהניסיון
אחד הלקוחות שלנו, חברת תחזוקת מכונות אוטומטיות, פרס אפליקציה לכ-200 טכנאים, שכל אחד מטפל ב-8–15 מיקומים יומית. הטעות העיקרית בגרסה הראשונה הייתה הפעלת סנכרון על כל פעולת משתמש דרך בקשת HTTP ישירה. ברשתות חלשות, זה גרם לטכנאי להמתין 30 שניות לאחר כל סגירת פריט. שכתבנו את זה לתור פעולות (טבלת SQLite pending_operations + WorkManager)—הטכנאי עובד מיידית, הסנכרון קורה ברקע. תלונות על "האפליקציה איטית" ירדו לאפס. חיסכון בזמן הגיע עד 40% לכל סגירת כרטיס.
שלבים
- ביקורת על המערכת הקיימת (ERP, CRM, מודול שיגור)—אנו מבינים עם מה לסנכרן.
- עיצוב מודל הנתונים האופליין ואסטרטגיית פתרון קונפליקטים.
- עיצוב ממשק משתמש תוך התחשבות בשימוש עם כפפות ובאור שמש בהיר (ניגודיות, כפתורים גדולים).
- פיתוח ואינטגרציה הדרגתית עם הקצה האחורי.
- פיילוט עם קבוצת טכנאים (10–20 אנשים) לפני פריסה מלאה.
- פרסום ב-App Store ו-Google Play עם פרופיל MDM למכשירים ארגוניים.
לוחות הזמנים נעים בין 6 שבועות (אפליקציה פשוטה עם כרטיסים ורשימות בדיקה) ל-4–6 חודשים לפלטפורמה מלאה עם מודול שיגור, ניתוב ואינטגרציה עם ERP. העלות מחושבת בנפרד לאחר ניתוח דרישות. עלויות פרויקט טיפוסיות מתחילות מ-$30,000 ומשתנות לפי מורכבות. קבלו ייעוץ על פיתוח אפליקציית שירותי שטח.