เวลาที่จะใช้กระดานเรื่องราวและเมื่อใดที่จะใช้ XIB

มีแนวทางใดบ้างในการใช้กระดานเรื่องราวในโครงการ iOS และเมื่อใช้ XIBs อะไรคือข้อดีและข้อเสียของแต่ละสถานการณ์

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

ฉันใช้ XIB อย่างกว้างขวางและทำสองโครงการให้เสร็จโดยใช้สตอรี่บอร์ด การเรียนรู้ของฉันคือ:

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

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

ถ้าฉันเริ่มต้นแอพขนาดเล็กและสามารถซื้อ iOS5 ได้เฉพาะความเข้ากันได้ฉันจะใช้สตอรีบอร์ด สำหรับกรณีอื่น ๆ ฉันใช้ XIB

อัปเดต 1/12/2016 : นี่คือปี 2016 และฉันยังคงต้องการจัดวาง UIs ของฉันในโค้ดไม่ใช่ในกระดานเรื่องราว ที่ถูกกล่าวว่ากระดานเรื่องราวมาไกล ฉันได้ลบคะแนนทั้งหมดจากโพสต์นี้ที่ไม่ได้ใช้อีกต่อไปในปี 2559

Update 4/24/2015 : ที่น่าสนใจ Apple ไม่ได้ใช้สตอรีบอร์ดใน ResearchKit ที่เพิ่งเปิดใหม่เมื่อปีเตอร์สไตน์เบอร์เกอร์สังเกตเห็น (ภายใต้หัวข้อย่อย "เครื่องมือสร้างอินเตอร์เฟส")

อัปเดต 6/10/2557 : อย่างที่คาดการณ์ไว้ Apple กำลังปรับปรุงสตอรีบอร์ดและ Xcode อย่างต่อเนื่อง บางจุดที่ใช้กับ iOS 7 และต่ำกว่าไม่ได้ใช้กับ iOS 8 อีกต่อไป (และตอนนี้ถูกทำเครื่องหมายเป็นเช่นนี้) ดังนั้นในขณะที่สตอรี่บอร์ดโดยเนื้อแท้ยังคงมีข้อบกพร่องผมทบทวนคำแนะนำของฉันจากการไม่ได้ใช้เพื่อใช้คัดเลือกที่มันทำให้รู้สึก

แม้ตอนนี้ iOS 9 จะออกมาแล้วฉันก็อยากจะแนะนำ ต่อต้านใช้ความระมัดระวังเมื่อตัดสินใจว่าจะใช้สตอรีบอร์ดหรือไม่ นี่คือเหตุผลของฉัน:

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

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

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

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

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

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

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

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

• บอร์ดโครงเรื่องจะไม่ให้คุณเปลี่ยนประเภทของตัวควบคุมมุมมองพิเศษ : คุณต้องการเปลี่ยนUITableViewControllerเป็นUICollectionViewController? หรือเป็นธรรมดาUIViewController? เป็นไปไม่ได้ในกระดานเรื่องราว คุณต้องลบตัวควบคุมมุมมองเก่าและสร้างอันใหม่และเชื่อมต่อส่วนย่อยทั้งหมดอีกครั้ง การเปลี่ยนแปลงรหัสทำได้ง่ายกว่ามาก

• กระดานเรื่องราวเพิ่มหนี้สินพิเศษสองรายการให้กับโครงการของคุณ : (1) เครื่องมือ Storyboard Editor ที่สร้างสตอรี่บอร์ด XML และ (2) ส่วนประกอบรันไทม์ที่แยกวิเคราะห์ XML และสร้าง UI และวัตถุควบคุมจากนั้น ทั้งสองส่วนสามารถมีข้อบกพร่องที่คุณไม่สามารถแก้ไขได้

• กระดานเรื่องราวไม่อนุญาตให้คุณเพิ่มมุมมองย่อยให้กับUIImageView : ใครจะรู้ว่าทำไม

• สตอรีบอร์ดไม่อนุญาตให้คุณเปิดใช้งานเลย์เอาต์อัตโนมัติสำหรับแต่ละมุมมอง (-Controller) s : โดยการทำเครื่องหมาย / ยกเลิกการเลือกตัวเลือกเลย์เอาต์อัตโนมัติใน Storyboard การเปลี่ยนแปลงจะถูกนำไปใช้กับคอนโทรลเลอร์ทั้งหมดในสตอรีบอร์ด (ขอบคุณ Sava Mazăreสำหรับประเด็นนี้!)

• สตอรีบอร์ดมีความเสี่ยงสูงที่จะทำลายความเข้ากันได้แบบย้อนหลัง : บางครั้ง Xcode เปลี่ยนรูปแบบไฟล์สตอรีบอร์ดและไม่รับประกันว่าจะสามารถเปิดไฟล์สตอรีบอร์ดที่คุณสร้างขึ้นในวันนี้ไม่กี่ปีหรือหลายเดือนนับจากนี้ (ขอบคุณที่คิดล่วงหน้าสำหรับจุดนี้ดูความคิดเห็นต้นฉบับ )

• สตอรี่บอร์ดสามารถทำให้รหัสของคุณที่ซับซ้อนมากขึ้น : เมื่อคุณสร้างตัวควบคุมมุมมองของคุณในรหัสคุณสามารถสร้างที่กำหนดเองวิธีการเช่นinit initWithCustomer:ด้วยวิธีนี้คุณสามารถทำให้customerภายในตัวควบคุมมุมมองไม่เปลี่ยนรูปและตรวจสอบให้แน่ใจว่าไม่สามารถสร้างตัวควบคุมมุมมองนี้ได้หากไม่มีcustomerวัตถุ สิ่งนี้เป็นไปไม่ได้เมื่อใช้บอร์ดโครงเรื่อง คุณจะต้องรอprepareForSegue:sender:วิธีการที่จะเรียกและจากนั้นคุณจะต้องตั้งค่าcustomerคุณสมบัติในตัวควบคุมมุมมองของคุณซึ่งหมายความว่าคุณต้องทำให้คุณสมบัตินี้ไม่แน่นอนและคุณจะต้องอนุญาตให้สร้างตัวควบคุมมุมมองโดยไม่ต้องcustomerวัตถุ . จากประสบการณ์ของฉันนี่อาจทำให้โค้ดของคุณซับซ้อนและทำให้ยากขึ้นเกี่ยวกับการไหลของแอปของคุณ อัปเดต 9/9/16: Chris Dzombak เขียนบทความที่ดีเกี่ยวกับปัญหานี้

• It's McDonald's : พูดในคำของ Steve Jobs เกี่ยวกับ Microsoft: มันเป็น McDonald (วิดีโอ) !

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

เมื่อฉันสร้าง UI และโฟลว์แอปพลิเคชันของฉันฉันควบคุมสิ่งที่เกิดขึ้นได้ง่ายขึ้นมันง่ายต่อการดีบักมันง่ายกว่าที่จะพบข้อผิดพลาดตั้งแต่เนิ่นๆมันจะอธิบายการเปลี่ยนแปลงของฉันกับนักพัฒนาคนอื่นได้ง่ายกว่า ง่ายต่อการรองรับ iPhone และ iPad

อย่างไรก็ตามฉันยอมรับว่าการกำหนดUI ทั้งหมดของคุณในรหัสอาจไม่ใช่โซลูชันที่เหมาะกับทุกขนาดสำหรับทุกโครงการ หาก iPad UI ของคุณแตกต่างอย่างมากจาก iPhone UI ของคุณในบางสถานที่อาจทำให้รู้สึกถึงการสร้าง XIB สำหรับพื้นที่เหล่านั้น

ปัญหาต่าง ๆ ที่กล่าวมาข้างต้นสามารถแก้ไขได้โดย Apple และฉันหวังว่านั่นคือสิ่งที่พวกเขาจะทำ

แค่สองเซ็นต์ของฉัน

อัปเดต : ใน Xcode 5 Apple ได้ยกเลิกตัวเลือกเพื่อสร้างโครงการโดยไม่มีกระดานเรื่องราว ฉันเขียนสคริปต์ขนาดเล็กที่พอร์ตแม่แบบของ Xcode 4 (พร้อมตัวเลือกสตอรี่บอร์ด - ยกเลิก) ไปที่ Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

กระดานเรื่องราวถูกสร้างขึ้นเพื่อช่วยให้นักพัฒนาสามารถมองเห็นแอปพลิเคชันและการไหลของแอปพลิเคชัน มันมากเหมือนมีพวงของ xib แต่ในไฟล์เดียว

มีคำถามที่คล้ายกับที่ตั้งนี้ความแตกต่างระหว่างไฟล์. xib และ. storyboard คืออะไร .

นอกจากนี้คุณยังสามารถสร้างการเปลี่ยนแปลงที่กำหนดเองผ่านรหัสที่จะเปลี่ยนแปลงแบบไดนามิกหากจำเป็นเช่นเดียวกับที่คุณสามารถทำได้ด้วย. xibs

ข้อดี:

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

ข้อเสีย:

• ใช้งานได้กับ iOS 5 ขึ้นไปเท่านั้น ไม่ทำงานกับ iOS4
• สามารถเกะกะได้ง่าย ๆ ถ้าคุณมีแอพพลิเคชั่นที่ดูเข้มข้นมาก ๆ

มีไม่ผิด / ผิดเมื่อใช้อย่างใดอย่างหนึ่งมันเป็นเรื่องของการตั้งค่าและ iOS รุ่นที่คุณต้องการใช้

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

1. Apple ได้ปรับปรุงการทำงานกับสตอรีบอร์ดเป็นอย่างมาก และพวกเขาสนับสนุนให้คุณทำงานกับพวกเขา ซึ่งหมายความว่าพวกเขาจะไม่ทำลายโครงการที่มีอยู่ของคุณด้วยการอัปเดตพวกเขาจะตรวจสอบให้แน่ใจว่ากระดานเรื่องราวเป็นหลักฐานในอนาคตสำหรับรุ่น XCode / iOS รุ่นใหม่
2. ผลลัพธ์ที่ชัดเจนยิ่งขึ้นในเวลาที่น้อยลงสำหรับเจ้าของสินค้าและผู้จัดการแม้ในระหว่างขั้นตอนการสร้าง คุณสามารถใช้สตอรี่บอร์ดเป็นแผนผังไดอะแกรมและอภิปรายในการประชุมได้
3. แม้หลังจากที่แอปเสร็จสิ้น (และโดยทั่วไปจะเป็นจุดเริ่มต้นของวงจรชีวิต) - ในอนาคตมันจะเร็วขึ้นและง่ายขึ้นในการปรับใช้เล็กน้อยเร็วขึ้นและง่ายต่อการใช้ปรับขนาดเล็กและสิ่งเหล่านี้สามารถเปลี่ยนแปลงเค้าโครงของคุณได้หลายอย่างในเวลาเดียวกันซึ่งคุณอาจต้องการเห็นในลักษณะ WYSIWYG ทางเลือกอื่นคือการเปลี่ยน UI การเขียนด้วยมือในโค้ดและสลับไปมาระหว่าง IDE และเครื่องมือจำลองเพื่อทดสอบในแต่ละครั้งที่รอการคอมไพล์และสร้าง
4. ผู้สอนที่ไม่ใช่นักพัฒนาสามารถสอนเพื่อตั้งค่าเลย์เอาต์ในกระดานเรื่องราวและสร้างตะขอที่จำเป็นสำหรับนักพัฒนา (IBOutlets และ IBActions) นั่นเป็นข้อดีอย่างมากเพราะมันช่วยให้ผู้พัฒนาซอฟต์แวร์มุ่งเน้นไปที่ตรรกะและนักออกแบบ UX ใช้การเปลี่ยนแปลงในลักษณะที่มองเห็นโดยไม่ต้องเขียนโค้ดใด ๆ เลย

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

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

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

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

ฉันได้อ่านความคิดเห็นจำนวนมากอีกครั้งซึ่งเป็นเค้าโครงอัตโนมัติ ด้วย XCode 5 มันได้รับการปรับปรุงให้ดีขึ้นจริง ๆ มันดีจริงๆสำหรับการจัดวางอัตโนมัติ ในบางกรณีคุณจะต้องทำอะไรบางอย่างในรหัส แต่คุณสามารถแก้ไขข้อ จำกัด ที่คุณต้องแก้ไขและ ณ จุดนั้นทำสิ่งที่คุณต้องการในรหัสของคุณ แม้แต่เคลื่อนไหวพวกเขา

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

ฉันไม่ได้ใช้ StoryBoard หรือ XIBs ในแอพใดก็ได้ของฉัน .. แต่สร้างทุกอย่างโดยทางโปรแกรม

∆ ประโยชน์:

√คุณสามารถสร้าง UI หรือแอนิเมชั่นการเปลี่ยนแปลงที่ซับซ้อนได้ UIView 's

√รองรับ iOS ทุกรุ่น ไม่ต้องกังวลกับ <iOS 5

√ * แอพของคุณรองรับอุปกรณ์ iPhone / iPod / iPad ทั้งหมดภายในรหัสของคุณ

√คุณจะได้รับการอัปเดตอยู่เสมอเพราะคุณรู้รหัสที่ใช้งานได้

√ * จะทำงานกับอุปกรณ์ (ใหม่) ที่เปิดตัว - ไม่จำเป็นต้องเปลี่ยนรหัส

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

√สุดท้าย แต่ไม่ใช่ในรายการ - คุณจะไม่มีวันลืมสิ่งนั้นวิธีการจัดการทุกอย่างโดยทางโปรแกรม นี่คือสิ่งที่ดีที่สุดเมื่อคุณรู้จักการควบคุมอย่างลึกซึ้งแล้วใครก็ตาม

_{ฉันไม่เคยพบปัญหาด้วยการไม่ใช้ SB หรือ XIBs เพราะฉันใช้งานได้ดี}

_{* หากคุณตั้งค่ากรอบวัตถุของ UIKit ตามขนาดหน้าจอ}

_{ป.ล. ถ้าคุณยังไม่ได้ทำสิ่งนี้ - คุณอาจประสบปัญหา (หรืออาจรู้สึกเบื่อ) แต่เมื่อคุณคุ้นเคยกับสิ่งนี้ - มันเป็นของหวานสำหรับคุณจริงๆ}

หากคุณกำลังสนใจเกี่ยวกับการทำงานของสตอรีบอร์ดดูWWDC 2015 เซสชัน 407

สร้างเวลา

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

หากฉันมีตัวควบคุมมุมมองที่มีมุมมองและมุมมองย่อยตัวสร้างส่วนต่อประสานเวลาบิลด์จะสร้างไฟล์ปลายปากกาสำหรับตัวควบคุมมุมมองและสร้างไฟล์ปลายปากกาสำหรับมุมมอง

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

เวลาทำงาน

เมื่อคุณจัดสรรอินสแตนซ์กระดานเรื่องราวโดยใช้สตอรี่บอร์ด UI, API สิ่งแรกที่คุณจัดสรรหน่วยความจำสำหรับคืออินสแตนซ์กระดานเรื่องราว UI

ยังไม่มีตัวควบคุมมุมมองยังไม่มีมุมมอง

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

ฉันทำงานเกี่ยวกับโปรเจคที่มีขนาดพอสมควร (> 20 ฉากในสแลงบอร์ดเรื่องราว) และพบข้อ จำกัด มากมายและต้องไปที่เอกสารและ google ค้นหาสิ่งต่าง ๆ ซ้ำ ๆ

1. UI มีอยู่ในไฟล์เดียว แม้ว่าคุณจะสร้างสตอรีบอร์ดหลายรายการคุณยังคงมีฉาก / หน้าจอจำนวนมากในแต่ละกระดานเรื่องราว นี่เป็นปัญหาในทีมขนาดใหญ่ขนาดกลาง

2. ประการที่สองพวกเขาเล่นได้ไม่ดีกับตัวควบคุมคอนเทนเนอร์แบบกำหนดเองซึ่งฝังตัวควบคุมคอนเทนเนอร์อื่น ๆ เป็นต้นเรากำลังใช้ MFSlideMenu ในแอปพลิเคชันแบบแท็บและฉากมีตาราง แทบจะเป็นไปไม่ได้เลยที่จะจัดการกับกระดานเรื่องราว หลังจากใช้เวลาหลายวันฉันก็หันไปใช้วิธี XIB ที่มีการควบคุมอย่างสมบูรณ์

3. IDE ไม่อนุญาตให้เลือกการควบคุมในสถานะซูมออก ดังนั้นในโครงการขนาดใหญ่การซูมออกส่วนใหญ่จะได้มุมมองระดับสูงและไม่มีอะไรเพิ่มเติม

ฉันจะใช้กระดานเรื่องราวสำหรับแอปพลิเคชันขนาดเล็กที่มีขนาดทีมเล็กและใช้วิธี XIB สำหรับทีม / โครงการขนาดกลางขนาดใหญ่

หากคุณต้องการใช้ UI บางส่วนในมุมมองหลายตัวควบคุมอีกครั้งคุณควรใช้ XIB