הבאזז הגדול הבא אחרי הענן: Mobile

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

מקור: flickr, cc-by Annie Mole

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

יחי המובייל!

“ה-PC מת” – מצהירים עיתונים, בפעם המי-יודע-כמה, “יחי הטאבלט!”. בהתחלה זו נשמעה כמו עוד המולה מהסוג שמשתלם לעיתונאים ולאנשי שיווק לייצר. מצד שני נראה שמשהו באמת השתנה: לחצי מהאמריקאים יש כיום סמארטפון (מקור) ושליש מהם גולשים בו באופן קבוע, הנתונים משפיעים על הפרסום והמכירות, כמובן (מקור). רק להבהיר: אני לא מאמין שה-PC יעלם בשנים הקרובות, אך בהחלט ייתכן שיהיה יותר שימוש בטאבלטים מאשר ב-PC תוך שנים בודדות.

הכניסה של מחשבי הטאבלט משפיעה לא רק על אתרי אינטרנט המוכרים לצרכן הסופי, אלא גם יותר ויותר על אפליקציות ארגוניות. זה התחיל ברופאים שזקוקים למידע “on the move”, המשיך בחברות תעופה ומשם המשיך לכלל התעשיה. כל ספק אפליקציה ארגונית רוצה כיום לומר “כן, בטח! יש לנו גם גרסת mobile”.

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

מהכרותי עם מערכות ה-Enterprise הגדולות, נראה לי שיש פה הזדמנות פז! מערכות ה-Enterprise כוללות עשרות, מאות ולפעמים אלפי מסכים מלאי פונקציות. כבר שנים שחברות ה-Enterprise רוצות לשפר את ה-UI המיושן ולהתקדם לטכנולוגיות חדשות יותר (“היי, יש כבר HTML 4!”). המאמץ לשכתב את כל אותם מסכים שנוצרו במשך שנים הוא פשוט גדול-מדי בכדי לקרות.

במשך השנים ניסו אירגוני ה-Enterprise כל מיני גישות: ממירים אוטומטיים מ-UI ישן ל-UI מחודש (כשלון), ייצור כלי פיתוח ל-UI שיאפשרו ליצור מסכים חדשים בטכנולוגיה העכשווית ברבע מהזמן – לרוב לקח פי-2 ויצר המון באגים, או לכתוב UI בשפה גנרית, כך שכל כמה שנים יהיה אפשר לבצע לו Rendering לטכנולוגיות ה-UI החדשה ביותר – פתרון מאותגר-הצלחה. כל אלה היו דרכים לנסות ולהתמודד עם השאלה “כיצד משכתבים את כל ה-UI הזה”.

האם באמת צריך את זה?

אבל אולי בעצם לא צריך לשכתב את “כל” ה-UI. הרי אנו מכירים את כלל הפארטו של הארגונים הגדולים, הידוע ככלל ה-94/6: תשעים וארבעה אחוז מהמשתמשים זקוקים לרק 6 אחוז מהפונקציות של המערכת. “אבל אי-אפשר לצמצם את הפונקציונליות!”, יזעק איש השיווק בדאגה, “אתם לא רוצים להתעסק עם <לקוח של עשרות מליונים> שאוהב דווקא את הכפתור הירוק שעושה משהו מוזר”. נכון, אי-אפשר.

מה נעשה? נשאיר את ה-UI הקיים כפי שהוא: גדול, עמוס מיושן ומסורבל – ומכיל כ”כ הרבה פונקציות.

עבור 6 אחוזים מהמשתמשים נבחר את הפונקציות הנפוצות ביותר – אולי 2-3 אחוזים מכלל המערכת – ולהם נכתוב UI חדש מגניב וקל-מאוד-לשימוש: UI למכשירי Mobile.

כך אנו יכולים להרוג 2 ציפורים במכה:

  • גם לשמח את רוב המשתמשים שמתקשים להשתמש במערכת המסובכת שלנו, ב-UI חדש ופשוט לשימוש.
  • גם לא להודות שה-UI הקיים שלנו – הוא ממש פשע “ה-UI הקיים מצויין ל Power Users”.
  • וגם לצאת מגניבים וחדשנים “הופתעתם איך חברה עם <עשרות אלפי> עובדים ניתרה בקלילות כזו לטרנד חדש? אתם כנראה לא מכירים אותנו!”

כיוונו ל-2 ציפורים ופגענו ב-3. איזו הצלחה!

ומה עם הלקוחות הקיימים ודרישות ה Enterprise הנקודתיות שלהם? “רוצה את הכפתור הירוק? יש לנו. גש ל-UI הישן.”, או “רוצה תמיכה לעיוורים ביפנית ובצורה סופר-מאובטחת? יש לנו. גש ל UI הישן”. כפי שאמרתי – הזדמנות פז!

מקור: BGR

לא רק “מסך קטן”

אם תשאלו אנשים מה ההבדל בין בניית אפליקציה ל-Desktop ול-Mobile, כנראה שהדבר הראשון שתשמעו זה: “צריך לתכנן מחדש את הדף כך שיתאים למסך קטן”. כל זה טוב ויפה, אך המעבר לאפליקציות Mobile הוא יותר ממעבר למסך קטן בעל form-factor שונה. כשיש לנו אתר אינטרנט (או אפליקציה אירגונית) אנו מנסים לאסוף עליה מידע כדי להתאים אותה טוב יותר למשתמשים: מיהם המשתמשים, מה הפונקציות שחשובות להם יותר, מה סדר הפעולות שלהם באפליקציה וכו’.

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

תנאים פיסיים

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

מקור: Google Blog

מיקום וזמן

לרוב מכשירי המובייל כיום יש GPS מובנה, מה שנקרא Geolocation. מדוע המידע הזה כ”כ משנה? חיבור של מיקום + זמן (שרת) = שעה ביום של המשתמש => עוד מידע מעניין על המשתמש. אם אתם מחתברים לרשת בתי מרקחת בלילה ייתכן והפעולות הנפוצות הן לבדוק היכן בית המרקחת התורן או שעות פתיחה של הסניפים מחר בבוקר, בעוד גולש ביום יתעניין יותר בכתובת בית המרקחת הקרוב.

ביצועים

עוד אלמנט חשוב הוא זמן עליית האפליקציה. משתמשי מובייל הם קצרי-רוח אפילו יותר ממשתמשי Desktop, בעוד החומרה העומדת לרשותים היא חלשה משמעותית. בעוד גם מחשב בין 5 שנים (עתיק) מסוגל להריץ יפה את רוב אתרי האינטרנט, יש פער משמעותי ביכולות של מכשירים ניידים בטווח של שנתיים להריץ דפים פשוטים בהרבה. להתאים את עצמכם למכשירים החלשים – זו לא בהכרח הבחירה הנכונה, כי בעלי המכשירים החזקים עלולים להיות מאוכזבים.

אמצעי הצבעה

בניגוד לעכבר שיכול לדייק בטווח של כמה פיקסלים, האצבע האנושית הממוצעת היא בקוטר 7 עד 10 מ”מ, מה שצריך להתרגם לאיזור לא-קטן מ-40 עד 80 פיקסלים (תלוי במכשיר) – על מנת שיהיה לחיץ בצורה קלה. תשכחו גם מ-Hover Effects – משתמשי מובייל לא ישוטטו עם האצבע על המסך. מצד שני יש את המחוות (Gestures) שמאוד טבעי לבצע בעזרת אצבע אך קשה בעזרת עכבר.

אז איך מפתחים אפליקציית מובייל?

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

אם תכוונו ל-iOs ו-Android בלבד, תצטרכו לכתוב בשתי שפות תכנות שונות (Objective C ל-iOS ו-Java או ++C ל-Android) על סביבות פיתוח בעלות ספריות שונות מהותית ותגיעו לכ-70 אחוזים מהשוק (נכון לזמן כתיבת הפוסט). משהו מרגיז מאוד הוא ששתי סביבות הפיתוח (IDE) הקיימות ל-iOS, כלומר XCode ו-AppCode, רצות רק על Mac ובתור משתמשי PC תאלצו לקנות מק או להריץ MacOS בתוך VM. לא דיברנו עוד על טאבלטים ועל השוני בין גרסאות שונות של מערכות ההפעלה הניידות – שמסבכות את הסיפור. במיוחד כאשר גרסא חדשה יוצאת כל שני וחמישי.

ב-iOS ובאנדרואיד תוכלו להורות לדפדפן להריץ את אפליקציית האינטרנט ב”Full Screen” בעזרת תגית META ” name=”apple-mobile-web-app-capable, הנתמכת אגב גם ע”י אנדרואיד, כך שלא יראו בכלל את הדפדפן. תוכלו להמשיך ולהוסיף לה Icon במידה והמשתמש שמר אותה על דף הבית של המכשיר ולהגדיר עוד כל מיני התנהגויות שיגרמו לאפליקציה שלכם להרגיש מאוד דומה לאפליקציית נייטיב.

עוד נקודה שכדאי לשים אליה לב היא שסביבות הפיתוח למובייל (בעיקר XCode) נבנו עבור מפתח יחיד. תמיכה בכלי Source Control, תהליך Build מסודר ועוד הן עדיין לא מפותחות בסביבות אלו ומקשות על פיתוח בסביבה של יותר ממפתח אחד. סה”כ ההמלצה עבור אפליקציה “עסקית” (בניגוד למשחקים) היא להתחיל בפיתוח אפליקציית ווב ומעבר לנייטיב ע”פ הצורך [1].

טכנולוגיות ווב

מקור: flickr, cc-by Espen Klem

כאשר מכוונים לאפליקציית ווב יש שתי קונפיגורציות שכדאי להתייחס אליהן: XHTML-MP / HTML 4, CSS 2.1 and JavaScript 1.4 – עבור מכשירים ישנים (לרוב 2009 ואחורה). HTML 5, CSS 3 and Ajax – עבור מכשירים חדשים וחזקים יותר. ה-WML (מין HTML למכשירים ניידים) – למי שזוכר אותו, כבר אינו רלוונטי.

הדפדפנים על מכשירים ניידים, מכשירים בעלי יכולות חלשות, הם לרוב יותר חדשים ומעודכנים מהמחשבים השולחניים. תמיכה ב-HTML5 ו-CSS3 היא נפוצה יותר ממה שאתם מכירים במחשבים שולחניים – בערך כל מכשיר שיצא אחרי 2010 תומך בהם בצורה כזו או אחרת.

איך בודקים את התוצר? יש 3 רמות:

  • הכי קל להריץ את הדפדפן השולחני המקביל בחלון שרוחבו כרוחב מכשיר נייד (320 או 400 פיקסלים וכו’) ומקונפג לדווח על User Agent של מכשיר נייד. בדיקה כזו טובה בעיקר לבדיקה בסיסית של הדף: Layout טיפול ב-events וכו’. זו דרך מהירה וקלה של בדיקה שלא זמינה למי שמפתח אפליקציה נייטיב.
  • קצת יותר מסורבל – אבל יותר מדוייק הוא להריץ אמולטור. מלבד אופרה – כל האחרים (Safari, Chrome, IE) רצים רק ב-VM של מערכת ההפעלה הניידת. תאלצו לחכות עוד כמה שניות עד שה-VM יעלה ותוכן תוכלו לצרוך רק מתוך שרת ווב (Apache, IIS) ולא כקובץ HTML מהדיסק כפי שיכולתם בדפדפן שולחני. כמובן שאפל דורשים Mac OS כדי להריץ את האמולטור שלהם. כמה צפוי! בעזרת האמולטור תוכלו לראות מה עובד באמת ולבדוק gestures והתנהגויות עם מערכת ההפעלה האמיתית. למערכות ההפעלה ניידות יש השפעה רבה יותר על חוויות השימוש בדפדפן מאשר מערכות הפעלה שולחניות.
  • שכבה שלישית היא לבדוק על מכשיר אמיתי – יש דברים שתגלו רק כאן. לדוגמא: אמולטור ירוץ הרבה יותר מהר מאשר המכשיר הנייד עצמו.

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

כמה טיפים לפיתוח אפליקציית ווב למובייל

ראשית, יש שלוש תגיות META שכדאי להכיר, ולשים בכל ראש של דף ווב למובייל:

  • Viewport – הוצג ע”י אפל והפך לסטנדרט דה-פאקטו.
  • Mobile Optimized – הוצג ע”י MS עבור מכשירי Pocket PC למניהם ועדיין נפוץ.
  • Handheld Friendly – עתיק, יסייע לתמיכה במכשירים עתיקים.

ללא תוויות אלו, המכשיר יניח שדף הווב תוכנן עבור רזולוציה ברוחב 1024 (למשל Windows Mobile) או 800 (למשל אנדרואיד) ויקטין את הדף משמעותית כך שמסך המובייל יציג 1024 פיקסלים לרוחב – אפילו אם במכשיר יש רק 300 פיקסלים לרוחב. התוצאה: פונט בגודל 2 שאינו קריא בכלל. כאן תוכלו למצוא דוגמאות איך להשתמש בהם, וכאן פירוט יותר מקיף מה יקרה אם לא תשתמשו בהם (כולל תופעות לוואי נוספות).

HTML5/CSS3

בתקן של HTML5  יש כמה אלמנטים שיעזרו לאפליקציות מובייל. לתג ה-Input הוסף מאפיין חדש בשם “Type”, כאשר הערכים האפשריים הם תאריך, טלפון, URL, EMAIL וכו’. אם תשתמשו בהם, דפדפני המובייל ידעו לבצע לעיתים אימות ערכים והתאמות שונות. לדוגמא, Safari Mobile יתאים את המקלדת לסוג השדה ויציג את הכפתורים השימושיים, כך שלא תצטרכו לעבור מקלדת עבור הקלדת “@” בכתובת דוא”ל.

עוד שני תקנים חשובים של HTML עבור מובייל הם:

  • HTML 5 local storage – שמירה של מידע על המכשיר בצורה קבועה. יכולת שעד לא מזמן הייתה שמורה לאפליקציות נייטיב. שמירת מידע על המכשיר תחסוך round-trips ושימוש לא-נוח בקוקיז.
  • HTML 5 Geo-location – מתאר מיקום – כפי שתואר למעלה.

עוד סטנדרט חשוב הוא CSS Media Querying – המאפשר למכשיר לקבל קובץ CSS מתאים על פי היכולות שהוא מצהיר שיש ברשותו. כך תוכלו לכתוב אפליקציית ווב פעם אחת ולהתאים אותה פעם אחת לסמארטפון ופעם אחת ל-iPad, רק בעזרת ה-CSS.

עצות שימושיות אחרות

בדפים למכשירי מובייל חשוב להמנע מ-Layouting מיושן מבוסס טבלאות (תגי tr,td) או גרוע מכך – טבלאות מקוננות. גם מ-iFrames כדאי להמנע בצורה גורפת – על מנת להמנע מהפתעות לא נעימות למשתמש. אם אתם שואלים את עצמכם ״אז איך לעזאזל אני אמור לסדר את הדף״ – לכו ללמוד על CSS ותגיות DIV – ומהר! :)

מקור: flickr, cc-by Tsahi Levent-Levi

ספריות שכדאי להכיר הן:

Modernizr – שעוזרת לזהות את יכולות הדפדפן (למשל תמיכה ב-HTML5 local Storage או פענוח קבצי SVG). הזיהוי מתבצע ב-JavaScript = בצד הלקוח. זיהוי בצד השרת ע”פ User Agent הוא חלקי מאוד ולא אמין.

jQuery Mobile – הכוללת סט Widget, אפקטים ויכולות Theme המותאמות למובייל. ספריה רזה ויעילה!

מקורות חשובים אחרים:

Boilerplate – תבנית לפרוייקטי HTML5 למובייל. התבנית בנויה שתחסוך בעיות שונות עם מכשירים ומצבים שונים. כדאי פשוט מאוד לקרוא את ההערות בגוף ה-HTML וה-CSS – ניתן ללמוד מהן הרבה!

W3C Mobile Best Practices – מסמך שבאופן מפתיע אינו ארוך או משעמם, הכולל הרבה המלצות עבור פיתוח במובייל.

[1] בזמן כתיבת הפוסט שמעתי על מחסור משמעותי בישראל במפתחי אנדרואיד נייטיב. איני יודע כמה המידע מדוייק. סיכוי סביר שהדבר נובע מהעובדה שפיתוח ב iOS הוא נוח משמעותית מפיתוח לאנדרואיד.

הפוסט פורסם לראשונה בבלוג אריכטקטורת תוכנה.

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

10 תגובות על "הבאזז הגדול הבא אחרי הענן: Mobile"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
קוקו
Guest

הבעיה, שפיתוח WEB הוא עדיין לא נוח ומסורבל.

נדב
Guest
צר לי, אך חסרים פה ה-מ-ו-ן פרטים, וחלק מהפרטים פשוט מטעים אעבור על חלק: 1. אי אפשר חוקית להריץ OSX בתוך VM 2. הסיבות לבחירת נייטיב/ווב הן רבות ומתאמות לאפליקציה, אך בגדול האינדיקציה בעיקרית לפיה נלך היא הצורך בביצועים (וגם על זה אפשר להתגבר, ראה הערה 3) 3. לא הזכרת כלל את Phonegap, הגשר בין אפליקיית הווב לנייטיב, המאפשרת הפצה בחנויות השונות, גישה מלאה ליכולות המכשיר, והוספת תוספים (וכתיבתם) אשר מוסיפים יכולות לנייטיב (כך למשל אם המקום היחיד בו האפליקציה חייבית ביצועים גבוהים אפשר להעביר את החלק הזה לביצוע בנייטיב) 4. הזכרת במילה אחת את jQueryMobile אך ישנן אלטרנטיבות טובות… Read more »
איל
Guest

כתבה רדודה ושטחית בלי חיבור למציאות.
חוץ מזה, קיימים המון פתרונות נוספים וטובים יותר לבעיות שהוצגו כאן (Senhca Touch, PhoneGap, iScroll, git)..

ליאור
Guest

תודה על ההערות:
1. אזכור תשתיות לכתיבה פעם-אחת והרצה על מספר פלטפורמות באמת חסרה בפוסט. אין לי נסיון בהן. שמעתי על נסיונות לעבוד עם כלי מסוג זה (ספיציפית – appcelerator) שנגמרו באכזבה ומעבר לפיתוח עבור כל פלטפורמה בנפרד – אך זהו איננו מדגם מייצג.
2. לגבי הספריות השונות שהוזכרו – אני מקבל את ההערה. לא ניסיתי לבחון או להשוות ספריות.

גל
Guest

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

שירן
Guest

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

שורה תחתונה – אני בעד הצעצועים האלה.

שירן
Guest

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

שורה תחתונה – אני בעד הצעצועים האלה.

שמואל
Guest

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

איל
Guest

ניתן לפתח Web application שיפעל גם במצב Offline ישירות מהדפדפן ע”י שימוש ב-cache manifest (ו-localStorage) – לאחר טעינה ראשונית של האפליקציה.
בנוסף, ניתן “לארוז” אפליקציה וובית (באמצעות PhoneGap למשל), לדחוף אותה למרקט/אפ-סטור כך שהרבה מאוד מגבלות (כולל זו שציינת) כבר נהיות לא רלוונטיות.

אבי
Guest
מאמר יפה ונגעת בכמה נקודות מאוד חשובות בעולם הUI וחויית המשתמש למרות שאינך בא מתחום ה-UX… אכן לאנשי המקצוע שבנינו יש אתגר לא קטן במציאת הפתרון הנכון ביותר בכל מה שנוגע למולטי-פלאטפורם ולכל גדלי המסכים. רק מה שמטריד אותי בכל המאמרים המתפרסמים כאן זה שלא משנה כמה המאמרים מקצעויים, כנראה שבישראל לא ממש שמעו על AIR של אדובי, שמספקת פתרון כמעט מושלם לפיתוח אפליקציות נייטיב לכל פלאטפורמה אפשרית בזכות פלאטפורמת הAIR של אדובי שמאפשרת ייצוא וקימפול אפליקצייה NATIVE אפילו לIOS, ז”א שבמקום לייצא לSWF שמצריך פלאג-אין לדפדפן (מה שבמובייל הולך ונעלם) אז אנו מסוגלים כעת לייצא את האפליקציה שלנו לכל… Read more »
wpDiscuz

תגיות לכתבה: