Antarmuka Pengguna iOS: Papan Cerita vs. NIB vs. Kode Kustom

Saya sering mendengar pengembang iOS menanyakan beberapa varian dari pertanyaan kunci yang sama:

Apa cara terbaik untuk mengembangkan UI di iOS: melalui Storyboard, NIB, atau kode?

Jawaban atas pertanyaan ini, secara eksplisit atau implisit, cenderung mengasumsikan bahwa ada pilihan eksklusif yang harus dibuat, pilihan yang sering dibahas di muka, sebelum pengembangan.

Saya berpendapat bahwa jawabannya harus berupa satu atau lebih pertanyaan balasan .

Apa mobil "terbaik"?

Mari saya jelaskan dengan contoh di luar topik. Katakanlah saya ingin membeli mobil dan saya mengajukan satu pertanyaan sederhana: "Apa pilihan terbaik?"

Bisakah Anda benar-benar menjawab dengan menyarankan model, atau bahkan merek? Tidak mungkin, kecuali jika Anda menyarankan Ferrari. Sebagai gantinya, Anda mungkin akan menjawab dengan beberapa pertanyaan lain, seperti:

• Apa anggaran Anda?
• Berapa banyak kursi yang Anda butuhkan?
• Apakah Anda peduli dengan konsumsi bahan bakar?
• Bagaimana perasaan Anda tentang mobil sport?

Jelas bahwa tidak ada mobil yang baik atau buruk kecuali jika ditempatkan dalam konteks yang tepat—hanya ada mobil yang baik atau buruk berdasarkan kebutuhan tertentu.

Kembali ke Desain UI iOS

Sama seperti pertanyaan mobil kami, pertanyaan "Apa cara terbaik untuk mengembangkan UI iOS" tidak memiliki konteks. Dan cukup mengejutkan, jawabannya tidak perlu menjadi kasus umum.

Secara garis besar, ada tiga jenis pendekatan desain antarmuka pengguna yang dapat Anda ambil, masing-masing dengan pro dan kontra, penggemar dan pembencinya:

• iOS Storyboards : Alat visual untuk meletakkan beberapa tampilan aplikasi dan transisi di antara mereka.
• NIB (atau XIB) : Setiap file NIB sesuai dengan elemen tampilan tunggal dan dapat diletakkan di Interface Builder, menjadikannya alat visual juga. Perhatikan bahwa nama "NIB" berasal dari ekstensi file (sebelumnya .nib dan sekarang .xib, meskipun pengucapan lama tetap ada).
• Kode Kustom : yaitu, tidak ada alat GUI, melainkan, menangani semua pemosisian kustom, animasi, dll. secara terprogram.

Tak satu pun dari opsi ini secara universal lebih baik daripada yang lain (terlepas dari apa yang mungkin Anda dengar).

Storyboard, misalnya, adalah tambahan terbaru untuk toolkit UI iOS. Saya telah diberitahu bahwa mereka adalah masa depan, bahwa mereka akan menggantikan NIB dan UI kode khusus. Saya melihat Storyboard sebagai alat yang berguna, tetapi bukan pengganti sebagai pelengkap untuk NIB dan kode khusus. Papan cerita adalah pilihan yang tepat dalam beberapa, tetapi tidak semua situasi.

Selanjutnya, mengapa Anda harus tetap berpegang pada satu opsi secara statis ketika Anda dapat menggunakan semuanya (dalam proyek yang sama), memilih mekanisme yang paling sesuai dengan masalah spesifik yang dihadapi?

Ini adalah pertanyaan yang menurut pendapat saya, dapat digeneralisasikan pada tingkat yang lebih tinggi, dan yang jawabannya berperingkat tinggi dalam daftar prinsip pengembangan perangkat lunak saya: Tidak ada bahasa, kerangka kerja, atau teknologi universal yang merupakan pilihan terbaik universal untuk setiap masalah pengembangan perangkat lunak. Hal yang sama berlaku untuk desain UI iOS.

Dalam tutorial pengembangan iOS ini, kita akan menjelajahi masing-masing metode ini dan memperkenalkan kasus penggunaan di mana mereka harus dan tidak boleh digunakan, serta cara-cara di mana mereka dapat digabungkan bersama.

Papan Cerita iOS

Kesalahan klasik pemula adalah membuat satu Storyboard iOS besar-besaran di seluruh proyek. Saya juga membuat kesalahan ini ketika saya pertama kali mulai bekerja dengan Storyboards (mungkin karena ini adalah rute yang menggoda untuk diambil).

Sesuai namanya, Storyboard adalah papan dengan sebuah cerita untuk diceritakan . Seharusnya tidak digunakan untuk mencampur cerita yang tidak terkait menjadi satu volume besar. Sebuah storyboard harus berisi pengontrol tampilan yang secara logis terkait satu sama lain—yang tidak berarti setiap pengontrol tampilan.

Misalnya, masuk akal untuk menggunakan Storyboard saat menangani:

• Satu set tampilan untuk otentikasi dan pendaftaran.
• Alur entri pesanan multi-langkah.
• Alur seperti penyihir (yaitu, tutorial).
• Kumpulan tampilan detail master (mis., daftar profil, detail profil).

Sementara itu, Storyboards besar harus dihindari, termasuk Storyboards di seluruh aplikasi tunggal (kecuali aplikasinya relatif sederhana). Sebelum kita masuk lebih dalam, mari kita lihat alasannya.

Kebodohan Papan Cerita iOS Besar

Papan Cerita Besar, selain sulit untuk dijelajahi dan dipelihara, menambahkan lapisan kompleksitas ke lingkungan tim: ketika beberapa pengembang bekerja pada file papan cerita yang sama pada saat yang sama, konflik kontrol sumber tidak dapat dihindari . Dan sementara storyboard secara internal direpresentasikan sebagai file teks (file XML, sebenarnya), penggabungan biasanya tidak sepele.

Ketika pengembang melihat kode sumber, mereka menganggapnya sebagai makna semantik. Jadi, saat menggabungkan secara manual, mereka dapat membaca dan memahami kedua sisi konflik dan bertindak sesuai dengan itu. Sebaliknya, storyboard adalah file XML yang dikelola oleh Xcode, dan arti setiap baris kode tidak selalu mudah dipahami.

Mari kita ambil contoh yang sangat sederhana: katakanlah dua pengembang yang berbeda mengubah posisi UILabel (menggunakan autolayout), dan yang terakhir mendorong perubahannya, menghasilkan konflik seperti ini (perhatikan atribut id yang bertentangan):

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

id itu sendiri tidak memberikan indikasi apa pun tentang signifikansi sebenarnya, jadi Anda tidak memiliki apa pun untuk dikerjakan. Satu-satunya solusi yang berarti adalah memilih salah satu dari dua sisi konflik dan membuang yang lain. Apakah akan ada efek samping? Siapa tahu? Bukan kamu.

Untuk meringankan masalah desain antarmuka iOS ini, menggunakan beberapa storyboard dalam proyek yang sama adalah pendekatan yang disarankan.

Kapan Menggunakan Storyboard

Storyboard paling baik digunakan dengan beberapa pengontrol tampilan yang saling berhubungan, karena penyederhanaan utamanya adalah transisi di antara pengontrol tampilan. Sampai tingkat tertentu, mereka dapat dianggap sebagai komposisi NIB dengan aliran visual dan fungsional antara pengontrol tampilan.

Selain memudahkan alur navigasi, keuntungan lain yang berbeda adalah mereka menghilangkan kode boilerplate yang diperlukan untuk memunculkan, mendorong, menampilkan, dan mengabaikan pengontrol tampilan. Selain itu, pengontrol tampilan dialokasikan secara otomatis, jadi tidak perlu init alloc manual.

Terakhir, meskipun Storyboard paling baik digunakan untuk skenario yang melibatkan banyak pengontrol tampilan, penggunaan Storyboard juga dapat dipertahankan saat bekerja dengan pengontrol tampilan tabel tunggal karena tiga alasan:

• Kemampuan untuk merancang prototipe sel tabel di tempat membantu menyatukan bagian-bagiannya.
• Beberapa templat sel dapat dirancang di dalam pengontrol tampilan tabel induk.
• Dimungkinkan untuk membuat tampilan tabel statis (tambahan yang sudah lama ditunggu-tunggu yang sayangnya hanya tersedia di Storyboard).

Orang dapat berargumen bahwa beberapa templat sel juga dapat dirancang menggunakan NIB. Sebenarnya, ini hanya masalah preferensi: beberapa pengembang lebih suka memiliki semuanya di satu tempat, sementara yang lain tidak peduli.

Kapan Tidak Menggunakan Papan Cerita iOS

Beberapa kasus:

• Tampilan memiliki tata letak yang rumit atau dinamis, paling baik diterapkan dengan kode.
• Tampilan sudah diimplementasikan dengan NIB atau kode.

Dalam kasus tersebut, kita dapat membiarkan tampilan keluar dari Storyboard atau menyematkannya di pengontrol tampilan. Yang pertama merusak alur visual Storyboard, tetapi tidak memiliki implikasi fungsional atau pengembangan yang negatif. Yang terakhir mempertahankan aliran visual ini, tetapi memerlukan upaya pengembangan tambahan karena tampilan tidak terintegrasi ke dalam pengontrol tampilan: itu hanya disematkan sebagai komponen, oleh karena itu pengontrol tampilan harus berinteraksi dengan tampilan daripada mengimplementasikannya.

Pro dan Kontra Umum

Sekarang setelah kita mengetahui kapan Storyboard berguna dalam desain UI iOS, dan sebelum kita beralih ke NIB dalam tutorial ini, mari kita lihat kelebihan dan kekurangannya secara umum.

Pro: Performa

Secara intuitif, Anda dapat mengasumsikan bahwa ketika Storyboard dimuat, semua pengontrol tampilannya segera dibuat. Untungnya, ini hanya abstraksi dan tidak benar untuk implementasi sebenarnya: sebagai gantinya, hanya pengontrol tampilan awal, jika ada, yang dibuat. Pengontrol tampilan lainnya dipakai secara dinamis, baik ketika segue dilakukan atau secara manual dari kode.

Pro: Prototipe

Storyboard menyederhanakan prototyping dan mocking antarmuka pengguna dan alur. Sebenarnya, aplikasi prototipe kerja lengkap dengan tampilan dan navigasi dapat dengan mudah diimplementasikan menggunakan Storyboard dan hanya beberapa baris kode.

Kontra: Dapat digunakan kembali

Dalam hal memindahkan atau menyalin, Storyboard iOS diposisikan dengan buruk. Storyboard harus dipindahkan bersama dengan semua pengontrol tampilan dependennya. Dengan kata lain, pengontrol tampilan tunggal tidak dapat diekstraksi dan digunakan kembali secara individual di tempat lain sebagai entitas independen tunggal; itu tergantung pada Storyboard lainnya untuk berfungsi.

Kontra: Aliran data

Data sering kali perlu diteruskan di antara pengontrol tampilan saat aplikasi bertransisi. Namun, aliran visual Storyboard rusak dalam kasus ini karena tidak ada jejak yang terjadi di Interface Builder. Storyboard menangani penanganan aliran antara pengontrol tampilan, tetapi bukan aliran data. Jadi, pengontrol tujuan harus dikonfigurasi dengan kode, mengesampingkan pengalaman visual.

Dalam kasus seperti itu, kita harus bergantung pada prepareForSegue:sender , dengan kerangka if/else-if seperti ini:

 - (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 ... }

Saya menemukan pendekatan ini rawan kesalahan dan tidak perlu bertele-tele.

NIB

NIB adalah cara lama (er) untuk melakukan desain antarmuka iOS.

Dalam hal ini, "tua" tidak berarti "buruk", "usang", atau "usang". Faktanya, penting untuk dipahami bahwa iOS Storyboard bukanlah pengganti universal untuk NIB; mereka hanya menyederhanakan implementasi UI dalam beberapa kasus.

Dengan NIB, tampilan arbitrer apa pun dapat dirancang, yang kemudian dapat dilampirkan pengembang ke pengontrol tampilan sesuai kebutuhan.

Jika kami menerapkan desain berorientasi objek ke UI kami, maka masuk akal untuk memecah tampilan pengontrol tampilan menjadi modul terpisah , masing-masing diimplementasikan sebagai tampilan dengan file NIB-nya sendiri (atau dengan beberapa modul yang dikelompokkan ke dalam file yang sama). Keuntungan yang jelas dari pendekatan ini adalah bahwa setiap komponen lebih mudah untuk dikembangkan, lebih mudah untuk diuji, dan lebih mudah untuk di-debug.

NIB berbagi masalah konflik penggabungan yang kami lihat dengan Storyboard, tetapi pada tingkat yang lebih rendah, karena file NIB beroperasi pada skala yang lebih kecil.

Kapan Menggunakan NIB untuk Desain UI iOS

Bagian dari semua kasus penggunaan adalah:

• Tampilan modal
• Tampilan login dan registrasi sederhana
• Pengaturan
• Jendela munculan
• Template tampilan yang dapat digunakan kembali
• Templat sel tabel yang dapat digunakan kembali

Sementara itu…

Kapan Tidak Menggunakan NIB

Anda harus menghindari penggunaan NIB untuk:

• Tampilan dengan konten dinamis, di mana tata letak berubah secara signifikan tergantung pada konten.
• Tampilan yang secara alami tidak mudah didesain di Interface Builder.
• Lihat pengontrol dengan transisi rumit yang dapat disederhanakan dengan Storyboarding.

Pro dan Kontra Umum

Secara lebih umum, mari kita telusuri pro dan kontra menggunakan NIB.

Pro: Dapat digunakan kembali

NIB berguna ketika tata letak yang sama dibagikan di beberapa kelas.

Sebagai kasus penggunaan sederhana, template tampilan yang berisi nama pengguna dan bidang teks sandi dapat diimplementasikan dengan tampilan TTLoginView TTSignupView , yang keduanya dapat berasal dari NIB yang sama. TTLoginView harus menyembunyikan bidang kata sandi, dan keduanya harus menentukan label statis yang sesuai (seperti 'Masukkan nama pengguna Anda' vs 'Masukkan kata sandi Anda'), tetapi label tersebut akan memiliki fungsi dasar yang sama dan tata letak yang serupa.

Pro & Kontra: Performa

NIB dimuat dengan malas, jadi mereka tidak menggunakan memori sampai mereka harus melakukannya. Meskipun ini bisa menjadi keuntungan, ada latensi pada proses pemuatan yang lambat, menjadikannya sesuatu yang merugikan juga.

Kode Kustom iOS (UI Terprogram)

Setiap desain antarmuka iOS yang dapat dilakukan dengan Storyboard dan NIB juga dapat diimplementasikan dengan kode mentah (tentu saja ada saatnya, ketika pengembang tidak memiliki kemewahan seperangkat alat yang begitu kaya).

Mungkin yang lebih penting, apa yang tidak dapat dilakukan dengan NIB dan Storyboard selalu dapat diimplementasikan dengan kode—tentu saja, asalkan itu layak secara teknis. Cara lain untuk melihatnya adalah bahwa NIB dan Storyboard diimplementasikan dengan kode, sehingga fungsionalitasnya secara alami akan menjadi subset. Mari kita langsung ke pro dan kontra.

Pro: Di Balik Terpal

Keuntungan terbesar dari membuat UI iOS secara terprogram: jika Anda tahu cara membuat kode antarmuka pengguna, maka Anda tahu apa yang terjadi di balik layar , sedangkan hal yang sama belum tentu berlaku untuk NIB dan Storyboard.

Untuk membuat perbandingan: kalkulator adalah alat yang berguna. Tapi itu bukan hal yang buruk untuk mengetahui bagaimana melakukan perhitungan secara manual.

Ini tidak terbatas pada iOS, tetapi untuk alat RAD visual apa pun (misalnya, Visual Studio dan Delphi, hanya untuk beberapa nama). Lingkungan Visual HTML RAD mewakili kasus batas yang khas: mereka digunakan untuk menghasilkan kode (sering ditulis dengan buruk), mengklaim bahwa tidak diperlukan pengetahuan HTML, dan bahwa semuanya dapat dilakukan secara visual. Tetapi tidak ada pengembang web yang akan mengimplementasikan halaman web tanpa mengotori tangannya: mereka tahu bahwa menangani HTML dan CSS mentah secara manual akan menghasilkan kode yang lebih modular dan lebih efisien.

Jadi, menguasai pengkodean antarmuka pengguna iOS memberi Anda lebih banyak kontrol dan kesadaran yang lebih besar tentang bagaimana bagian-bagian ini cocok bersama, yang meningkatkan batas atas Anda sebagai pengembang.

Pro: Ketika Kode adalah Satu-satunya Pilihan

Ada juga kasus di mana kode iOS khusus adalah satu-satunya pilihan untuk desain UI. Tata letak dinamis, di mana elemen tampilan dipindahkan dan alur atau tata letak menyesuaikan secara signifikan berdasarkan konten, adalah contoh umum.

Pro: Gabungkan Konflik

Sementara NIB dan Storyboard menderita secara signifikan dari konflik gabungan, kode tidak memiliki kesalahan yang sama. Semua kode memiliki makna semantik, sehingga menyelesaikan konflik tidak lebih sulit dari biasanya.

Con: Prototyping

Sulit untuk mengetahui bagaimana tata letak akan terlihat sampai Anda melihatnya beraksi. Selanjutnya, Anda tidak dapat memposisikan tampilan dan kontrol secara visual, jadi menerjemahkan spesifikasi tata letak menjadi tampilan nyata dapat memakan waktu lebih lama, dibandingkan dengan NIB dan Storyboard yang memberi Anda pratinjau langsung tentang bagaimana segala sesuatunya akan dirender.

Kontra: Pemfaktoran Ulang

Memfaktorkan ulang kode yang telah lama ditulis atau oleh orang lain juga menjadi jauh lebih rumit: ketika elemen diposisikan dan dianimasikan dengan metode khusus dan angka ajaib, sesi debugging bisa menjadi sulit.

Pro: Performa

Dalam hal kinerja, Storyboard dan NIB tunduk pada overhead pemuatan dan penguraian; dan pada akhirnya, mereka secara tidak langsung diterjemahkan ke dalam kode. Tak perlu dikatakan, ini tidak terjadi dengan UI yang dibuat dengan kode.

Pro: Dapat digunakan kembali

Setiap tampilan yang diimplementasikan secara terprogram dapat dirancang dengan cara yang dapat digunakan kembali. Mari kita lihat beberapa kasus penggunaan:

• Dua atau lebih pandangan memiliki perilaku yang sama, tetapi mereka sedikit berbeda. Kelas dasar dan dua subkelas menyelesaikan masalah dengan elegan.
• Sebuah proyek harus bercabang, dengan tujuan menciptakan basis kode tunggal, tetapi menghasilkan dua (atau lebih) aplikasi yang berbeda, masing-masing dengan penyesuaian khusus.

Proses desain UI yang sama akan jauh lebih rumit dengan NIB dan Storyboard. File template tidak mengizinkan pewarisan, dan solusi yang memungkinkan terbatas pada hal berikut:

• Gandakan file NIB dan Storyboard. Setelah itu, mereka memiliki kehidupan yang terpisah dan tidak ada hubungan dengan file aslinya.
• Ganti tampilan dan perilaku dengan kode, yang mungkin berfungsi dalam kasus sederhana, tetapi dapat menyebabkan komplikasi yang signifikan pada kasus lain. Penggantian berat dengan kode juga dapat membuat desain visual tidak berguna dan berkembang menjadi sumber masalah yang konstan, misalnya, ketika kontrol tertentu ditampilkan satu arah di Interface Builder, tetapi terlihat sangat berbeda saat aplikasi sedang berjalan.

Kapan Menggunakan Kode

Ini sering kali merupakan panggilan yang baik untuk menggunakan kode khusus untuk desain antarmuka pengguna iOS ketika Anda memiliki:

• Tata letak dinamis.
• Tampilan dengan efek, seperti sudut membulat, bayangan, dll.
• Setiap kasus di mana menggunakan NIB dan Storyboard rumit atau tidak layak.

Kapan Tidak Menggunakan Kode

Secara umum, UI yang dibuat dengan kode selalu dapat digunakan. Mereka jarang merupakan ide yang buruk, jadi saya akan menempatkan di sini.

Meskipun NIB dan Storyboard membawa beberapa keuntungan ke meja, saya merasa tidak ada kerugian yang masuk akal bahwa saya akan memasukkan daftar untuk mencegah penggunaan kode (kecuali, mungkin, kemalasan).

Satu Proyek, Banyak Alat

Storyboard, NIB, dan kode adalah tiga alat berbeda untuk membangun antarmuka pengguna iOS. Kami beruntung memiliki mereka. Fanatik UI terprogram mungkin tidak akan mempertimbangkan dua opsi lainnya: kode memungkinkan Anda melakukan semua yang mungkin secara teknis, sedangkan alternatifnya memiliki keterbatasan. Untuk pengembang lainnya di luar sana, pisau tentara Xcode menyediakan tiga alat yang dapat digunakan sekaligus, dalam proyek yang sama, secara efektif.

Bagaimana, Anda bertanya? Bagaimanapun yang kau suka. Berikut adalah beberapa pendekatan yang mungkin:

• Kelompokkan semua layar terkait ke dalam grup terpisah, dan terapkan setiap grup dengan Storyboard yang berbeda.
• Rancang sel tabel yang tidak dapat digunakan kembali di tempat dengan Storyboard, di dalam pengontrol tampilan tabel.
• Rancang sel tabel yang dapat digunakan kembali dalam NIB untuk mendorong penggunaan kembali dan menghindari pengulangan, tetapi muat NIB ini melalui kode khusus.
• Rancang tampilan kustom, kontrol, dan objek di antara menggunakan NIB.
• Gunakan kode untuk tampilan yang sangat dinamis, dan lebih umum lagi untuk tampilan yang tidak mudah diterapkan melalui Storyboard dan NIB, sementara menampilkan transisi tampilan di Storyboard.

Sebagai penutup, mari kita lihat satu contoh terakhir yang menyatukan semuanya.

Kasus Penggunaan Sederhana

Katakanlah kami ingin mengembangkan aplikasi perpesanan dasar dengan beberapa tampilan berbeda:

• Daftar teman yang diikuti (dengan templat sel yang dapat digunakan kembali untuk menjaga UI tetap konsisten di seluruh daftar di masa mendatang).
• Tampilan detail profil, disusun menjadi beberapa bagian terpisah (termasuk informasi profil, statistik, dan bilah alat).
• Daftar pesan yang dikirim dan diterima dari seorang teman.
• Formulir pesan baru.
• Tampilan tag cloud yang menampilkan berbagai tag yang digunakan dalam pesan pengguna, dengan ukuran masing-masing tag proporsional dengan frekuensi penggunaannya.

Selain itu, kami ingin tampilan mengalir sebagai berikut:

• Mengklik item dalam daftar teman yang diikuti akan menampilkan detail profil teman yang relevan.
• Detail profil menunjukkan nama profil, alamat, statistik, daftar singkat pesan terbaru, dan toolbar.

Untuk mengimplementasikan aplikasi iOS ini, ketiga alat UI kami akan berguna, karena kami dapat menggunakan:

• Storyboard dengan empat pengontrol tampilan (daftar, detail, daftar pesan, dan formulir pesan baru).
• File NIB terpisah untuk templat sel daftar profil yang dapat digunakan kembali.
• Tiga file NIB terpisah untuk tampilan detail profil, satu untuk setiap bagian terpisah yang menyusunnya (detail profil, statistik, tiga pesan terakhir), untuk memungkinkan perawatan yang lebih baik. NIB ini akan dipakai sebagai tampilan dan kemudian ditambahkan ke pengontrol tampilan.
• Kode khusus untuk tampilan tag cloud. Tampilan ini adalah contoh tipikal yang tidak dapat dirancang di Interface Builder, baik melalui StoryBoards maupun NIB. Sebaliknya, itu sepenuhnya diimplementasikan melalui kode. Untuk mempertahankan alur visual Storyboard, kami memilih untuk menambahkan pengontrol tampilan kosong ke Storyboard, menerapkan tampilan tag cloud sebagai tampilan mandiri, dan secara terprogram menambahkan tampilan ke pengontrol tampilan. Jelas, tampilan juga dapat diimplementasikan di dalam pengontrol tampilan daripada sebagai tampilan yang berdiri sendiri, tetapi kami memisahkannya agar dapat digunakan kembali dengan lebih baik.

Mock-up yang sangat mendasar mungkin terlihat seperti:

Dengan itu, kami telah menguraikan konstruksi dasar aplikasi iOS yang cukup canggih yang tampilan intinya menyatukan tiga pendekatan utama kami untuk desain UI. Ingat: tidak ada keputusan biner yang harus dibuat, karena setiap alat memiliki kekuatan dan kelemahannya.

Membungkus

Seperti yang diperiksa dalam turtorial ini, Storyboard menambahkan penyederhanaan yang nyata pada desain UI iOS dan aliran visual. Mereka juga menghilangkan kode boilerplate; tetapi semua ini ada harganya, dibayar dengan fleksibilitas. NIB, sementara itu, menawarkan lebih banyak fleksibilitas dengan berfokus pada satu tampilan, tetapi tanpa aliran visual. Solusi yang paling fleksibel, tentu saja, adalah kode, yang cenderung agak tidak ramah dan secara inheren non-visual.

Jika artikel ini menggelitik Anda, saya sangat merekomendasikan menonton debat hebat dari Ray Wenderlich, 55 menit yang dihabiskan dengan baik untuk diskusi tentang NIB, Storyboard, dan UIS yang dibuat dengan kode.

Sebagai penutup, saya ingin menekankan satu hal: Hindari penggunaan alat desain UI iOS yang tidak tepat dengan cara apa pun . Jika tampilan tidak dapat didesain dengan Storyboard, atau jika dapat diimplementasikan dengan NIB atau kode dengan cara yang lebih sederhana, jangan gunakan Storyboard. Demikian pula, jika tampilan tidak dapat didesain menggunakan NIB, jangan gunakan NIB. Aturan-aturan ini, meskipun sederhana, akan sangat berguna dalam pendidikan Anda sebagai pengembang.