פיתוח אפליקציה לנייד לטיפוס

למה אפליקציית טיפוס נשברת על סלע אמיתי

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשרויות מימוש: נייטיב, חוצה-פלטפורמות, היברידי

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

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

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

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

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

שלבי פיתוח אפליקציה לטיפוס

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

1. ניתוח תרחישים על הסלע. יוצאים לשטח: איך מחפשים מסלול, מסמנים העפלה, נעזרים בסכימה. מתעדים אילו פעולות חייבות לעבוד ללא רשת.
2. סכימת נתונים. מה נשמר במכשיר, מה בשרת, איך ממוספרות הרשומות ואיך מיושבים קונפליקטים בין מכשירים.
3. אב-טיפוס לניווט. בודקים על המסלול: כמה מגעים עד לסימון ההעפלה, האם הסכימה קריאה בכפפה.
4. מימוש הליבה האופליין. אחסון מקומי, תור שינויים, שליחה מושהית לשרת.
5. סנכרון בחזרה לקליטה. חושבים מראש על ניתוק באמצע, כניסה חוזרת והחלפת מכשיר, ולא רק על התרחיש השגרתי.
6. ניסויים בשדה. יציאות אמיתיות: אות חלש, סוללה ריקה, גשם וקור בעמדה.
7. מסירה ותמיכה. מוסרים קוד מקור, תיעוד לסכימת הנתונים וסדר העדכונים.

מפות, חיישנים ואחסון אופליין: איך זה בנוי

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

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

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

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

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

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

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

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

מה הלקוח מקבל לידיו לאחר מסירת הפרויקט

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

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

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

במה שונה מצב אופליין ממטמון בזמן אמת?

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

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

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

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

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

מקרה בוחן: איך גדל שיעור המסלולים שהוקלטו

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

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

מה הראו המדדים

• שיעור המסלולים שאבדו: 17% → 1.8%;
• זמן סנכרון הסשן לאחר החזרה לרשת: ~40 שנ' → 4–6 שנ';
• צריכת סוללה בהעפלה של ארבע שעות: 34% → 11%;
• שיעור הסשנים שהתחילו והגיעו למסלול שמור: 62% → 94%.

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

ספקות טכניים לפני תחילת העבודה

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

עד כמה מדויק הסימון על המסלול?

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

תחברו את האפליקציה לשירותים שלנו?

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

מה עם תמיכה במכשירים ישנים?

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

ממה מורכב היקף התמיכה?

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

נדון במשימה שלכם ונחזור עם תוכנית

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

תארו את המשימה בצורה חופשית — מה כבר קיים ומה חסר:

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

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