Storyboard ne zaman ve XIB'ler ne zaman kullanılır?

Bir iOS projesinde film şeritlerinin ne zaman kullanılacağı ve XIB'lerin ne zaman kullanılacağı hakkında herhangi bir kural var mı? her birinin artıları ve eksileri nelerdir ve her biri hangi durumlara uygundur?

Yakınlarda, dinamik UI öğeleri (harita pinleri gibi) tarafından kontrol edilen görüntü denetleyicilerine sahip olduğunuzda storyboard segues kullanmanın o kadar temiz olmadığını anlayabiliyorum.

XIB'leri yoğun bir şekilde kullandım ve Storyboard'ları kullanarak iki projeyi tamamladım. Benim öğrendiklerim:

• Görsel senaryo taslakları, az ve orta sayıda ekrana sahip olan ve görünümler arasında nispeten basit gezinme olan uygulamalar için iyidir.
• Aralarında çok sayıda görünümünüz ve aralarında çok fazla gezinme varsa, Storyboard görünümü kafa karıştırıcı hale gelir ve temiz tutmak için çok fazla çalışma yapar.
• Birden fazla geliştiriciye sahip büyük bir proje için Öykü Tablolarını kullanmam çünkü UI'niz için tek bir dosyanız var ve kolayca paralel çalışamıyor.
• Büyük uygulamaların birden fazla storyboard dosyasına bölünmesi faydalı olabilir, ancak bunu denemedim. Bu cevap film şeridi arasında nasıl segue yapılacağını gösterir.
• Hala XIB'lere ihtiyacınız var: Her iki Storyboard projemde de XIB'leri özel tablo hücreleri için kullanmak zorunda kaldım.

Sanırım Storyboard'lar kullanıcı arayüzü uygulaması için doğru yönde atılmış bir adım ve Apple'ın bunları gelecekteki iOS sürümlerinde genişleteceğini umuyorum. Ancak "tek dosya" sorununu çözmeleri gerekiyor, aksi takdirde daha büyük projeler için çekici olmayacaklar.

Küçük boyutlu bir uygulama başlatırsam ve yalnızca iOS5 uyumluluğunu karşılayabilirsem, Storyboard'ları kullanırdım. Diğer tüm durumlarda XIB'lere bağlı kalıyorum.

Güncelleme 1/12/2016 : 2016 ve hala kullanıcı arayüzlerimi Storyboard'larda değil kodda düzenlemeyi tercih ediyorum. Bununla birlikte, Storyboard'lar uzun bir yol kat etti. 2016'da artık geçerli olmayan bu yazıdan tüm noktaları kaldırdım.

Güncelleme 4/24/2015 : İlginçtir ki Apple, Peter Steinberger'in fark ettiği gibi Storyboard'ları yakın zamanda açık kaynaklı ResearchKit'te bile kullanmıyor ("Interface Builder" alt başlığı altında).

Güncelleme 6/10/2014 : Apple beklendiği gibi Storyboard'ları ve Xcode'u geliştirmeye devam ediyor. İOS 7 ve sonraki sürümlere uygulanan bazı noktalar artık iOS 8 için geçerli değildir (ve şimdi böyle işaretlenmiştir). Öyleyse Storyboard'ların doğal olarak hala kusurları olsa da, tavsiyemi mantıklı olan yerlerde seçici olarak kullanmak için kullanmamaya revize ediyorum .

Şimdi iOS 9 çıktığında bile, karşısındaStoryboard'ları kullanmaya karar verirken dikkatli olmak. İşte nedenlerim:

• Storyboard'lar derleme zamanında değil, çalışma zamanında başarısız olur : Segue adında bir yazım hatası var mı veya film şeridinize yanlış mı bağladınız? Çalışma zamanında patlar. Film şeridinizde artık bulunmayan özel bir UIViewController alt sınıfı mı kullanıyorsunuz? Çalışma zamanında patlar. Kodda böyle şeyler yaparsanız, derleme zamanında onları erken yakalayacaksınız. Güncelleme : Yeni aracım StoryboardLint çoğunlukla bu sorunu çözüyor.

• Görsel senaryo taslakları hızla karışıyor : Projeniz büyüdükçe, görsel senaryo taslağınızda gezinmek giderek zorlaşıyor. Ayrıca, birden çok görünüm denetleyicisinin diğer birden çok görünüm denetleyicisine birden fazla seguyonu varsa, film şeridiniz hızla bir kase spagetti gibi görünmeye başlar ve aradığınız görünüm denetleyicisini bulmak için kendinizi yakınlaştırıp uzaklaştırdığınızı ve her yere kaydırdığınızı göreceksiniz. ve hangi segue nereye işaret eder bulmak için. Güncelleme : Bu sorun çoğunlukla, Pilky ve Robert Brown'un bu makalesinde anlatıldığı gibi, Storyboard'unuzu birden fazla Storyboard'a bölerek çözülebilir .

• Görsel senaryo taslakları bir ekipte çalışmayı zorlaştırır : Projeniz için genellikle yalnızca bir tane büyük hikaye panosu dosyanız olduğundan, birden fazla geliştiricinin bu dosyada düzenli olarak değişiklik yapması baş ağrısı olabilir: Değişikliklerin birleştirilmesi ve çakışmaların çözülmesi gerekir. Bir çakışma meydana geldiğinde, bunu nasıl çözeceğinizi söylemek zor: Xcode, film şeridi XML dosyasını oluşturur ve bir insanın onu düzenlemek yerine, okuması gerektiği düşünülerek gerçekten tasarlanmamıştır.

• Storyboard'lar kod incelemelerini zorlaştırır veya neredeyse imkansız hale getirir : Akran kodu incelemeleri ekibinizde yapmak için harika bir şeydir. Ancak, bir film şeridinde değişiklik yaptığınızda, bu değişiklikleri farklı bir geliştiriciyle incelemek neredeyse imkansızdır. Çekebileceğiniz tek şey büyük bir XML dosyasının bir farkıdır. Gerçekten neyin değiştiğini ve bu değişikliklerin doğru olup olmadığını veya bir şeyi bozup bozmadıklarını çözmek gerçekten zor.

• Storyboard'lar kodun yeniden kullanılmasını engeller : iOS projelerimde, genellikle uygulama boyunca tutarlı bir görünüm ve his vermek için kullandığım tüm renkleri, yazı tiplerini, kenar boşluklarını ve iç metinleri içeren bir sınıf oluştururum: tüm uygulama için bu değerlerden herhangi birini ayarlayın. Film şeridinde bu tür değerleri ayarlarsanız, bunları çoğaltırsınız ve değiştirmek istediğiniz her olayı bulmanız gerekir. Birini özlemenin şansı yüksektir, çünkü film şeridinde arama ve değiştirme yoktur.

• Storyboard'lar sürekli bağlam anahtarları gerektirir : Kendimi kodda hikaye tahtalarından çok daha hızlı çalışır ve gezinirken buluyorum. Uygulamanız film şeritlerini kullandığında, bağlamınızı sürekli olarak değiştirirsiniz: "Ah, farklı bir görünüm denetleyicisi yüklemek için bu tablo görünümü hücresine hafifçe dokunmak istiyorum. Şimdi film şeridini açmam, doğru görünüm denetleyicisini bulmam, yeni bir segue oluşturmam gerekiyor diğer görünüm denetleyicisine (ben de bulmak zorundayım), segue'e bir ad verin, o adı hatırlayın (film şeritlerinde sabitleri veya değişkenleri kullanamıyorum), koda geri dönün ve umarım adını yanlış yazmıyorum Benim için bu 3 kod satırını tam burada olduğum yerde yazabilseydim! " Hayır, eğlenceli değil. Kod ve film şeridi (ve klavye ve fare arasında) arasında geçiş yapmak hızlı bir şekilde eskimiş ve sizi yavaşlatır.

• Görsel senaryo taslaklarının yeniden düzenlenmesi zordur : Kodunuzu yeniden düzenlediğinizde, bunun senaryo taslağınızın beklentilerine uyduğundan emin olmanız gerekir. Film şeridinizde bir şeyleri taşıdığınızda, çalışma zamanında yalnızca kodunuzla hala çalışıyorsa öğrenirsiniz. Sanki iki dünyayı senkronize tutmak zorundaymışım gibi geliyor. Gevrek hissettiriyor ve alçakgönüllü görüşüme göre değişimi caydırıyor.

• Görsel senaryo taslakları daha az esnektir : Kod olarak, temelde istediğiniz her şeyi yapabilirsiniz! Görsel senaryo taslakları ile, kodda yapabileceklerinizin bir alt kümesiyle sınırlı olursunuz. Özellikle animasyonlar ve geçişler ile bazı gelişmiş şeyler yapmak istediğinizde, kendinizi çalıştırabilmeniz için “storyboard ile mücadele” bulacaksınız.

• Görsel senaryo taslakları, özel görünüm denetleyicilerinin türünü değiştirmenize izin vermez : UITableViewControllera UICollectionViewController? Yoksa bir ovaya UIViewControllermı? Bir Storyboard'da mümkün değil. Eski görünüm denetleyicisini silmeli ve yeni bir tane oluşturmalı ve tüm sekmeleri yeniden bağlamalısınız. Kodda böyle bir değişiklik yapmak çok daha kolay.

• Film şeritleri projenize iki ekstra yükümlülük ekler : (1) Film şeridi XML'sini oluşturan Storyboard Düzenleyici aracı ve (2) XML'yi ayrıştıran ve bundan UI ve denetleyici nesneleri oluşturan çalışma zamanı bileşeni. Her iki parçada da düzeltemeyeceğiniz hatalar olabilir.

• Görsel senaryo taslakları aşağıdakilere bir alt görünüm eklemenize izin vermezUIImageView : Nedenini kim bilir?

• Film şeritleri, tek tek Görünümler (-Kontrolör) için Otomatik Mizanpaj'ı etkinleştirmenize izin vermez : Bir Film şeridindeki Otomatik Mizanpaj seçeneğini işaretleyerek / işaretini kaldırarak, değişiklik Film şeridindeki TÜM denetleyicilere uygulanır. (Bu nokta için Sava Mazăre'a teşekkürler!)

• Storyboard'ların geriye dönük uyumluluğu kırma riski daha yüksektir : Xcode bazen Storyboard dosya biçimini değiştirir ve bugün oluşturduğunuz Storyboard dosyalarını birkaç yıl hatta aylar sonra açabileceğinizi garanti etmez. (Bu nokta için thoughtadvances'a teşekkürler. Orijinal yoruma bakın )

• Storyboard'lar kodunuzu daha karmaşık hale getirebilir : Görünüm denetleyicilerinizi kodda oluşturduğunuzda init, örneğin özel yöntemler oluşturabilirsiniz initWithCustomer:. Bu şekilde, customergörünüm denetleyicinizin içini değiştirilemez hale getirebilir ve bu görünüm denetleyicisinin customernesne olmadan oluşturulamayacağından emin olabilirsiniz . Storyboard'ları kullanırken bu mümkün değildir. prepareForSegue:sender:Yöntemin çağrılmasını beklemeniz gerekir ve daha sonra customerözelliği görünüm denetleyicinizde ayarlamanız gerekir; bu, bu özelliği değiştirilebilir hale getirmeniz ve görünüm denetleyicisinin customernesne olmadan oluşturulmasına izin vermeniz gerektiği anlamına gelir. . Deneyimlerime göre bu, kodunuzu büyük ölçüde karmaşıklaştırabilir ve uygulamanızın akışı hakkında akıl yürütmeyi zorlaştırır. 9/9/16 Güncellemesi: Chris Dzombak bu sorun hakkında harika bir makale yazdı .

• Bu McDonald's : Steve Jobs'un Microsoft hakkındaki sözlerinde söylemek: McDonald's (video) !

Hikaye tahtalarıyla çalışmayı gerçekten sevmeme nedenlerim bunlar. Bu nedenlerden bazıları XIB'ler için de geçerlidir. Üzerinde çalıştığım storyboard tabanlı projelerde, tasarruf ettiklerinden çok daha fazla zaman harcadılar ve işleri daha kolay yerine daha karmaşık hale getirdiler.

Kullanıcı arayüzümü ve uygulama akışımı kodda oluşturduğumda, neler olup bittiğini çok daha kontrol ediyorum, hata ayıklamak daha kolay, hataları erken tespit etmek daha kolay, değişikliklerimi diğer geliştiricilere açıklamak daha kolay ve iPhone ve iPad'i desteklemek daha kolaydır.

Bununla birlikte, tüm kullanıcı arayüzünüzü kod halinde düzenlemenin her proje için tek bedene uygun bir çözüm olmayabileceğini kabul ediyorum . İPad kullanıcı arayüzünüz belirli yerlerde iPhone kullanıcı arayüzünüzden büyük ölçüde farklıysa, yalnızca bu alanlar için bir XIB oluşturmak mantıklı olabilir.

Yukarıda belirtilen sorunların birçoğu Apple tarafından düzeltilebilir ve umarım yapacakları şey budur.

Sadece iki sentim.

Güncelleme : Xcode 5'te Apple, Storyboard'suz bir proje oluşturma seçeneğini elinden aldı. Xcode 4'ün şablonlarını (Storyboard devre dışı bırakma seçeneği ile) Xcode 5'e bağlayan küçük bir komut dosyası yazdım: https://github.com/jfahrenkrug/Xcode4templates

Storyboard'lar, geliştiricilerin uygulamalarını ve uygulama akışını görselleştirmelerine yardımcı olmak için oluşturuldu. Bir sürü xib'e sahip olmak gibi bir şey ama tek bir dosyada.

Buna benzer bir soru var .xib dosyası ile .storyboard arasındaki fark nedir? .

.Xibs gibi, gerektiğinde dinamik olarak değişecek kod aracılığıyla da özel geçişler oluşturabilirsiniz.

Artıları:

• Herhangi bir kod varsa, çok fazla yazmadan bir uygulamanın akışını alay edebilirsiniz.
• Ekranlar ve uygulama akışınız arasındaki geçişleri görmek çok daha kolay.
• Film şeridi ile gerekirse .xibs de kullanabilir.

EKSİLERİ:

• Yalnızca iOS 5+ ile çalışır. İOS4 ile çalışmaz.
• Çok görünüm yoğun bir uygulama varsa kolayca darmadağın olabilir.

Birini veya diğerini ne zaman kullanacağınız gerçekten doğru / yanlış değil, sadece bir tercih meselesi ve hangi iOS sürümlerini kullanmak istediğinizi.

Sadece devlet olacaktır 4 basit nedenler neden gerektiğini size sahip olduğu ürün sahipleri, ürün yöneticileri, UX tasarımcılar, vb bir takımda çalışmak için özellikle verimli bir ortamda, storyboard kullanmak

1. Apple, Storyboard'larla çalışmayı büyük ölçüde geliştirdi. Ve sizi onlarla çalışmaya teşvik ediyorlar. Onlar hangi vasıta olmaz güncellemeleri ile mevcut projeleri kırmak, onlar storyboard'lar yeni XCode / iOS sürümleri için gelecek kanıtı sağlayacaktır.
2. Daha görünür sonuçlar içinde daha kısa sürede bile yaratma aşamasında ürün sahipleri ve yöneticileri için. Film şeridini bir ekran akışı diyagramı olarak bile kullanabilir ve toplantılarda tartışabilirsiniz.
3. Bir uygulama yapıldıktan sonra bile (ve genellikle yaşam döngüsünün başladığı yer) - gelecekte küçük ayarlamalar uygulamak daha hızlı ve daha kolay olacaktır . Ve bunlar, muhtemelen WYSIWYG tarzında görmek istediğiniz, düzeninizin birden çok yönünü aynı anda çok iyi değiştirebilir. Alternatif, koddaki UI değişikliklerini elle yazmak ve IDE ile simülatör arasında test etmek için her seferinde derlemek ve derlemek için beklemek olacaktır.
4. Geliştiricilere, görsel senaryo taslaklarında düzenler oluşturma ve geliştiriciler için gerekli kancaları oluşturma (IBOutlets ve IBActions) öğretilebilir . Bu çok büyük bir artı çünkü geliştiricilerin mantığa odaklanmasına izin veriyor ve UX tasarımcıları herhangi bir kod yazmak zorunda kalmadan değişikliklerini görsel bir şekilde uyguluyorlar.

Johannes, cevabında muhtemelen tüm uygulanabilir olanları listelediği için herhangi bir CONS yazmayacağım. Ve çoğu kesinlikle uygun değil, özellikle XCode6'nın büyük gelişmeleri ile değil.

Sorunuz için doğru bir cevap olduğunu düşünmüyorum, bu sadece kişisel bir deneyim ve daha rahat hissettiğiniz bir konu.

Bence, Storyboard'lar harika bir şey. Doğru, uygulamanızın çalışma zamanında neden gizlice çöktüğünü öğrenmek gerçekten zor, ancak bir süre ve deneyimden sonra her zaman bir yerde eksik olan bazı IBOutlet ile ilişkili olduğunu fark edeceksiniz ve kolayca düzeltebileceksiniz.

Tek gerçek sorun, hikaye tahtaları ile sürüm kontrolü altında takımda çalışmaktır, gelişimin erken aşamalarında gerçek bir karışıklık olabilir. Ancak bu ilk aşamadan sonra, film şeridini tamamen değiştiren UI güncellemeleri çok nadirdir ve çoğu durumda, film şeridini yeniden açtığınızda genellikle kendilerini düzelten segue referansları olan xml'nin son bölümlerinde çakışmalarla sonuçlanırsınız. . Takım çalışmamızda, tonlarca görüş koduna sahip ağır görüş kontrolörleri yerine bununla uğraşmayı tercih ettik.

Otomatik düzen için birçok yorum tekrar okudum. XCode5 ile gerçekten geliştirildi, Otomatik döndürme düzenleri için bile gerçekten iyi. Bazı durumlarda kodda bir şey yapmanız gerekir, ancak düzenlemeniz gereken kısıtlamayı çıkarabilir ve bu noktada kodunuzda ihtiyacınız olanı yapabilirsiniz. Hatta onları canlandırın.

Ayrıca, storyboard'lardan hoşlanmayan insanların çoğunun, bir yoldan diğerine geçiş şeklinizi tamamen özelleştirebileceğiniz (tek bir dosyada) özel bir manuel segue'in gücünü tam olarak anlamaya çalışmadığını düşünüyorum. bazı hileler), daha önce yüklenmiş bir görünüm denetleyicisini, tüm içeriği tamamen yeniden yüklemek yerine yalnızca görünüm içeriğini güncelleyerek yeniden kullanabilirsiniz. Sonunda gerçekten kod ile aynı şeyleri yapabilirsiniz, ancak sanırım hikaye tahtaları ile endişelerin daha iyi bir ayrımı var, ama birçok şey özellikleri (yazı tipleri, renk arka plan olarak görüntü, ecc ... ).

Hiçbir uygulama StoryBoard veya XIBs kullanmıyorum .. ama programlı olarak her şeyi oluşturma.

∆ Yararları:

UIView'' S için herhangi bir karmaşık UI veya geçiş animasyonu oluşturabilirsiniz .

All Tüm iOS sürümlerini destekleyin. <İOS 5 hakkında endişelenmenize gerek yok.

Your * Uygulamanız kodunuzdaki tüm iPhone / iPod / iPad cihazlarını destekleyecektir.

√ Her zaman çalışacak kodu bildiğiniz için daima güncellenirsiniz.

Launched * Başlatılan herhangi bir (yeni) cihazda çalışır - Kod değiştirmeye gerek yoktur.

√ Her şey size kalmış. Belli bir yerde bir şeyi değiştirmek istiyorsunuz - Film şeridine veya xib'e bakmanıza gerek yok. Sadece belirli bir sınıfta arayın.

√ Sonuncu ama liste değil - Bunu asla unutmayacaksın, her şeyi programlı olarak nasıl yöneteceksin. Herkesten çok daha derin bir kontrol bildiğiniz için bu en iyi şey.

_{Bu konuda iyi olduğum için SB veya XIB'leri kullanmayarak bir sorun bulamadım.}

_{* UIKit'in nesne çerçevelerini ekran boyutuna göre ayarladıysanız.}

_{PS Hala bu şeyi yapmadıysanız - zorluklarla karşılaşabilirsiniz (veya sıkıcı hissedebilirsiniz) ama bir kez bunu öğrendikten sonra - bu gerçekten sizin için bir Şeker.}

Storyboard performansını önemsemek üzereyseniz WWDC 2015 Oturum 407'yi izleyin

Yapım Zamanı

Arayüz oluşturucu bir storyboard derlerken önce iki şey yapıyor, uygulamanızın performansını en üst düzeye çıkarmaya çalışıyor ve ikinci olarak da oluşturulan uç dosyalarının sayısını en aza indiriyor.

Bir görünüm ve bir grup alt görünümleri, arabirim oluşturucu ile bir görünüm denetleyicisi varsa, derleme süresi görünüm denetleyicisi için bir uç dosyası ve görünüm için bir uç dosyası oluşturacak.

Hem görünüm denetleyicisi hem de görünüm için ayrı uç dosyalarına sahip olmak, görünüm hiyerarşisinin isteğe bağlı olarak yüklenebileceği anlamına gelir.

Çalışma süresi

UI storyboard, API kullanarak bir storyboard örneği ayırdığınızda, başlangıçta bellek ayırdığınız tek şey UI storyboard örneğinin kendisidir.

Henüz görünüm denetleyicisi yok görünüm yok.

İlk görünüm denetleyicinizi başlattığınızda, bu ilk görünüm denetleyicisinin ucunu yükler, ancak yine de birisi gerçekten isteyene kadar henüz bir görünüm hiyerarşisi yüklenmemiştir.

Makul büyüklükte bir proje üzerinde çalışıyorum (film şeridi parlar> 20 sahneleri) ve birçok sınırlamalarla karşılaştım ve tekrar tekrar dokümantasyon ve bir şeyler yapmak için google aramalarına gitmeliyim.

1. Kullanıcı arabiriminin tümü tek bir dosyada. Birden fazla film şeridi oluştursanız bile, her film şeridinde hala birçok sahne / ekran var. Bu orta-büyük ekiplerde bir sorundur.

2. İkincisi, diğer kapsayıcı denetleyicilerini vb. Yerleştiren özel Kapsayıcı Denetleyicileri ile iyi oynamazlar. Sekmeli bir uygulamada MFSlideMenu kullanıyoruz ve sahnenin bir tablosu var. Bu, bir storyboard ile neredeyse imkansız. Günler geçirdikten sonra, tam kontrolün olduğu XIB yolunu yapmaya başvurdum.

3. IDE, uzaklaştırılmış durumdaki kontrollerin seçilmesine izin vermez. Yani, büyük bir projede, uzaklaştırma çoğunlukla yüksek düzeyde bir görünüm elde etmek ve daha fazlası için değil.

Küçük ekip boyutlarına sahip daha küçük uygulamalar için film şeritlerini ve orta-büyük ekipler / projeler için XIB yaklaşımını kullanırdım.

Bazı kullanıcı arayüzlerini birden çok görünüm denetleyicisinde yeniden kullanmak istiyorsanız, XIB'leri kullanmalısınız