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

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

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

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

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

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

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

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