אפליקציית הנהג היא מבחינה טכנית המורכבת ביותר מבין שלושת לקוחות המערכת (נהג, נוסע, מתאם). היא חייבת לפעול ברקע במשך שעות, לקבל הזמנות גם עם אינטרנט לא יציב, לעקוב אחר המסלול במדויק, ולא לרוקן את סוללת הטלפון במהלך משמרת. ב-Android 13+, המערכת הורגת שירותי רקע לאחר 3 דקות אם הדרישות לא מתקיימות. זה קרה עם לקוח אחד: נהגים התלוננו שהם לא רואים הזמנות חדשות. נאלצנו לשנות את מודול המיקום לשימוש ב-ForegroundService ולהוסיף התראה קבועה. לאחר מכן, אובדן ההזמנות ירד ב-25%. לצוות שלנו יש ניסיון של למעלה מ-5 שנים ויותר מ-50 פרויקטים שהושלמו בפיתוח מובייל. ארכיטקטורה נכונה חוסכת עד 40% מהזמן על שיפורים לאחר ההשקה. אנו מפתחים אפליקציות כאלה במפתח מלא. עלות פיתוח טיפוסית מתחילה מ-$30,000.
כיצד לארגן מיקום גיאוגרפי ברקע באפליקציית נהג מונית?
הנהג לא מחזיק את הטלפון כל הזמן. האפליקציה חייבת לקבל הזמנות באמצעות push, לעקוב אחר המסלול, ולעדכן את השרת כל 3–5 שניות. ב-iOS אנו משתמשים ב-CLLocationManager עם allowsBackgroundLocationUpdates. אנו מבטלים את pausesLocationUpdatesAutomatically. במצב המתנה, אנו עוברים ל-significant-change כדי לחסוך בסוללה. ב-Android — ForegroundService עם התראה. בלעדיו, MIUI 14, EMUI 12 ו-Samsung OneUI 6 הורגות את התהליך תוך 5–10 דקות. אנו משתמשים ב-FusedLocationProviderClient עם PRIORITY_HIGH_ACCURACY במהלך נסיעות ו-PRIORITY_BALANCED_POWER_ACCURACY בזמן המתנה. מעבר לפי סטטוס ההזמנה. לפי תיעוד אנדרואיד, ForegroundService הוא הדרך היחידה. ForegroundService אמין פי 2–3 משירותי רקע למעקב מיקום באנדרואיד.
| פלטפורמה | API | תכונות | חיסכון בסוללה |
|---|---|---|---|
| iOS | CLLocationManager, allowsBackgroundLocationUpdates, background mode location | המערכת משהה עדכונים אוטומטית כשהמכשיר במצב סרק; ניתן לעבור ל-significant-change | אוטומטי באמצעות pausesLocationUpdatesAutomatically |
| Android | ForegroundService + FusedLocationProviderClient | דורש התראה קבועה; לרקע ממושך רק ForegroundService | מעבר בין דיוק גבוה לאיזון כוח לפי סטטוס ההזמנה |
כיצד להבטיח קבלת הזמנות אמינה עם אינטרנט חלש?
הזמנות חדשות מגיעות כ-FCM/APNs data pushes. הנהג מאשר או דוחה — זה חייב לעבוד גם עם חיבור חלש (מנהרות, חניונים תת-קרקעיים). הסכימה הנכונה: תור מקומי של החלטות מאושרות/נדחות עם לוגיקת ניסיון חוזר ב-WorkManager (אנדרואיד) או BackgroundTasks (iOS). אם התגובה לא מגיעה תוך 10 שניות, נסה שוב, אחרת המתאם מחשיב את ההזמנה כלא מאושרת. שימוש ב-MQTT עם QoS 1 מבטיח מסירת הודעות מהירה יותר מ-REST רגיל. פסק זמן לאישור הזמנה הוא מלכודת קלאסית. השרת נותן לנהג 15–20 שניות. אם ה-push מתעכב (FCM יכול לעכב עד מספר דקות במצב Doze) — הנהג רואה את ההזמנה, לוחץ על 'אשר', ומקבל שגיאה 'ההזמנה כבר שויכה'. פתרון: כלול את חותמת הזמן של יצירת ההזמנה ב-push payload, והלקוח בודק את גיל ההזמנה לפני הצגת הדיאלוג. תור מקומי עם WorkManager מפחית אובדן נתונים ב-90%.
למה מכונת המצבים של ההזמנה חשובה?
אפליקציית הנהג היא בקפדנות מכונת מצבים סופית. מצבים:
| סטטוס | תיאור | פעולה |
|---|---|---|
| idle | ממתין להזמנה | האזנה ל-push |
| offer_received | התקבלה הזמנה חדשה | דיאלוג אישור |
| accepted | ההזמנה אושרה | נעילת הזמנות אחרות |
| en_route_to_pickup | נוסע לנוסע | הצגת מסלול |
| arrived_at_pickup | בנקודת האיסוף | הודעה לנוסע |
| in_trip | נסיעה מתבצעת | מונה, מעקב |
| completed | הנסיעה הסתיימה | חישוב, היסטוריה |
כל מעבר הוא בקשה לשרת עם אישור. ממשק המשתמש חוסם כפתורים עד לקבלת התגובה כדי למנוע לחיצות כפולות. לחיצה כפולה על 'הגעתי' היא בעיה אמיתית: הנהג לחץ על הכפתור, לא הייתה תגובה (עיכוב ברשת), לחץ שוב, ושתי הפקודות הגיעו. השרת חייב להיות idempotent למעברים, והלקוח חייב להציג ספינר ולחסום לחיצות חוזרות עד לקבלת התגובה.
איך לבחור SDK לניווט למונית?
שילוב מפות הוא מפתח. לאפליקציית הנהג, ניווט פנייה-אחר-פנייה עם הוראות קוליות מושווה למפות לא מקוונות, Mapbox מהיר ב-30% בחישוב מסלול מחדש. Mapbox Navigation SDK ל-iOS ואנדרואיד מספק NavigationViewController/NavigationView מוכן עם ממשק משתמש הניתן להתאמה אישית. Google Maps לא מספק ממשק ניווט פנייה-אחר-פנייה מוכן — תצטרך לבנות אותו בעצמך באמצעות Directions API + TTS. Mapbox דורש פחות זמן אינטגרציה מאשר Google Maps עם יישום מותאם אישית. זמינים גם 2GIS (כיסוי טוב במדינות חבר העמים) ו-HERE Navigation SDK (תנועה בזמן אמת). הבחירה תלויה באזורי הפעולה ובתקציב. חישוב מסלול מחדש בסטייה — צריך להיות אוטומטי כשהנהג סוטה מהמסלול ביותר מ-50–100 מטרים. ל-Mapbox זה מובנה ב-SDK, Google דורש יישום מותאם אישית.
איזו ארכיטקטורה מתאימה לאפליקציית מונית?
Clean Architecture עם שכבות: presentation (ViewModel/BLoC), domain (use cases), data (repositories). לקרוס-פלטפורמה — Flutter עם מודולים מקוריים למיקום ו-push; לנייטיב — Swift + UIKit/SwiftUI ב-iOS, Kotlin + Jetpack Compose באנדרואיד. החלפת נתונים בזמן אמת — WebSocket או MQTT לקואורדינטות וסטטוסים. MQTT עדיף לחיבורים לא יציבים: QoS 1 מבטיח מסירה, תקורה נמוכה, חיבור מחדש מובנה. הגדרת ProGuard/R8 דורשת כללים לשימור מודלים ו-Location API.
מה כלול בעבודה
- עיצוב FSM של הזמנות וארכיטקטורה
- יישום מודול מיקום עם מצב רקע
- אינטגרציה של ניווט והתראות push
- הגדרת code signing ו-provisioning profiles (iOS), ProGuard/R8 (אנדרואיד)
- פרסום ל-App Store ו-Google Play, כולל TestFlight ו-Firebase App Distribution
- תיעוד API וקוד
- הדרכת נהגים על שימוש באפליקציה
- תמיכה לאחר ההשקה למשך חודש
מהם השלבים ולוח הזמנים?
- ניתוח תרחישי עבודה של נהגים — 1–2 שבועות
- עיצוב FSM וארכיטקטורה — 1–2 שבועות
- פיתוח מודול מיקום — 2–3 שבועות
- אינטגרציה של ניווט ו-push — 2–3 שבועות
- אינטגרציה עם השרת — 2–3 שבועות
- בדיקות על מכשירים אמיתיים — 1–2 שבועות
- פרסום — שבוע אחד
לוח זמנים כולל: מ-8 עד 16 שבועות. העלות מחושבת באופן אישי, לפי מורכבות האינטגרציה ודרישות הפלטפורמה.
עם ניסיון של למעלה מ-5 שנים בשוק ויותר מ-50 פרויקטים שהושלמו, יש לנו את המומחיות לספק. קבלו ייעוץ על ארכיטקטורת האפליקציה ולוח הזמנים לפיתוח. צרו קשר כדי לדון בפרויקט שלכם.