שיטות מומלצות

כדי לשפר את החוויה הכוללת של המשתמשים, כדאי לפעול לפי המדריכים האלה לעיצוב תוספים.

שיטות מומלצות כלליות

מומלץ לפעול לפי השיטות המומלצות הבאות בכל התוספים שאתם מפתחים.

קביעת הבעלות על תוסף לפני שמתחילים

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

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

הרחבת המינוי ל-Google Workspace, לא לשכפל אותה

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

צמצום של ההיקפים

כשאתם מגדירים את ההיקפים באופן מפורש, תמיד כדאי לבחור בקבוצת ההיקפים הכי פחות מגבילה שאפשר. לדוגמה, לא לבקש מהתוסף הרשאת גישה מלאה ליומן של המשתמש עם ההיקף https://www.googleapis.com/auth/calendar אם יש לו צורך רק בגישת קריאה. להרשאת קריאה בלבד, צריך להשתמש בהיקף https://www.googleapis.com/auth/calendar.readonly.

מומלץ להימנע משימוש יתר בספריות

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

זמן האחזור שמתואר למעלה חל רק על פרויקטים ב-Apps Script שמשמשים כספריות בצד השרת. תוכלו להשתמש בספריות JavaScript בצד הלקוח כמו jQuery באופן חופשי, בלי לחכות בזמן האחזור הזה.

שיטות מומלצות לשימוש בתוספים ל-Google Workspace

השיטות המומלצות הבאות רלוונטיות רק לתוספים ל-Google Workspace ולשימוש בשירות הכרטיסים.

להשתמש במספר קטן של כרטיסים

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

יש להימנע מהצורך ליצור יותר כרטיסים מהנדרש.

שימוש בפונקציות ליצירת ווידג'טים

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

כרטיסים פשוטים

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

שימוש בכרטיסי שגיאה

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

כתיבת בדיקות והודעות בדיקה

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

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

    Logger.log(response.printJson());

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

צריך להשתמש בנתוני בדיקה שמתאימים לכל אפליקציית מארח שהתוסף מרחיב. לדוגמה, אם התוסף מרחיב את Gmail, סביר להניח שתזדקקו לכמה הודעות אימייל לבדיקה ואת מזהי ההודעות שלהן, כדי לוודא שהתוסף פועל כצפוי כשמזינים תוכן הודעות שונה. אפשר לאתר את מזהה ההודעה של הודעה נתונה על ידי פירוט ההודעות באמצעות method Gmail API Users.messages.list או על ידי שימוש בשירות Gmail של Apps Script.

שיטות מומלצות לשיחות ועידה ביומן

אם התוסף משלב ביומן Google אפשרויות של שיחות ועידה ביומן של צד שלישי, כדאי ליישם את השיטות המומלצות הבאות:

שמירה על onCreateFunction אור

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

שימוש בשדות ConferenceData מתאימים לנתונים של שיחת הוועידה

כשיוצרים אובייקטים ConferenceData, אפשר לאכלס אותם בפרטים על שיחת הוועידה (קודי גישה, מספרי טלפון, קודי אימות, מזהי URI וכו'). הקפידו להשתמש בשדה EntryPoint המתאים למידע הזה. אין להציב את הפרטים האלה בשדה ConferenceData ההערות.

לא להוסיף לאירוע ביומן Google פרטים של שיחת ועידה

אין צורך להוסיף לתיאור האירוע ביומן Google מידע על שיחות ועידה של צד שלישי שנוצרו. יומן Google עושה זאת באופן אוטומטי לפי הצורך.