חוויית המפתחים
אחרי שסיפרתי על אפליקציות המיני בפני עצמן, אני רוצה להתמקד בחוויית המפתח בפלטפורמות השונות של האפליקציות הגדולות. פיתוח אפליקציות מיני בכל הפלטפורמות מתבצע בסביבות פיתוח משולבות (IDE) שסופקו בחינם על ידי פלטפורמות הסופר-אפליקציות. יש עוד כמה, אבל אני רוצה להתמקד בארבע הפופולריות ביותר, ובאפליקציה החמישית – אפליקציה מהירה – לצורך השוואה.
סביבת פיתוח משולבת (IDE) מיניאטורית לאפליקציות
בדומה לאפליקציות הסופר, רוב סביבת הפיתוח המשולבות זמינות רק בסינית. חשוב לוודא שאתם מתקינים את הגרסה הסינית ולא את הגרסה האנגלית (או הגרסה לחו'ל) שזמינה לפעמים, כי יכול להיות שהיא לא עדכנית. אם אתם מפתחים של macOS, חשוב לדעת שלא כל סביבת הפיתוח המשולבת (IDE) חתומה, כלומר macOS מסרב להריץ את מנהל ההתקנות. אפשר לעקוף את הבדיקה הזו באחריותך הבלעדית, כפי שמתואר במאמר העזרה של Apple.
פרויקטים בסיסיים של אפליקציות מיני
כדי להתחיל לפתח אפליקציות מיני במהירות, כל ספקי האפליקציות הגדולות מציעים אפליקציות הדגמה שאפשר להוריד ולבדוק באופן מיידי. לפעמים האפליקציות האלה משולבות גם באשפי 'פרויקט חדש' בסביבות הפיתוח השונות.
תהליך הפיתוח
אחרי שמפעילים את סביבת הפיתוח האינטגרטית (IDE) וטעונים או יוצרים אפליקציה מיני (דמו), השלב הראשון הוא תמיד להתחבר. בדרך כלל צריך רק לסרוק קוד QR באפליקציית העל (שבה כבר נכנסתם לחשבון) שנוצר על ידי סביבת הפיתוח המשולבת. רק לעיתים רחוקות צריך להזין סיסמה. אחרי הכניסה לחשבון, סביבת הפיתוח האינטגרטית תזהה את הזהות שלכם ותאפשר לכם להתחיל לתכנת, לנפות באגים, לבדוק ולשלוח את האפליקציה לבדיקה. בהמשך מופיעים צילומי מסך של חמשת סביבת הפיתוח המשולבות שצוינו בפסקה שלמעלה.
כפי שאפשר לראות, הרכיבים הבסיסיים של כל סביבת הפיתוח המשולבת דומים מאוד. תמיד יש לכם עורך קוד שמבוסס על Monaco Editor, אותו פרויקט שמפעיל גם את VS Code. בכל סביבת הפיתוח המשולבת יש מנתח באגים שמבוסס על חזית כלי הפיתוח ל-Chrome עם כמה שינויים. בהמשך נסביר על השינויים האלה (ראו מנתח באגים). סביבת הפיתוח המשולבת בעצמה מיושמת כאפליקציית NW.js או Electron, והסימולטורים בסביבת הפיתוח המשולבת מיושמים בתור תג <webview> של NW.js או תג <webview> של Electron, שמבוססים על תג <webview> של Chromium. אם אתם רוצים לבדוק את הרכיבים הפנימיים של סביבת הפיתוח המשולבת, בדרך כלל תוכלו לעשות זאת באמצעות Chrome DevTools באמצעות מקשי הקיצור Control+Alt+I (או Command+Option+I ב-Mac).
<webview> של Electron.
בדיקה וניפוי באגים בסימולטור ובמכשיר אמיתי
הסימולטור דומה למצב המכשיר ב-Chrome DevTools. אפשר לדמות מכשירים שונים של Android ו-iOS, לשנות את קנה המידה ואת כיוון המכשיר, וגם לדמות מצבי רשת שונים, לחץ זיכרון, אירוע קריאת ברקוד, סיום בלתי צפוי ומצב כהה.
הסימולטור המובנה מספיק כדי לקבל מושג כללי לגבי אופן ההתנהגות של האפליקציה, אבל אי אפשר להחליף אותו בבדיקות במכשיר, כמו באפליקציות אינטרנט רגילות. כדי לבדוק אפליקציית מיני שנמצאת בפיתוח, צריך רק לסרוק את קוד ה-QR. לדוגמה, ב-ByteDance DevTools, סריקת קוד QR שנוצר באופן דינמי על ידי סביבת הפיתוח המשולבת (IDE) במכשיר אמיתי מובילה לגרסה של המיני-אפליקציה שמתארחת בענן, שאפשר לבדוק אותה מיד במכשיר. האופן שבו המערכת של ByteDance פועלת הוא שכתובת ה-URL שמאחורי קוד ה-QR (דוגמה) מפנה לדף מתארח (דוגמה) שמכיל קישורים עם סכמות URI מיוחדות, כמו snssdk1128://, כדי להציג תצוגה מקדימה של האפליקציה המינימלית בסופראפליקציות השונות של ByteDance, כמו Douyin או Toutiao (דוגמה).
ספקים אחרים של אפליקציות סופר לא עוברים דרך דף ביניים, אלא פותחים את התצוגה המקדימה ישירות.
תכונה מעניינת עוד יותר היא ניפוי באגים מרחוק בגרסת טרום-השקה (Preview) בענן. אחרי שסורקים קוד QR מיוחד שנוצר ב-IDE, המיני-אפליקציה נפתחת במכשיר הפיזי, וחלון Chrome DevTools פועל במחשב לצורך ניפוי באגים מרחוק.
כלי לניפוי באגים
ניפוי באגים ב-Elements
חוויית ניפוי הבאגים של האפליקציות המיני היא מוכרת מאוד לכל מי שפעל אי פעם עם כלי הפיתוח של Chrome. עם זאת, יש כמה הבדלים חשובים שמאפשרים להתאים את תהליך העבודה לאפליקציות המיני. במקום חלונית הרכיבים של כלי הפיתוח ל-Chrome, בסביבות פיתוח לאפליקציות מיני יש חלונית בהתאמה אישית שמותאמת לדיאלקט הספציפי של HTML. לדוגמה, ב-WeChat הלוח נקרא Wxml, ראשי תיבות של WeiXin Markup Language. ב-Baidu DevTools, הוא נקרא Swan Element. ב-ByteDance DevTools הוא נקרא Bxml. ב-Alipay הוא נקרא AXML, וב-Quick App הוא נקרא פשוט UX. בהמשך ארחיב על שפות הסימון האלה.
<image> באמצעות WeChat DevTools.
רכיבים מותאמים אישית ברקע
בדיקה של WebView במכשיר אמיתי דרך about://inspect/#devices מגלה ש-WeChat DevTools הסתיר את האמת בכוונה. במקום <image> שמוצג ב-WeChat DevTools, מה שאני רואה הוא רכיב מותאם אישית שנקרא <wx-image> עם <div> בתור הצאצא היחיד שלו. חשוב לציין שהרכיב בהתאמה אישית הזה לא משתמש ב-Shadow DOM. מידע נוסף על הרכיבים האלה בהמשך.
<image> באמצעות כלי הפיתוח של WeChat מראה שהוא למעשה רכיב <wx-image> בהתאמה אישית.
ניפוי באגים ב-CSS
הבדל נוסף הוא יחידת האורך החדשה rpx לפסל רספונסיבי בדיאלקטים השונים של CSS (מידע נוסף על היחידות האלה בהמשך). ב-WeChat DevTools נעשה שימוש ביחידות אורך של CSS שאינן תלויות במכשיר, כדי לפתח בצורה אינטואיטיבית יותר למכשירים בגדלים שונים.
200rpx 0) בתצוגה באמצעות WeChat DevTools.
ביקורת ביצועים
הביצועים הם הדבר החשוב ביותר באפליקציות המיני, ולכן לא מפתיע ש-WeChat DevTools וכלים נוספים של DevTools כוללים כלי ביקורת משולב בהשראת Lighthouse. תחומי ההתמקדות בבדיקות הם 'סה"כ', 'ביצועים', 'חוויית משתמש' ו'שיטות מומלצות'. אפשר להתאים אישית את התצוגה של סביבת הפיתוח המשולבת. בצילום המסך שבהמשך, הסתרתי באופן זמני את עורך הקוד כדי לפנות מקום במסך לכלי הביקורת.
זיוף API
במקום לדרוש מהמפתח להגדיר שירות נפרד, התכונה של יצירת מודלים (mocking) לתשובות API היא חלק ישיר מ-WeChat DevTools. באמצעות ממשק קל לשימוש, המפתח יכול להגדיר נקודות קצה של API ותשובות מדומה (mock) רצויות.
תודות
הבדיקה של המאמר בוצעה על ידי Joe Medley, Kayce Basques, Milica Mihajlija, Alan Kent ו-Keith Gu.