לאחרונה פנה אלינו לקוח עם בעיה: באפליקציית משלוחי המזון שלהם, מסך היסטוריית ההזמנות לא היה יציב. בהפעלה קרה, התראה push פתחה עמוד ריק, וגלילה מהירה גרמה לכפילויות בהזמנות. פתרנו זאת עם פאג'ינציה מבוססת cursor, התראות WebSocket וטיפול נכון ב-deep link. הסטאק של הלקוח: React Native + TypeScript, backend על Node.js עם GraphQL. במאמר זה, אנו מפרקים את ההחלטות הארכיטקטוניות המרכזיות שהפחיתו את זמן טעינת המסך ב-80% וביטלו כפילויות. אנו גם מכסים עדכוני סטטוס בזמן אמת וטיפול ב-deep link בהפעלה קרה. עלות פיתוח מסך היסטוריית הזמנות מחושבת באופן פרטני לפי אינטגרציות, והחיסכון בקיבולת שרת באמצעות caching יכול להיות משמעותי.
פאג'ינציה וטעינה
פאג'ינציה מבוססת cursor עדיפה על offset עבור היסטוריית הזמנות: כשהמשתמש גולל למטה, פריטים חדשים מתווספים מבלי להזיז את כל הרשימה. ב-React Native, השתמשו ב-FlatList עם onEndReached (מופעל ב-onEndReachedThreshold * viewport לפני הסוף). טעות נפוצה: onEndReached מופעל מספר פעמים בגלילה מהירה. הפתרון הוא דגל isLoadingMore עם בדיקה לפני הבקשה. לפי מסמכי React Native, ScrollController מוגדר בדרך כלל ל-0.5–1.0.
ב-Flutter, השתמשו ב-addListener עם position.pixels >= position.maxScrollExtent - 200, ובדקו ListView.builder. לחלופין, itemCount: items.length + (hasMore ? 1 : 0) עם CircularProgressIndicator—הפריט האחרון מציג @Dao.
| גישה | כפילויות | ביצועים | מורכבות יישום |
|---|---|---|---|
| Offset | אפשריות | מתדרדר ב-offsets גדולים | נמוכה |
| מבוסס Cursor | מבוטלות | יציב בכל נפח | בינונית |
Caching. 20–30 ההזמנות הראשונות נשמרות מקומית—המשתמש רואה אותן מיד בפתיחה הבאה בזמן שרענון רקע מתבצע. ב-Android, Room עם שאילתת socket.io-client לפי userId, ממוין לפי תאריך. ב-React Native, MMKV ל-IO מהיר (פי 10 מהיר יותר מ-AsyncStorage בנפחים גדולים). Caching מקצר את זמן טעינת המסך ב-80% ומפחית בקשות לשרת ב-30%.
איך ליישם עדכוני סטטוס בזמן אמת?
סטטוס "בדרך" חייב להתעדכן מבלי לטעון מחדש את האפליקציה. שלוש גישות:
- WebSocket—
web_socket_channelב-React Native אוuseEffectב-Flutter. הירשמו לערוץ עבור הזמנה ספציפית לפי ה-ID שלה. - Server-Sent Events—פשוט יותר מ-WebSocket לעדכונים חד-כיווניים.
- Polling—כל 30–60 שניות אם WebSocket לא זמין. דרך
setInterval+Timer.periodicב-React Native,Timer.periodicב-Flutter.
| שיטה | השהיה | מורכבות | צריכת סוללה |
|---|---|---|---|
| WebSocket | <100ms | בינונית | נמוכה |
| SSE | <200ms | נמוכה | נמוכה |
| Polling | 30-60s | מינימלית | גבוהה |
מניסיון: אפליקציית משלוחי מזון, iOS Swift + UIKit. מסך היסטוריית ההזמנות נפתח מהתראה push והציג פרטים נכון—אבל רק אם האפליקציה כבר רצה. בהפעלה קרה, מסך הפרטים נפתח ריק. הסיבה: ה-deep link טופל לפני שתהליך ההתחברות הושלם. הוספנו תור של deep links ממתינים—לאחר התחברות מוצלחת, הניווט בוצע מהתור.
מסך פרטי הזמנה
פרטי ההזמנה כוללים: רשימת פריטים עם תמונות וכמויות, כתובת משלוח, פרטי שליח (שם, טלפון, תמונה), מפה עם מעקב, סכום כולל עם פירוט.
מפה עם מעקב היא מורכבות נפרדת. MapKit (iOS) / Google Maps SDK (Android) / flutter_map (Flutter). סמן השליח מתעדכן דרך WebSocket. קו מסלול דרך Directions API. זה מוסיף לפחות 1–2 ימים נוספים.
כפתור "הזמנה חוזרת" מוסיף את כל הפריטים לעגלה עם בדיקות זמינות. פריטים לא זמינים מדווחים למשתמש בנפרד, לא מדלגים עליהם בשקט.
למה פאג'ינציה מבוססת Cursor עדיפה לאפליקציות מובייל?
פאג'ינציה מבוססת Offset סובלת מכפילויות ופערים כשמוכנסות רשומות חדשות. מבוססת Cursor פותרת זאת באמצעות מזהה ייחודי של הפריט האחרון. המהנדסים שלנו מיישמים גישה זו בכל הפרויקטים—היא מפחיתה בקשות חוזרות ב-30% ומשפרת את חוויית המשתמש עם טעינה חלקה.
איך אנו מיישמים מסך היסטוריית הזמנות: שלב אחר שלב
- ניתוח דרישות ועיצוב API עם פאג'ינציה מבוססת cursor.
- יישום רשימה עם טעינה המופעלת בגלילה (FlatList / ListView).
- אינטגרציית WebSocket לעדכוני סטטוס בזמן אמת.
- Caching מקומי (Room/MMKV) למצב לא מקוון.
- טיפול ב-deep link עם תור בהפעלה קרה.
- בדיקות על מכשירים עם 3 GB RAM ורשת איטית.
רשימת בדיקה של טעויות נפוצות
- אי הגדרת דגל isLoadingMore—גורם לבקשות מרובות.
- שכחת תור deep link בהפעלה קרה—המשתמש רואה מסך ריק.
- שימוש בפאג'ינציה מבוססת offset על נתונים דינמיים—כפילויות ופערים.
- אי caching של העמודים הראשונים—טעינה ארוכה בחיבורים חלשים.
מה כלול בעבודה
- רשימת הזמנות עם פאג'ינציה מבוססת cursor
- כרטיס הזמנה: מספר, תאריך, סטטוס, סכום, תצוגה מקדימה של פריטים
- מסך פרטי הזמנה עם הרכב מלא וציר זמן סטטוסים
- סינון לפי סטטוס (פעיל / הושלם / בוטל)
- Caching של הזמנות אחרונות למצב לא מקוון
- כפתור "הזמנה חוזרת"
- תמיכה ב-deep link לפתיחת הזמנה ספציפית מהתראה push
לוח זמנים ועלות
2–3 ימי עסקים—רשימה עם פרטים וסטטוסים. עם מעקב שליח בזמן אמת על מפה, הוסיפו 1–2 ימים. העלות מחושבת באופן פרטני לפי מורכבות האינטגרציה. הפתרונות שלנו יכולים להפחית עלויות תשתית שרת בעד 40% באמצעות caching יעיל. צרו קשר לייעוץ על אינטגרציה—נציע ארכיטקטורה לסטאק שלכם. הזמינו פיתוח מסך היסטוריית הזמנות מהמהנדסים שלנו עם ניסיון בשירות לקוחות עם למעלה ממיליון משתמשים. אנו מבטיחים איכות גבוהה ומסירה בזמן. קבלו ייעוץ עוד היום!