פיתוח אפליקציה לסמארטפון – מה חשוב?

16.12.2012

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

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

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

עיצוב גראפי חשוב שיעשה ע"י חברה בעלת נסיון מוכח בתחום זה. בהיבט זה חשוב להתאים את סוג העיצוב למכשיר, למשל באפליקציית אנדרואיד לא מקובל ליישם באר תחתון אלא Action bar  . בנוסף, באפליקצית אנדרואיד, אין צורך לממש את כפתור ה back שהוא מובנה בפלטפורמת אנדרואיד. בנוסף צריך לתת את הדעת אם יש לעצב את האפליקציה בצורה שונה לטאבלטים (למשל אייפאד) שבהם שטח המסך גדול משמעותית מגודל הסמארטפון.

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

תהליך הבדיקות: יש להגדיר מהו תהליך הבדיקות הנדרש: האם הבדיקות כוללות unit test – בדיקות של התוכניתן בלבד ו בדיקות מערכת הנקראות system test. פחות רצוי שמפתח האפליקציה יהיה היחיד שיבדוק את האפליקציה. לעיתים החברה שמזמינה את האפליקציה מעדיפה לבצע את ה system test  בעצמן.

קוד המקור: קוד המקור(source code)  צריך להיות מסופק ללקוח בסיום הפרוייקט. בגופים בעלי יכולת טכנולוגית מתאימה, בונים את האפליקציה (מקמפלים אותה) לפני שיחרור האפליקציה לאפסאור, Google Play, Windows store. בדרך זאת ניתן לוודא שכל עדכוני התוכנה נכללים בקוד המקור שסופק.

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

מימוש פתרון של Push Notification , צריך להיות ברור באיזה תשתית ממשים את פיתוח הודעות הפוש בשרת. האם משתמשים בפתרון של צד ג' שכרוך בתשלום לצורך שליחת ההודעות כדוגמת Urban Airship. במקרה זה משתמשים במנגנון אחיד לכל הפלטפורמות.  או בפיתוח של 3 מנגננונים שונים ללכל פלטפורמה: אפל, גוגל ווינדוס 8.

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

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

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

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

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