ส่วนต่อประสานผู้ใช้ iOS: สตอรี่บอร์ดกับ NIB กับโค้ดที่กำหนดเอง

ฉันมักจะได้ยินนักพัฒนา iOS ถามคำถามสำคัญที่ต่างกันออกไป:

อะไรคือวิธีที่ดีที่สุดในการพัฒนา UI ใน iOS: ผ่าน Storyboards, NIB หรือโค้ด

คำตอบสำหรับคำถามนี้ ไม่ว่าโดยชัดแจ้งหรือโดยปริยาย มักจะสันนิษฐานว่ามีตัวเลือกที่ไม่เกิดร่วมกัน ซึ่งมักจะต้องระบุล่วงหน้าก่อนการพัฒนา

ฉันคิดว่าคำตอบควรอยู่ในรูปของคำถาม ที่โต้แย้ง ตั้งแต่หนึ่งข้อขึ้นไป

รถอะไร "ดีที่สุด"?

ให้ฉันอธิบายด้วยตัวอย่างนอกหัวข้อ สมมติว่าฉันต้องการซื้อรถยนต์และถามคำถามง่ายๆ หนึ่งข้อ: "ตัวเลือกที่ดีที่สุดคืออะไร"

คุณสามารถตอบด้วยการแนะนำรุ่นหรือแม้แต่แบรนด์ได้หรือไม่? ไม่น่าจะเป็นไปได้ เว้นแต่คุณจะแนะนำเฟอร์รารี คุณอาจจะตอบคำถามอื่นๆ สองสามข้อแทน เช่น

• คุณมีงบประมาณเท่าไร?
• คุณต้องการกี่ที่นั่ง?
• คุณสนใจเกี่ยวกับการบริโภคน้ำมันเชื้อเพลิงหรือไม่?
• คุณรู้สึกอย่างไรเกี่ยวกับรถสปอร์ต?

เห็นได้ชัดว่าไม่มีสิ่งที่เรียกว่ารถ ดี หรือ ไม่ดี เว้นแต่จะอยู่ในบริบทที่เหมาะสม มีเพียงรถที่ดีหรือไม่ดีตามความต้องการเฉพาะ

กลับไปที่ iOS UI Design

เช่นเดียวกับการสอบถามเกี่ยวกับรถยนต์ของเรา คำถาม "วิธีใดคือวิธีที่ดีที่สุดในการพัฒนา UI ของ iOS" ไม่มีบริบท และที่น่าแปลกใจก็คือ คำตอบไม่จำเป็นต้องเป็นกรณีๆ ไป

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

• iOS Storyboards : เครื่องมือภาพสำหรับจัดวางมุมมองแอปพลิเคชันหลายมุมมองและการเปลี่ยนระหว่างมุมมองต่างๆ
• NIB (หรือ XIB) : ไฟล์ NIB แต่ละไฟล์สอดคล้องกับองค์ประกอบมุมมองเดียวและสามารถจัดวางใน Interface Builder ทำให้เป็นเครื่องมือที่มองเห็นได้เช่นกัน โปรดทราบว่าชื่อ “NIB” มาจากนามสกุลไฟล์ (ก่อนหน้านี้คือ .nib และปัจจุบันคือ .xib แม้ว่าการออกเสียงแบบเก่าจะยังคงอยู่)
• Custom Code : นั่นคือไม่มีเครื่องมือ GUI แต่จัดการตำแหน่งที่กำหนดเอง ภาพเคลื่อนไหว ฯลฯ ทั้งหมดโดยทางโปรแกรม

ไม่มีตัวเลือกใด ดี ไปกว่าตัวเลือกอื่นๆ ในระดับสากล (แม้ว่าคุณจะได้ยินอะไรก็ตาม)

ตัวอย่างเช่น สตอรี่บอร์ดเป็นส่วนเสริมล่าสุดของชุดเครื่องมือ iOS UI ฉันได้รับแจ้งว่าพวกเขาคืออนาคต พวกเขาจะมาแทนที่ NIB และ UI ของโค้ดที่กำหนดเอง ฉันเห็นสตอรี่บอร์ดเป็นเครื่องมือที่มีประโยชน์ แต่ไม่มีส่วน ทดแทน สำหรับ NIB และโค้ดที่กำหนดเองมากนัก สตอรี่บอร์ดเป็นตัวเลือกที่เหมาะสมในบางสถานการณ์ แต่ไม่ใช่ทุกสถานการณ์

นอกจากนี้ เหตุใดคุณจึงควรยึดติดกับตัวเลือกเดียวในเมื่อคุณสามารถใช้ทั้งหมดได้ (ในโครงการเดียวกัน) โดยเลือกกลไกที่เหมาะสมกับปัญหาเฉพาะที่มีอยู่มากที่สุด

ในความคิดของฉัน นี่เป็นคำถามที่สามารถสรุปได้ทั่วไปในระดับที่สูงกว่า และคำตอบนั้นอยู่ในอันดับต้นๆ ในรายการหลักการพัฒนาซอฟต์แวร์ของฉัน: ไม่มีภาษาสากล เฟรมเวิร์ก หรือเทคโนโลยีใดที่เป็นตัวเลือกที่ดีที่สุดสำหรับทุกคน ปัญหาการพัฒนาซอฟต์แวร์ เช่นเดียวกับการออกแบบ iOS UI

ในบทช่วยสอนการพัฒนา iOS นี้ เราจะมาสำรวจแต่ละวิธีการเหล่านี้และแนะนำกรณีการใช้งานที่ควรและ ไม่ ควรใช้ ตลอดจนวิธีการผสมผสานเข้าด้วยกัน

iOS สตอรี่บอร์ด

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

ตามชื่อของมัน Storyboard คือ กระดานที่มีเรื่องราวที่จะเล่า ไม่ควรใช้เพื่อผสมผสานเรื่องราวที่ไม่เกี่ยวข้องเป็นเล่มใหญ่เล่มเดียว กระดานเรื่องราวควรมีตัวควบคุมการดูที่เกี่ยวข้องกันตามตรรกะ ซึ่งไม่ได้หมายความว่า ทุก ตัวควบคุมการดู

ตัวอย่างเช่น การใช้สตอรี่บอร์ดในการจัดการ:

• ชุดมุมมองสำหรับการรับรองความถูกต้องและการลงทะเบียน
• โฟลว์การป้อนคำสั่งแบบหลายขั้นตอน
• กระแสเหมือนพ่อมด (เช่น บทช่วยสอน)
• ชุดมุมมองที่มีรายละเอียดหลัก (เช่น รายการโปรไฟล์ รายละเอียดโปรไฟล์)

ในขณะเดียวกัน ควรหลีกเลี่ยง Storyboard ขนาดใหญ่ รวมถึง Storyboard ทั่วทั้งแอปเดียว (เว้นแต่แอปจะค่อนข้างง่าย) ก่อนที่เราจะลงลึกไปกว่านี้ เรามาดูกันว่าทำไม

ความเขลาของสตอรี่บอร์ด iOS ขนาดใหญ่

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

เมื่อนักพัฒนาดูซอร์สโค้ด พวกเขาจะอธิบายความหมายเชิงความหมาย ดังนั้นเมื่อรวมด้วยตนเอง พวกเขาสามารถอ่านและทำความเข้าใจความขัดแย้งทั้งสองด้านและดำเนินการตามนั้น กระดานเรื่องราวเป็นไฟล์ XML ที่จัดการโดย Xcode แทน และความหมายของโค้ดแต่ละบรรทัดนั้นไม่ได้เข้าใจง่ายเสมอไป

มาดูตัวอย่างง่ายๆ กัน: สมมติว่านักพัฒนาสองคนที่แตกต่างกันเปลี่ยนตำแหน่งของ UILabel (โดยใช้การจัดวางอัตโนมัติ) และตัวหลังผลักดันการเปลี่ยนแปลงของเขา ทำให้เกิดข้อขัดแย้งเช่นนี้ (สังเกตแอตทริบิวต์ id ที่ขัดแย้งกัน):

 <layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/> </layoutGuides> <layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/> </layoutGuides>

id นั้นไม่ได้ให้การบ่งชี้ใด ๆ เกี่ยวกับความสำคัญที่แท้จริงของมัน ดังนั้นคุณจึงไม่ต้องดำเนินการใดๆ ทางออกเดียวที่มีความหมายคือการเลือกด้านใดด้านหนึ่งของความขัดแย้งและละทิ้งอีกด้านหนึ่ง จะมีผลข้างเคียงหรือไม่? ใครจะรู้? ไม่ใช่คุณ.

เพื่อลดปัญหาการออกแบบอินเทอร์เฟซ iOS เหล่านี้ การใช้สตอรีบอร์ดหลายรายการในโปรเจ็กต์เดียวกันคือแนวทางที่แนะนำ

เมื่อใดควรใช้สตอรี่บอร์ด

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

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

สุดท้าย แม้ว่า Storyboards จะใช้ได้ดีที่สุดสำหรับสถานการณ์ที่เกี่ยวข้องกับตัวควบคุมการดูหลายตัว แต่ก็สามารถป้องกันได้ถ้าใช้ Storyboard เมื่อทำงานกับตัวควบคุมมุมมองตาราง เดียว ด้วยเหตุผลสามประการ:

• ความสามารถในการออกแบบต้นแบบเซลล์ตารางแบบเข้าที่ช่วยรักษาชิ้นส่วนต่างๆ ไว้ด้วยกัน
• สามารถออกแบบเทมเพลตเซลล์ได้หลายแบบภายในตัวควบคุมมุมมองตารางพาเรนต์
• เป็นไปได้ที่จะสร้างมุมมองตารางแบบคงที่ (ส่วนเพิ่มเติมที่รอมานานซึ่งน่าเสียดายที่มีให้เฉพาะในสตอรี่บอร์ดเท่านั้น)

อาจมีคนโต้แย้งว่าสามารถออกแบบเทมเพลตหลายเซลล์โดยใช้ NIB ได้ อันที่จริง นี่เป็นเพียงเรื่องของการตั้งค่า: นักพัฒนาบางคนชอบที่จะมีทุกอย่างในที่เดียว ในขณะที่คนอื่นไม่สนใจ

เมื่อ ไม่ ใช้สตอรี่บอร์ด iOS

บางกรณี:

• มุมมองมีเลย์เอาต์ที่ซับซ้อนหรือไดนามิก ใช้งานกับโค้ดได้ดีที่สุด
• มุมมองถูกนำไปใช้กับ NIB หรือโค้ดแล้ว

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

ข้อดีและข้อเสียทั่วไป

ตอนนี้เราเข้าใจแล้วว่าสตอรี่บอร์ดมีประโยชน์ในการออกแบบ iOS UI เมื่อใด และก่อนที่เราจะไปยัง NIB ในบทช่วยสอนนี้ เรามาพูดถึงข้อดีและข้อเสียทั่วไปของพวกมันกัน

Pro: ประสิทธิภาพ

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

โปร: ต้นแบบ

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

คอนดิชั่น: นำกลับมาใช้ใหม่ได้

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

Con: การไหลของข้อมูล

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

ในกรณีเช่นนี้ เราต้องพึ่งพา prepareForSegue:sender ด้วย if/else-if skeleton ดังนี้:

 - (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = [segue identifier]; if ([identifier isEqualToString@"segue_name_1"]) { MyViewController *vc = (MyViewController *) [segue destinationViewController]; [vc setData:myData]; } else if ([identifier isEqualToString@"segue_name_2"]) { ... } else if ... }

ฉันพบว่าวิธีนี้มีข้อผิดพลาดและละเอียดโดยไม่จำเป็น

NIBs

NIB เป็นวิธีแบบเก่า (เอ้อ) ในการออกแบบอินเทอร์เฟซ iOS

ในกรณีนี้ "เก่า" ไม่ได้หมายความว่า "ไม่ดี" "ล้าสมัย" หรือ "เลิกใช้แล้ว" อันที่จริง สิ่งสำคัญคือต้องเข้าใจว่าสตอรี่บอร์ด iOS ไม่ใช่สิ่งทดแทน NIB ที่เป็นสากล พวกเขาเพียงแค่ทำให้การใช้งาน UI ง่ายขึ้นใน บาง กรณี

ด้วย NIB คุณสามารถออกแบบมุมมองตามอำเภอใจใด ๆ ซึ่งนักพัฒนาสามารถแนบไปกับตัวควบคุมการดูได้ตามต้องการ

หากเราใช้การออกแบบเชิงวัตถุกับ UI ของเรา ก็ควรที่จะแบ่งมุมมองของตัวควบคุมมุมมองออกเป็น โมดูลที่แยกจากกัน ซึ่งแต่ละส่วนใช้งานเป็นมุมมองที่มีไฟล์ NIB ของตัวเอง (หรือมีหลายโมดูลที่จัดกลุ่มเป็นไฟล์เดียวกัน) ข้อได้เปรียบที่ชัดเจนของแนวทางนี้คือ แต่ละองค์ประกอบพัฒนาได้ง่ายกว่า ทดสอบได้ง่ายขึ้น และแก้ปัญหาได้ง่ายขึ้น

NIB แบ่งปันปัญหาข้อขัดแย้งในการผสานที่เราเห็นในสตอรี่บอร์ด แต่ในระดับที่น้อยกว่า เนื่องจากไฟล์ NIB ทำงานในขนาดที่เล็กกว่า

เมื่อใดควรใช้ NIB สำหรับ iOS UI Design

ส่วนย่อยของกรณีการใช้งานทั้งหมดจะเป็น:

• มุมมองโมดัล
• มุมมองการเข้าสู่ระบบและการลงทะเบียนง่าย ๆ
• การตั้งค่า
• หน้าต่างป๊อปอัป
• เทมเพลตมุมมองที่ใช้ซ้ำได้
• เทมเพลตเซลล์ตารางที่ใช้ซ้ำได้

ในขณะเดียวกัน…

เมื่อ ไม่ ใช้ NIBs

คุณควรหลีกเลี่ยงการใช้ NIB สำหรับ:

• มุมมองที่มีเนื้อหาไดนามิก ซึ่งเลย์เอาต์เปลี่ยนแปลงอย่างมากขึ้นอยู่กับเนื้อหา
• มองว่าโดยธรรมชาติแล้วไม่สามารถออกแบบได้ง่ายในเครื่องมือสร้างอินเทอร์เฟซ
• ดูตัวควบคุมที่มีช่วงการเปลี่ยนภาพที่ซับซ้อนซึ่งลดความซับซ้อนได้ด้วย Storyboarding

ข้อดีและข้อเสียทั่วไป

โดยทั่วไป มาดูข้อดีและข้อเสียของการใช้ NIB กัน

Pro: นำกลับมาใช้ใหม่ได้

NIB มีประโยชน์เมื่อมีการแชร์เลย์เอาต์เดียวกันในหลายคลาส

ในกรณีการใช้งานอย่างง่าย เทมเพลตมุมมองที่มีช่องข้อความชื่อผู้ใช้และรหัสผ่านสามารถนำไปใช้กับมุมมอง TTLoginView และ TTSignupView ที่สมมติขึ้นได้ ซึ่งทั้งสองอย่างนี้สามารถเริ่มต้นจาก NIB เดียวกันได้ TTLoginView จะต้องซ่อนฟิลด์รหัสผ่าน และทั้งคู่จะต้องระบุป้ายกำกับคงที่ที่เกี่ยวข้อง (เช่น 'ป้อนชื่อผู้ใช้ของคุณ' กับ 'ป้อนรหัสผ่านของคุณ') แต่ป้ายกำกับจะมีฟังก์ชันพื้นฐานเหมือนกันและรูปแบบที่คล้ายคลึงกัน

Pro & Con: ประสิทธิภาพ

NIB โหลดอย่างเกียจคร้าน ดังนั้นจึงไม่ใช้หน่วยความจำจนกว่าจะจำเป็น แม้ว่าสิ่งนี้จะเป็นประโยชน์ แต่ก็มีความล่าช้าในกระบวนการโหลดแบบ Lazy Loading ซึ่งทำให้เป็นข้อเสียเช่นกัน

รหัสที่กำหนดเองของ iOS (UI แบบเป็นโปรแกรม)

การออกแบบอินเทอร์เฟซ iOS ใดๆ ที่สามารถทำได้ด้วย Storyboards และ NIB ก็สามารถนำมาใช้กับโค้ดดิบได้ (แน่นอนว่ามีบางครั้งที่นักพัฒนาไม่มีชุดเครื่องมืออันหรูหราดังกล่าว)

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

มือโปร: ภายใต้ประทุน

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

ในการเปรียบเทียบ: เครื่องคิดเลขเป็นเครื่องมือที่มีประโยชน์ แต่ก็ไม่ใช่เรื่องเลวร้ายที่จะรู้วิธีคำนวณด้วยตนเอง

สิ่งนี้ไม่ จำกัด เฉพาะ iOS แต่สำหรับเครื่องมือ RAD แบบเห็นภาพ (เช่น Visual Studio และ Delphi เพียงไม่กี่ชื่อ) สภาพแวดล้อม Visual HTML RAD แสดงถึงตัวกรณีทั่วไป: ใช้เพื่อสร้างโค้ด (มักเขียนได้ไม่ดี) โดยอ้างว่าไม่จำเป็นต้องมีความรู้ HTML และทุกอย่างสามารถทำได้ด้วยสายตา แต่ไม่มีนักพัฒนาเว็บคนใดที่จะใช้หน้าเว็บโดยไม่ทำให้มือสกปรก พวกเขารู้ว่าการจัดการ HTML และ CSS แบบดิบด้วยตนเองจะนำไปสู่โค้ดแบบแยกส่วนและมีประสิทธิภาพมากขึ้น

ดังนั้น การเรียนรู้การเข้ารหัสของอินเทอร์เฟซผู้ใช้ iOS อย่างเชี่ยวชาญจะช่วยให้คุณควบคุมและตระหนักมากขึ้นว่าชิ้นส่วนเหล่านี้เข้ากันได้อย่างไร ซึ่งจะช่วยเพิ่มขอบเขตบนของคุณในฐานะนักพัฒนา

Pro: เมื่อรหัสเป็นตัวเลือกเดียว

นอกจากนี้ยังมีกรณีที่โค้ด iOS ที่กำหนดเองเป็นตัวเลือกเดียวสำหรับการออกแบบ UI เลย์เอาต์แบบไดนามิกที่องค์ประกอบมุมมองถูกย้ายไปรอบๆ และโฟลว์หรือเลย์เอาต์ที่ปรับอย่างมากตามเนื้อหา เป็นตัวอย่างทั่วไป

มือโปร: ผสานความขัดแย้ง

แม้ว่า NIB และ Storyboard จะประสบปัญหาจากความขัดแย้งในการผสานอย่างมาก แต่โค้ดก็ไม่มีข้อผิดพลาดเหมือนกัน โค้ดทั้งหมดมีความหมายเชิงความหมาย ดังนั้น การแก้ไขข้อขัดแย้งจึงไม่ยากกว่าปกติ

Con: การสร้างต้นแบบ

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

คอนดิชั่น: Refactoring

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

Pro: ประสิทธิภาพ

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

Pro: นำกลับมาใช้ใหม่ได้

มุมมองใดๆ ที่ใช้งานโดยทางโปรแกรมสามารถออกแบบในลักษณะที่นำกลับมาใช้ใหม่ได้ ลองดูกรณีการใช้งานบางส่วน:

• มุมมองตั้งแต่สองข้อขึ้นไปมีพฤติกรรมร่วมกัน แต่มีความแตกต่างกันเล็กน้อย คลาสฐานและคลาสย่อยสองคลาสแก้ปัญหาได้อย่างสวยงาม
• โปรเจ็กต์ต้องถูกแยกออกโดยมีเป้าหมายเพื่อสร้างฐานโค้ดเดียว แต่สร้างสองแอปพลิเคชัน (หรือมากกว่า) ที่แตกต่างกัน โดยแต่ละรายการมีการปรับแต่งเฉพาะ

ขั้นตอนการออกแบบ UI เดียวกันจะซับซ้อนกว่ามากเมื่อใช้ NIB และ Storyboards ไฟล์เทมเพลตไม่อนุญาตให้มีการสืบทอด และวิธีแก้ปัญหาที่เป็นไปได้จำกัดดังต่อไปนี้:

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

เมื่อใดควรใช้รหัส

มักจะเป็นการดีที่จะใช้โค้ดที่กำหนดเองสำหรับการออกแบบส่วนต่อประสานผู้ใช้ iOS เมื่อคุณมี:

• เค้าโครงแบบไดนามิก
• มุมมองที่มีเอฟเฟกต์ เช่น มุมโค้งมน เงา ฯลฯ
• กรณีใดก็ตามที่การใช้ NIB และ Storyboards นั้นซับซ้อนหรือเป็นไปไม่ได้

เมื่อ ไม่ ใช้รหัส

โดยทั่วไป คุณสามารถใช้ UI ที่สร้างโค้ดได้ เสมอ ไม่ค่อยมีความคิดที่แย่นัก ดังนั้นฉันจึงใส่ an ที่นี่.

แม้ว่า NIB และ Storyboards จะนำข้อดีบางอย่างมาสู่ตาราง แต่ฉันรู้สึกว่าไม่มีข้อเสียที่สมเหตุสมผลที่ฉันจะใส่ในรายการเพื่อไม่ให้ใช้โค้ด (ยกเว้นบางที ความเกียจคร้าน)

หนึ่งโครงการ หลายเครื่องมือ

กระดานเรื่องราว NIB และโค้ดเป็นเครื่องมือสามอย่างที่แตกต่างกันสำหรับการสร้างอินเทอร์เฟซผู้ใช้ iOS เราโชคดีที่มีพวกเขา ผู้คลั่งไคล้ UI แบบเป็นโปรแกรมอาจจะไม่พิจารณาตัวเลือกอีกสองตัวเลือกอื่น: รหัสช่วยให้คุณทำทุกอย่างที่ทำได้ในทางเทคนิค ในขณะที่ทางเลือกอื่นนั้นมีข้อจำกัด สำหรับนักพัฒนาที่เหลือนั้น Xcode มีดทหารมีเครื่องมือสามอย่างซึ่งสามารถใช้งานได้ทั้งหมดในคราวเดียว ในโครงการเดียวกันอย่างมีประสิทธิภาพ

คุณถามอย่างไร แล้วแต่คุณชอบ แนวทางที่เป็นไปได้มีดังนี้

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

เพื่อปิด มาดูตัวอย่างสุดท้ายที่เชื่อมโยงทั้งหมดเข้าด้วยกัน

กรณีการใช้งานอย่างง่าย

สมมติว่าเราต้องการพัฒนาแอพส่งข้อความพื้นฐานที่มีมุมมองที่แตกต่างกันหลายประการ:

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

นอกจากนี้ เราต้องการให้มุมมองไหลลื่นดังนี้:

• การคลิกรายการในรายชื่อเพื่อนที่ติดตามจะแสดงรายละเอียดโปรไฟล์ของเพื่อนที่เกี่ยวข้อง
• รายละเอียดโปรไฟล์จะแสดงชื่อโปรไฟล์ ที่อยู่ สถิติ รายการข้อความล่าสุด และแถบเครื่องมือ

ในการใช้งานแอป iOS นี้ เครื่องมือ UI ทั้งสามของเราจะมีประโยชน์ ดังที่เราสามารถใช้:

• กระดานเรื่องราวพร้อมตัวควบคุมมุมมองสี่แบบ (รายการ รายละเอียด รายการข้อความ และแบบฟอร์มข้อความใหม่)
• ไฟล์ NIB แยกต่างหากสำหรับเทมเพลตเซลล์รายการโปรไฟล์ที่ใช้ซ้ำได้
• ไฟล์ NIB แยกกันสามไฟล์สำหรับมุมมองรายละเอียดโปรไฟล์ ไฟล์หนึ่งไฟล์สำหรับแต่ละส่วนที่แยกจากกันที่ประกอบขึ้น (รายละเอียดโปรไฟล์ สถิติ สามข้อความล่าสุด) เพื่อให้บำรุงรักษาได้ดียิ่งขึ้น NIB เหล่านี้จะถูกสร้างอินสแตนซ์เป็นมุมมอง และเพิ่มไปยังตัวควบคุมมุมมอง
• รหัสที่กำหนดเองสำหรับมุมมองแท็กคลาวด์ มุมมองนี้เป็นตัวอย่างทั่วไปของมุมมองที่ไม่สามารถออกแบบในตัวสร้างส่วนต่อประสาน ไม่ว่าจะผ่าน StoryBoards หรือ NIB แต่จะใช้งานโดยสมบูรณ์ผ่านโค้ดแทน เพื่อรักษาโฟลว์ภาพของ Storyboard เราเลือกที่จะเพิ่มตัวควบคุมมุมมองที่ว่างเปล่าลงใน Storyboard ใช้แท็ก cloud view เป็นมุมมองแบบสแตนด์อโลน และเพิ่มมุมมองไปยังตัวควบคุมมุมมองโดยทางโปรแกรม เห็นได้ชัดว่า มุมมองสามารถใช้งานได้ภายในตัวควบคุมการดู แทนที่จะเป็นมุมมองแบบสแตนด์อโลน แต่เราแยกส่วนเหล่านี้ออกจากกันเพื่อนำมาใช้ใหม่ได้ดียิ่งขึ้น

แบบจำลองพื้นฐานจริงๆ อาจมีลักษณะดังนี้:

ด้วยเหตุนี้ เราจึงได้สรุปโครงสร้างพื้นฐานของแอป iOS ที่มีความซับซ้อนพอสมควร ซึ่งมุมมองหลักเชื่อมโยงแนวทางหลักสามประการในการออกแบบ UI เข้าด้วยกัน โปรดจำไว้ว่า: ไม่มีการตัดสินใจแบบไบนารี เนื่องจากเครื่องมือแต่ละอย่างมีจุดแข็งและจุดอ่อน

ห่อ

ตามที่ตรวจสอบในบทแนะนำนี้ Storyboards ได้เพิ่มความเรียบง่ายที่เห็นได้ชัดเจนให้กับการออกแบบ iOS UI และการไหลของภาพ พวกเขายังกำจัดรหัสสำเร็จรูป แต่ทั้งหมดนี้มาในราคาที่จ่ายได้อย่างยืดหยุ่น ในขณะเดียวกัน NIB ให้ความยืดหยุ่นมากขึ้นโดยเน้นที่มุมมองเดียว แต่ไม่มีการไหลของภาพ โซลูชันที่ยืดหยุ่นที่สุดคือโค้ด ซึ่งมักจะไม่เป็นมิตรและไม่ใช่ภาพโดยเนื้อแท้

หากบทความนี้ทำให้คุณทึ่ง ฉันขอแนะนำให้ดูการอภิปรายที่ยอดเยี่ยมของ Ray Wenderlich ซึ่งใช้เวลา 55 นาทีในการอภิปรายเกี่ยวกับ NIB, Storyboards และ UIS ที่สร้างด้วยโค้ด

สรุป ฉันต้องการเน้นสิ่งหนึ่ง: หลีกเลี่ยงการใช้เครื่องมือออกแบบ iOS UI ที่ไม่เหมาะสมในทุก กรณี หากมุมมองไม่สามารถออกแบบได้ด้วย Storyboard หรือหากสามารถนำไปใช้กับ NIB หรือโค้ดในวิธีที่ง่ายกว่า ก็ อย่า ใช้ Storyboard ในทำนองเดียวกัน หากมุมมองไม่สามารถออกแบบได้โดยใช้ NIB อย่าใช้ NIB กฎเหล่านี้แม้จะเรียบง่าย แต่จะช่วยส่งเสริมการศึกษาของคุณในฐานะนักพัฒนาซอฟต์แวร์ได้เป็นอย่างดี