Kapan harus menggunakan Storyboard dan kapan harus menggunakan XIB

Apakah ada pedoman kapan menggunakan papan cerita dalam proyek iOS dan kapan menggunakan XIB? apa pro dan kontra dari masing-masing dan situasi apa yang masing-masing sesuai?

Sedekat yang bisa saya katakan, tidak segarang menggunakan papan storyboard ketika Anda memiliki pengontrol tampilan yang didorong oleh elemen UI dinamis (Seperti pin peta).

Saya telah menggunakan XIB secara ekstensif dan menyelesaikan dua proyek menggunakan Storyboard. Pembelajaran saya adalah:

• Storyboard bagus untuk aplikasi dengan jumlah layar kecil hingga menengah dan navigasi yang relatif mudah antara tampilan.
• Jika Anda memiliki banyak tampilan dan banyak navigasi silang di antara mereka, tampilan Storyboard menjadi membingungkan dan terlalu banyak pekerjaan untuk tetap bersih.
• Untuk proyek besar dengan banyak pengembang saya tidak akan menggunakan Storyboards karena Anda memiliki satu file untuk UI Anda dan tidak dapat dengan mudah bekerja secara paralel.
• Mungkin layak untuk aplikasi besar untuk dipecah menjadi beberapa file storyboard tapi saya belum mencobanya. Jawaban ini menunjukkan bagaimana melakukan pemisahan antara storyboard.
• Anda masih membutuhkan XIB: Di kedua proyek Storyboard saya, saya harus menggunakan XIB untuk sel tabel kustom.

Saya pikir Storyboard adalah langkah ke arah yang benar untuk implementasi UI dan berharap Apple akan memperpanjangnya di versi iOS yang akan datang. Mereka perlu menyelesaikan masalah "file tunggal", jika tidak mereka tidak akan menarik untuk proyek yang lebih besar.

Jika saya memulai aplikasi ukuran kecil dan hanya mampu kompatibilitas iOS5, saya akan menggunakan Storyboards. Untuk semua kasus lain saya tetap menggunakan XIB.

Pembaruan 1/12/2016 : Ini tahun 2016 dan saya masih lebih suka menata kode UI saya dan bukan di Storyboards. Yang sedang berkata, Storyboards telah datang jauh. Saya telah menghapus semua poin dari posting ini yang tidak berlaku lagi pada tahun 2016.

Pembaruan 4/24/2015 : Yang menarik Apple bahkan tidak menggunakan Storyboard di ResearchKit mereka yang baru-baru ini bersumber terbuka seperti yang diperhatikan Peter Steinberger (di bawah judul "Interface Builder").

Pembaruan 6/10/2014 : Seperti yang diharapkan, Apple terus meningkatkan Storyboards dan Xcode. Beberapa poin yang berlaku untuk iOS 7 dan di bawah tidak berlaku untuk iOS 8 lagi (dan sekarang ditandai seperti itu). Jadi, sementara Storyboard secara inheren masih memiliki kekurangan, saya merevisi saran saya dari tidak digunakan secara selektif untuk menggunakannya .

Bahkan sekarang iOS 9 sudah keluar, saya akan menyarankan melawanuntuk menggunakan hati-hati saat memutuskan apakah akan menggunakan Storyboard. Inilah alasan saya:

• Storyboard gagal saat runtime, bukan pada waktu kompilasi : Anda memiliki kesalahan ketik dalam nama segue atau menghubungkannya dengan salah di storyboard Anda? Ini akan meledak saat runtime. Anda menggunakan subkelas UIViewController khusus yang tidak ada lagi di storyboard Anda? Ini akan meledak saat runtime. Jika Anda melakukan hal-hal tersebut dalam kode, Anda akan menangkapnya sejak dini, selama waktu kompilasi. Memperbarui : Alat baru saya StoryboardLint sebagian besar memecahkan masalah ini.

• Storyboard menjadi membingungkan dengan cepat : Seiring proyek Anda tumbuh, storyboard Anda semakin sulit dinavigasi. Juga, jika beberapa pengontrol tampilan memiliki beberapa segmen ke beberapa pengontrol tampilan lainnya, storyboard Anda dengan cepat mulai terlihat seperti semangkuk spageti dan Anda akan menemukan diri Anda memperbesar dan memperkecil dan menggulir ke semua tempat untuk menemukan pengontrol tampilan yang Anda cari untuk dan untuk mengetahui poin segue mana. Pembaruan : Masalah ini sebagian besar dapat diselesaikan dengan membagi Storyboard Anda menjadi beberapa Storyboards, seperti yang dijelaskan dalam artikel ini oleh Pilky dan artikel ini oleh Robert Brown .

• Storyboard membuat bekerja dalam tim lebih sulit : Karena Anda biasanya hanya memiliki satu file storyboard besar untuk proyek Anda, membuat banyak pengembang secara teratur membuat perubahan pada satu file itu bisa menjadi sakit kepala: Perubahan perlu digabung dan konflik diselesaikan. Ketika konflik terjadi, sulit untuk mengatakan bagaimana mengatasinya: Xcode menghasilkan file XML storyboard dan itu tidak benar-benar dirancang dengan tujuan bahwa manusia harus membaca, apalagi mengeditnya.

• Storyboard membuat ulasan kode sulit atau hampir tidak mungkin : Ulasan kode rekan adalah hal yang hebat untuk dilakukan di tim Anda. Namun, ketika Anda membuat perubahan pada storyboard, hampir tidak mungkin untuk meninjau perubahan ini dengan pengembang yang berbeda. Yang dapat Anda tarik hanyalah sebuah file XML yang sangat besar. Menguraikan apa yang benar-benar berubah dan apakah perubahan itu benar atau jika mereka merusak sesuatu sangat sulit.

• Storyboards menghambat penggunaan kembali kode : Dalam proyek iOS saya, saya biasanya membuat kelas yang berisi semua warna dan font serta margin dan inset yang saya gunakan di seluruh aplikasi untuk memberikan tampilan dan rasa yang konsisten: Ini adalah perubahan satu baris jika saya harus sesuaikan salah satu dari nilai-nilai itu untuk seluruh aplikasi. Jika Anda menetapkan nilai-nilai tersebut di storyboard, Anda menduplikasinya dan perlu menemukan setiap kejadian ketika Anda ingin mengubahnya. Kemungkinan besar Anda melewatkannya, karena tidak ada pencarian dan ganti di storyboard.

• Storyboard membutuhkan saklar konteks konstan : Saya menemukan diri saya bekerja dan menavigasi lebih cepat dalam kode daripada di storyboard. Saat aplikasi Anda menggunakan storyboard, Anda terus-menerus mengubah konteks: "Oh, saya ingin mengetuk sel tampilan tabel ini untuk memuat pengontrol tampilan yang berbeda. Sekarang saya harus membuka storyboard, menemukan pengontrol tampilan yang benar, membuat segue baru ke view controller lain (yang juga harus saya temukan), berikan nama segue, ingat nama itu (saya tidak bisa menggunakan konstanta atau variabel di storyboard), kembali ke kode dan berharap saya tidak salah ketik nama segue untuk metode prepForSegue saya. Betapa saya berharap saya bisa mengetikkan 3 baris kode di sini di mana saya berada! " Tidak, itu tidak menyenangkan. Beralih antara kode dan storyboard (dan antara keyboard dan mouse) menjadi cepat dan memperlambat Anda.

• Storyboard sulit untuk di-refactor : Ketika Anda melakukan refactor pada kode Anda, Anda harus memastikan itu masih cocok dengan yang diharapkan storyboard Anda. Ketika Anda memindahkan barang-barang di storyboard Anda, Anda hanya akan mengetahui saat runtime jika masih bekerja dengan kode Anda. Rasanya bagi saya seolah-olah saya harus menyinkronkan dua dunia. Rasanya rapuh dan membuat perubahan dalam pendapat saya yang sederhana.

• Storyboard kurang fleksibel : Dalam kode, Anda pada dasarnya dapat melakukan apa pun yang Anda inginkan! Dengan storyboard, Anda terbatas pada subset dari apa yang dapat Anda lakukan dalam kode. Terutama ketika Anda ingin melakukan beberapa hal maju dengan animasi dan transisi, Anda akan menemukan diri Anda "melawan papan cerita" untuk membuatnya bekerja.

• Storyboard tidak memungkinkan Anda mengubah jenis pengontrol tampilan khusus : Anda ingin mengubah UITableViewControllera UICollectionViewController? Atau ke dataran UIViewController? Tidak mungkin di Storyboard. Anda harus menghapus pengontrol tampilan lama dan membuat yang baru dan menghubungkan kembali semua segmen. Jauh lebih mudah untuk melakukan perubahan kode.

• Storyboard menambahkan dua kewajiban tambahan untuk proyek Anda : (1) Alat Editor Storyboard yang menghasilkan XML storyboard dan (2) komponen runtime yang mem-parsing XML dan membuat UI dan objek pengontrol darinya. Kedua bagian dapat memiliki bug yang tidak dapat Anda perbaiki.

• Storyboard tidak memungkinkan Anda untuk menambahkan subview keUIImageView : Siapa yang tahu mengapa.

• Storyboard tidak memungkinkan Anda untuk mengaktifkan Tata Letak Otomatis untuk Tampilan individual (-Controller) s : Dengan mencentang / menghapus centang opsi Auto Layout di Storyboard, perubahan diterapkan ke SEMUA pengontrol di Storyboard. (Terima kasih kepada Sava Mazăre untuk poin ini!)

• Storyboard memiliki risiko lebih tinggi untuk merusak kompatibilitas mundur : Xcode terkadang mengubah format file Storyboard dan tidak menjamin dengan cara apa pun Anda akan dapat membuka file Storyboard yang Anda buat hari ini beberapa tahun atau bahkan beberapa bulan dari sekarang. (Berkat kemajuan pemikiran untuk hal ini. Lihat komentar asli )

• Storyboard dapat membuat kode Anda lebih kompleks : Ketika Anda membuat pengontrol tampilan dalam kode, Anda dapat membuat initmetode khusus , misalnya initWithCustomer:. Dengan begitu, Anda dapat membuat bagian customerdalam pengontrol tampilan Anda tidak berubah dan memastikan bahwa pengontrol tampilan ini tidak dapat dibuat tanpa customerobjek. Ini tidak mungkin saat menggunakan Storyboards. Anda harus menunggu prepareForSegue:sender:metode dipanggil dan kemudian Anda harus mengatur artikel yang bagus tentang masalah ini .customer properti pada pengontrol tampilan Anda, yang berarti Anda harus membuat properti ini bisa berubah dan Anda harus membiarkan pengontrol tampilan dibuat tanpa customerobjek . Dalam pengalaman saya ini dapat sangat menyulitkan kode Anda dan membuatnya lebih sulit untuk alasan tentang aliran aplikasi Anda. Perbarui 9/9/16: Chris Dzombak menulis

• Ini McDonald's : Untuk mengatakannya dalam kata-kata Steve Jobs tentang Microsoft: Ini McDonald's (video) !

Ini adalah alasan saya mengapa saya benar-benar tidak suka bekerja dengan storyboard. Beberapa alasan ini juga berlaku untuk XIB. Pada proyek-proyek berbasis storyboard yang telah saya kerjakan, mereka telah menghabiskan lebih banyak waktu daripada yang telah saya hemat dan mereka membuat hal-hal lebih rumit daripada lebih mudah.

Ketika saya membuat UI dan aliran aplikasi dalam kode, saya jauh lebih mengontrol apa yang sedang terjadi, lebih mudah untuk debug, lebih mudah untuk menemukan kesalahan sejak awal, lebih mudah untuk menjelaskan perubahan saya ke pengembang lain dan itu lebih mudah untuk mendukung iPhone dan iPad.

Namun, saya setuju bahwa meletakkan semua UI Anda dalam kode mungkin bukan solusi satu ukuran untuk semua proyek. Jika UI iPad Anda sangat berbeda dari UI iPhone Anda di tempat-tempat tertentu, mungkin masuk akal untuk membuat XIB hanya untuk area tersebut.

Banyak masalah yang diuraikan di atas dapat diperbaiki oleh Apple dan saya harap itulah yang akan mereka lakukan.

Hanya dua sen saya.

Pembaruan : Di Xcode 5, Apple mengambil opsi untuk membuat proyek tanpa Storyboard. Saya telah menulis sebuah skrip kecil yang memindahkan templat Xcode 4 (dengan opsi Storyboard-opt-out) ke Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

Storyboard dibuat untuk membantu pengembang memvisualisasikan aplikasi mereka dan alur aplikasi. Ini seperti memiliki banyak xib tetapi dalam satu file.

Ada pertanyaan yang mirip dengan lokasi ini. Apa perbedaan antara file .xib dan .storyboard? .

Anda juga dapat membuat transisi khusus melalui kode yang akan berubah secara dinamis jika diperlukan, seperti halnya Anda menggunakan .xibs.

PROS:

• Anda dapat mempermainkan aliran aplikasi tanpa menulis banyak, jika ada kode.
• Jauh lebih mudah untuk melihat transisi Anda antara layar dan aliran aplikasi Anda.
• Dapat juga menggunakan .xibs jika diperlukan dengan storyboard.

CONS:

• Hanya bekerja dengan iOS 5+. Tidak bekerja dengan iOS4.
• Dapat berantakan dengan mudah jika Anda memiliki aplikasi yang sangat intensif.

Sebenarnya tidak ada benar / salah ketika menggunakan satu atau yang lain, itu hanya masalah preferensi dan versi iOS apa yang ingin Anda gunakan.

Saya hanya akan menyatakan 4 alasan sederhana mengapa Anda harus menggunakan storyboard, terutama di lingkungan yang produktif di mana Anda harus bekerja dalam tim pemilik produk, manajer produk, desainer UX, dll.

1. Apple telah sangat meningkatkan bekerja dengan Storyboards. Dan mereka mendorong Anda untuk bekerja dengan mereka. Yang berarti mereka tidak akan merusak proyek Anda yang ada dengan pembaruan, mereka akan memastikan bahwa storyboard adalah bukti masa depan untuk versi XCode / iOS yang lebih baru.
2. Hasil yang lebih terlihat di waktu kurang bagi pemilik produk dan manajer, bahkan selama tahap pembuatan. Anda bahkan dapat menggunakan storyboard itu sendiri sebagai diagram alur layar dan mendiskusikannya dalam rapat.
3. Bahkan setelah aplikasi selesai (dan itu umumnya di mana siklus hidupnya dimulai) - di masa depan akan lebih cepat dan lebih mudah untuk menerapkan penyesuaian kecil . Dan ini bisa sangat mengubah beberapa aspek tata letak Anda pada saat yang sama, yang mungkin ingin Anda lihat dengan cara WYSIWYG. Alternatifnya adalah perubahan UI tulisan tangan dalam kode dan beralih bolak-balik antara IDE dan simulator untuk mengujinya, setiap kali menunggu kompilasi & pembuatan.
4. Non-pengembang dapat diajarkan untuk mengatur tata letak di storyboard dan membuat kait yang diperlukan untuk para pengembang (IBOutlets dan IBActions). Itu nilai tambah yang sangat besar karena memungkinkan para pengembang fokus pada logika dan desainer UX menerapkan perubahan mereka secara visual, tanpa harus menulis kode apa pun.

Saya tidak akan menulis CONS, karena Johannes telah mendaftar mungkin semua yang layak dalam jawabannya. Dan kebanyakan dari mereka jelas tidak layak, terutama tidak dengan perbaikan besar XCode6.

Saya tidak berpikir ada jawaban yang tepat untuk pertanyaan Anda, itu hanya masalah pengalaman pribadi dan apa yang Anda rasa lebih nyaman.

Menurut pendapat saya, Storyboard adalah hal yang hebat. Memang benar, sangat sulit untuk mengetahui mengapa aplikasi Anda mengalami crash pada saat runtime, tetapi setelah beberapa waktu dan pengalaman Anda akan menyadari bahwa itu selalu terkait dengan beberapa IBOutlet yang hilang di suatu tempat dan Anda akan dapat dengan mudah memperbaikinya.

Satu-satunya masalah sebenarnya adalah bekerja dalam tim di bawah kontrol versi dengan storyboard, pada tahap awal pengembangan itu bisa menjadi kekacauan nyata. Tetapi setelah tahap pertama itu, pembaruan UI yang benar-benar mengubah storyboard sangat jarang, dan dalam kebanyakan kasus Anda berakhir dengan konflik di bagian paling akhir xml, yang merupakan referensi segue yang biasanya memperbaiki sendiri ketika Anda membuka kembali storyboard. . Dalam kerja tim kami, kami lebih suka berurusan dengan ini daripada pengontrol tampilan berat dengan banyak kode tampilan.

Saya telah membaca banyak komentar terhadap tata letak otomatis. Dengan XCode5 semakin baik, Ini sangat bagus bahkan untuk tata letak autorotating. Dalam beberapa kasus Anda harus melakukan sesuatu dalam kode, tetapi Anda dapat dengan mudah menyalurkan kendala yang perlu Anda edit dan, pada saat itu, lakukan apa yang Anda butuhkan dalam kode Anda. Bahkan menghidupkan mereka.

Saya juga berpikir bahwa sebagian besar orang yang tidak menyukai storyboard tidak sepenuhnya mencoba memahami kekuatan segue manual manual, di mana Anda dapat benar-benar menyesuaikan (dalam satu file) cara Anda bertransisi dari satu cara ke cara lain dan juga (dengan beberapa trik) bahkan menggunakan kembali pengontrol tampilan yang dimuat sebelumnya dengan hanya memperbarui konten tampilan itu daripada sepenuhnya memuat semuanya. Pada akhirnya Anda benar-benar dapat melakukan hal yang sama seperti dalam kode, tetapi saya pikir Anda memiliki pemisahan yang lebih baik dengan storyboard, tetapi saya setuju bahwa dalam banyak hal mereka kekurangan fitur (font, gambar sebagai latar belakang warna, ... ).

Saya tidak menggunakan StoryBoard atau XIB di salah satu aplikasi saya .. tetapi membuat semuanya secara terprogram.

∆ Manfaat:

√ Anda dapat membuat jenis UI atau animasi transisi yang rumit untuk apa pun UIView.

√ Mendukung semua versi iOS. Tidak perlu khawatir tentang <iOS 5.

√ * Aplikasi Anda akan mendukung semua perangkat iPhone / iPod / iPad dalam kode Anda.

√ Anda selalu diperbarui karena Anda tahu kode yang akan selalu berfungsi.

√ * Akan berfungsi pada perangkat apa pun (baru) yang diluncurkan - Tidak perlu mengubah kode.

√ Semuanya terserah Anda. Di tempat tertentu Anda ingin mengubah sesuatu - Tidak perlu melihat ke storyboard atau xib. Cukup cari di kelas tertentu.

√ Terakhir tetapi bukan daftar - Anda tidak akan pernah lupa itu, bagaimana mengatur semuanya secara terprogram. Ini adalah hal terbaik karena Anda tahu kontrolnya sangat dalam daripada siapa pun.

_{Saya tidak pernah menemukan masalah dengan tidak menggunakan SB atau XIB karena saya baik dengan ini.}

_{* jika Anda telah mengatur bingkai objek UIKit sesuai dengan ukuran layar.}

_{PS Jika Anda masih belum melakukan hal ini - Anda mungkin menghadapi kesulitan (atau mungkin merasa membosankan) tetapi begitu Anda terbiasa dengan hal ini - itu benar-benar sebuah Permen untuk Anda.}

Jika Anda akan peduli dengan kinerja Storyboard, saksikan WWDC 2015 Sesi 407

Waktu membangun

Ketika pembangun antarmuka sedang menyusun storyboard itu melakukan dua hal pertama, itu mencoba untuk memaksimalkan kinerja aplikasi Anda dan kedua itu juga meminimalkan jumlah file pena yang dibuat.

Jika saya memiliki pengontrol tampilan dengan tampilan dan banyak sub tampilan, pembuat antarmuka, waktu pembuatan akan membuat file nib untuk pengontrol tampilan dan membuat file nib untuk tampilan.

Dengan memiliki file nib terpisah untuk pengontrol tampilan dan tampilan, ini berarti hierarki tampilan dapat dimuat sesuai permintaan.

Jalankan Waktu

Saat Anda mengalokasikan instance storyboard menggunakan storyboard UI, API, awalnya semua yang Anda alokasikan memori adalah instance storyboard UI itu sendiri.

Belum ada pengontrol tampilan.

Ketika Anda instantiate controller tampilan awal Anda itu akan memuat nib untuk controller tampilan awal itu, tetapi, sekali lagi, tidak ada hierarki tampilan telah dimuat sampai seseorang benar-benar memintanya.

Saya telah mengerjakan proyek yang cukup besar (> 20 adegan dalam bahasa storyboard), dan telah menemukan banyak keterbatasan dan harus berulang kali pergi ke dokumentasi dan pencarian google untuk melakukan sesuatu.

1. UI semua dalam satu file. Bahkan jika Anda membuat banyak storyboard, Anda masih memiliki banyak adegan / layar di setiap storyboard. Ini adalah masalah di tim menengah-besar.

2. Kedua, mereka tidak bermain dengan baik dengan Controllers Kontainer kustom yang menyematkan kontroler kontainer lain dll. Kami menggunakan MFSlideMenu dalam aplikasi Tab dan adegan memiliki tabel. Ini hampir tidak mungkin dilakukan dengan storyboard. Setelah menghabiskan berhari-hari, saya terpaksa melakukan cara XIB di mana ada kontrol penuh.

3. IDE tidak memungkinkan untuk memilih kontrol dalam keadaan diperbesar. Jadi, dalam proyek besar, zoom-out sebagian besar untuk mendapatkan tampilan tingkat tinggi dan tidak lebih.

Saya akan menggunakan storyboard untuk aplikasi yang lebih kecil dengan ukuran tim kecil dan menggunakan pendekatan XIB untuk tim / proyek menengah-besar.

Jika Anda ingin menggunakan kembali beberapa UI di beberapa pengontrol tampilan maka Anda harus menggunakan XIB