แนวทางปฏิบัติที่ดี

ปรับปรุงประสบการณ์โดยรวมของผู้ใช้โดยทำตามคำแนะนำเหล่านี้สำหรับการออกแบบส่วนเสริม

แนวทางปฏิบัติแนะนำโดยทั่วไป

เราขอแนะนำให้ใช้แนวทางปฏิบัติแนะนำต่อไปนี้กับส่วนเสริมทั้งหมดที่คุณพัฒนา

ตรวจสอบความเป็นเจ้าของส่วนเสริมก่อนเริ่มต้น

ส่วนเสริมจะกำหนดโดยโปรเจ็กต์ Apps Script ซึ่งต้องเป็นเจ้าของโดยบัญชีที่เฉพาะเจาะจงหรือวางไว้ในไดรฟ์ที่แชร์ ก่อนเขียนโค้ดส่วนเสริม ให้พิจารณาว่าบัญชีใดควรเป็นเจ้าของโปรเจ็กต์ และบัญชีใดจะทำหน้าที่เป็นผู้เผยแพร่ นอกจากนี้ ให้กำหนดบัญชีที่จะทำหน้าที่เป็นผู้ทำงานร่วมกัน และตรวจสอบว่าบัญชีเหล่านั้นมีสิทธิ์เข้าถึงโปรเจ็กต์สคริปต์และโปรเจ็กต์ Google Cloud ที่เชื่อมโยงอยู่

หมายเหตุ: คุณต้องวางแผนการเป็นเจ้าของส่วนเสริม หากเจ้าของส่วนเสริมออกจากองค์กร คุณต้องตรวจสอบว่าได้โอนการเป็นเจ้าของแล้ว ไม่เช่นนั้นคุณอาจอัปเดตและจัดการส่วนเสริมไม่ได้ ด้วยเหตุนี้ คุณจึงควรสร้างบัญชีองค์กรเพื่อเป็นเจ้าของและเผยแพร่ส่วนเสริมขององค์กรโดยเฉพาะ คุณยังใช้ไดรฟ์ที่แชร์เพื่อทำหน้าที่เป็นเจ้าของโปรเจ็กต์สคริปต์ได้ด้วย แต่บัญชีหนึ่งๆ จะต้องทำหน้าที่เป็นผู้เผยแพร่ส่วนเสริม

ขยายการใช้งาน 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 หรือออบเจ็กต์ UI ที่ซับซ้อนอื่นๆ ให้พิจารณาใส่โค้ดนั้นไว้ในฟังก์ชันของตัวเอง ฟังก์ชันการสร้างนี้ควรสร้างออบเจ็กต์และแสดงผล ซึ่งจะช่วยให้คุณสร้างออบเจ็กต์นั้นอีกครั้งได้อย่างรวดเร็วทุกครั้งที่ UI ต้องรีเฟรช อย่าลืมเรียกใช้ build() หลังจากใช้คลาสบิลเดอร์ในบริการการ์ด

ทำให้การ์ดเรียบง่าย

หากการ์ดมีวิดเจ็ตมากเกินไป วิดเจ็ตอาจเต็มหน้าจอและทำให้การ์ดมีประโยชน์น้อยลง แม้ว่าส่วนการ์ดขนาดใหญ่จะแสดงผลเป็นองค์ประกอบ UI แบบยุบได้ แต่วิธีนี้จะเป็นการซ่อนข้อมูลจากผู้ใช้ มุ่งเน้นที่การเพิ่มประสิทธิภาพส่วนเสริมและมอบสิ่งที่ผู้ใช้ต้องการอย่างตรงจุด

ใช้การ์ดข้อผิดพลาด

สร้างการ์ดสำหรับเงื่อนไขข้อผิดพลาด หากส่วนเสริมแสดงข้อผิดพลาด ก็ควรแสดงการ์ดที่มีข้อมูลข้อผิดพลาดและวิธีการแก้ไข (หากเป็นไปได้) เช่น หากส่วนเสริมเชื่อมต่อกับบริการที่ไม่ใช่ของ Google ไม่ได้เนื่องจากการให้สิทธิ์ไม่สำเร็จ ให้แสดงการ์ดที่แจ้งเรื่องนี้และขอให้ผู้ใช้ยืนยันข้อมูลบัญชีที่ใช้

เขียนการทดสอบและข้อความทดสอบ

คุณควรทดสอบส่วนเสริมทั้งหมดที่สร้างอย่างละเอียด สร้างฟังก์ชันทดสอบที่สร้างการ์ดและวิดเจ็ตโดยใช้ข้อมูลทดสอบ จากนั้นตรวจสอบว่าระบบสร้างออบเจ็กต์ตามที่คาดไว้

เมื่อใช้ฟังก์ชันการเรียกกลับการดำเนินการ คุณมักจะต้องสร้างออบเจ็กต์การตอบกลับ คุณสามารถใช้คำสั่งต่อไปนี้เพื่อตรวจสอบว่าระบบสร้างคำตอบได้อย่างถูกต้อง

    Logger.log(response.printJson());

เรียกใช้ฟังก์ชันทดสอบที่คุณสร้างขึ้นจากเครื่องมือแก้ไข Apps Script โดยตรงโดยใช้เมนูเรียกใช้ เมื่อคุณมีส่วนเสริมที่ใช้งานได้ ให้ติดตั้งเวอร์ชันที่ยังไม่ได้เผยแพร่เพื่อให้ทดสอบได้

ใช้ข้อมูลทดสอบที่เหมาะสมสําหรับแต่ละแอปพลิเคชันโฮสต์ที่ส่วนเสริมขยาย ตัวอย่างเช่น หากส่วนเสริมขยายการทำงานของ Gmail คุณอาจต้องใช้อีเมลทดสอบ 2-3 ฉบับและรหัสข้อความของอีเมลเหล่านั้นเพื่อให้แน่ใจว่าส่วนเสริมทำงานตามที่คาดไว้เมื่อได้รับเนื้อหาข้อความที่ต่างกัน คุณรับรหัสข้อความของข้อความหนึ่งๆ ได้โดยแสดงรายการข้อความโดยใช้เมธอด Gmail API users.messages.list หรือใช้บริการ Gmail ของ Apps Script

แนวทางปฏิบัติแนะนำสำหรับการประชุมในปฏิทิน

หากส่วนเสริมผสานรวมตัวเลือกการประชุมในปฏิทินของบุคคลที่สามเข้ากับ Google ปฏิทิน ให้ทําตามแนวทางปฏิบัติแนะนําเพิ่มเติมต่อไปนี้

เปิดไฟ onCreateFunction ไว้

ระบบจะเรียกใช้ onCreateFunction แต่ละรายการที่คุณกำหนดไว้ในไฟล์ Manifest แบบซิงค์กันเมื่อผู้ใช้พยายามสร้างโซลูชันการประชุมประเภทนั้น ตรวจสอบว่าฟังก์ชันเหล่านี้ทํางานเพียงขั้นต่ำที่จําเป็นในการสร้างการประชุมเท่านั้น การทำสิ่งต่างๆ ในฟังก์ชันเหล่านี้มากเกินไปอาจทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานส่วนเสริมที่ช้า

ใช้ฟิลด์ ConferenceData ที่เหมาะสมสำหรับข้อมูลการประชุม

เมื่อสร้างออบเจ็กต์ ConferenceData คุณสามารถสร้างออบเจ็กต์ที่มีรายละเอียดเกี่ยวกับการประชุม (รหัสผ่าน หมายเลขโทรศัพท์ พินส์ URI ฯลฯ) โปรดใช้ช่องEntryPoint ที่เกี่ยวข้องสำหรับข้อมูลนี้ อย่าใส่รายละเอียดเหล่านี้ในช่องหมายเหตุ ConferenceData

อย่าเพิ่มรายละเอียดการประชุมต่อท้ายกิจกรรมในปฏิทิน

ส่วนเสริมไม่จำเป็นต้องเพิ่มข้อมูลเกี่ยวกับการประชุมของบุคคลที่สามที่สร้างไว้ลงในคำอธิบายกิจกรรมของปฏิทิน ปฏิทินจะดำเนินการนี้โดยอัตโนมัติเมื่อจำเป็น