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 : UITableViewController
a UICollectionViewController
? Yoksa bir ovaya UIViewController
mı? 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, customer
görünüm denetleyicinizin içini değiştirilemez hale getirebilir ve bu görünüm denetleyicisinin customer
nesne 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 customer
nesne 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