iOS Kullanıcı Arayüzleri: Storyboard'lar ve NIB'ler ve Özel Kodlar

iOS geliştiricilerinin aynı anahtar sorunun bazı türevlerini sorduğunu sık sık duyuyorum:

iOS'ta bir UI geliştirmenin en iyi yolu nedir: Storyboard'lar, NIB'ler veya kod aracılığıyla?

Bu soruya verilen yanıtlar, açık veya örtük olarak, geliştirmeden önce, genellikle önceden ele alınan, karşılıklı olarak birbirini dışlayan bir seçim olduğunu varsayma eğilimindedir.

Bunun yerine cevabın bir veya daha fazla karşı soru şeklini alması gerektiği görüşündeyim.

"En iyi" araba nedir?

Konu dışı bir örnekle açıklayayım. Diyelim ki bir araba satın almak istiyorum ve size basit bir soru soruyorum: “En iyi seçim nedir?”

Gerçekten bir model, hatta bir marka önererek cevap verebilir misiniz? Bir Ferrari önermedikçe pek olası değil. Bunun yerine, muhtemelen aşağıdaki gibi birkaç soruyla cevap verirsiniz:

• Bütçeniz nedir?
• Kaç koltuğa ihtiyacınız var?
• Yakıt tüketimini önemsiyor musunuz?
• Spor arabalar hakkında ne düşünüyorsun?

Doğru bir bağlama oturtulmadığı sürece iyi ya da kötü araba diye bir şey olmadığı açıktır - sadece belirli ihtiyaçlara göre iyi ya da kötü bir araba vardır.

iOS Kullanıcı Arayüzü Tasarımına Geri Dön

Tıpkı araba sorgulamamızda olduğu gibi, "Bir iOS kullanıcı arayüzü geliştirmenin en iyi yolu nedir?" sorusu bağlamdan yoksundur. Ve şaşırtıcı bir şekilde, cevabın her şeyi kapsayan bir durum olması gerekmez.

Genel olarak konuşursak, her biri artıları ve eksileri, hayranları ve düşmanları ile alabileceğiniz üç tür kullanıcı arayüzü tasarımı yaklaşımı vardır:

• iOS Storyboards : Birden çok uygulama görünümünü ve bunlar arasındaki geçişleri düzenlemek için görsel bir araç.
• NIB'ler (veya XIB'ler) : Her NIB dosyası, tek bir görünüm öğesine karşılık gelir ve Arayüz Oluşturucu'da düzenlenebilir, bu da onu görsel bir araç haline getirir. "NIB" adının dosya uzantısından türetildiğini unutmayın (eski telaffuz devam etmesine rağmen, daha önce .nib ve şimdi .xib).
• Özel Kod : yani, GUI aracı yok, bunun yerine tüm özel konumlandırma, animasyon vb.'nin programlı olarak işlenmesi.

Bu seçeneklerin hiçbiri evrensel olarak diğerlerinden daha iyi değildir (duyabileceklerinize rağmen).

Örneğin storyboard'lar, iOS UI araç setine yapılan en son eklemedir. Bana gelecek oldukları, NIB'lerin ve özel kod UI'lerinin yerini alacakları söylendi. Storyboard'ları yararlı bir araç olarak görüyorum, ancak NIB'ler ve özel kod için bir tamamlayıcı olarak çok fazla bir yedek değil. Storyboard'lar bazı durumlarda doğru seçimdir, ancak tüm durumlarda değil.

Ayrıca, eldeki belirli soruna en iyi uyan mekanizmayı seçerek (aynı projede) hepsini kullanabilecekken neden statik olarak tek bir seçeneğe bağlı kalmalısınız?

Bu, bence, daha yüksek düzeyde genelleştirilebilecek ve cevabı yazılım geliştirme ilkeleri listemde üst sıralarda yer alan bir sorudur: Herkes için evrensel en iyi seçim olan evrensel bir dil, çerçeve veya teknoloji yoktur. yazılım geliştirme sorunu. Aynısı iOS UI tasarımı için de geçerlidir.

Bu iOS geliştirme eğitiminde, bu yöntemlerin her birini keşfedecek ve kullanılmaları ve kullanılmamaları gereken kullanım örneklerinin yanı sıra bunların birlikte harmanlanabilecekleri yolları tanıtacağız.

iOS Storyboard'ları

Klasik bir yeni başlayanların hatası, proje çapında büyük bir iOS Storyboard oluşturmaktır. Storyboard'larla ilk çalışmaya başladığımda ben de bu hatayı yaptım (muhtemelen bu cazip bir yol olduğu için).

Adından da anlaşılacağı gibi Storyboard, anlatacak bir hikayesi olan bir panodur. Birbiriyle ilgisiz hikayeleri tek bir büyük ciltte karıştırmak için kullanılmamalıdır. Film şeridi, mantıksal olarak birbiriyle ilişkili görünüm denetleyicileri içermelidir - bu, her görünüm denetleyicisi anlamına gelmez.

Örneğin, aşağıdakileri işlerken Storyboard'ları kullanmak mantıklıdır:

• Kimlik doğrulama ve kayıt için bir dizi görünüm.
• Çok adımlı bir sipariş giriş akışı.
• Sihirbaz benzeri (yani öğretici) bir akış.
• Bir ana ayrıntı görünümü kümesi (örneğin, profil listeleri, profil ayrıntıları).

Bu arada, uygulama çapında tek Storyboard'lar dahil olmak üzere büyük Storyboard'lardan kaçınılmalıdır (uygulama nispeten basit değilse). Daha derine inmeden önce, nedenini görelim.

Büyük iOS Storyboard'larının Deliliği

Büyük Storyboard'lar, göz atılması ve bakımının zor olmasının dışında, ekip ortamına bir karmaşıklık katmanı ekler: birden fazla geliştirici aynı anda aynı storyboard dosyası üzerinde çalıştığında, kaynak denetimi çakışmaları kaçınılmazdır . Ve bir storyboard dahili olarak bir metin dosyası (aslında bir XML dosyası) olarak temsil edilirken, birleştirme genellikle önemsiz değildir.

Geliştiriciler kaynak kodu görüntülediğinde, ona anlamsal bir anlam yüklerler. Böylece manuel olarak birleşirken, bir çatışmanın her iki tarafını da okuyup anlayabilir ve buna göre hareket edebilirler. Bunun yerine bir storyboard, Xcode tarafından yönetilen bir XML dosyasıdır ve her bir kod satırının anlamını anlamak her zaman kolay değildir.

Çok basit bir örnek alalım: Diyelim ki iki farklı geliştirici bir UILabel konumunu değiştiriyor (otomatik yerleşimi kullanarak) ve ikincisi değişikliğini zorlayarak bunun gibi bir çatışma üretiyor (çakışan id niteliklerine dikkat edin):

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

id kendisi, gerçek önemi hakkında herhangi bir gösterge sağlamaz, bu nedenle üzerinde çalışacağınız hiçbir şey yoktur. Tek anlamlı çözüm, çatışmanın iki tarafından birini seçip diğerini atmak. Yan etkileri olacak mı? Kim bilir? Sen değil.

Bu iOS arabirim tasarımı sorunlarını kolaylaştırmak için, aynı projede birden çok storyboard kullanmak önerilen yaklaşımdır.

Storyboard'lar Ne Zaman Kullanılır?

Storyboard'lar en iyi şekilde, birbirine bağlı birden çok görünüm denetleyicisi ile kullanılır, çünkü temel basitleştirmeleri görünüm denetleyicileri arasında geçiş yapmaktır. Bir dereceye kadar, görünüm denetleyicileri arasında görsel ve işlevsel akışlara sahip NIB'lerin bir bileşimi olarak düşünülebilirler.

Gezinme akışını kolaylaştırmanın yanı sıra, bir başka belirgin avantaj, görünüm denetleyicilerini açmak, göndermek, sunmak ve kapatmak için gereken ortak kod kodunu ortadan kaldırmalarıdır. Ayrıca, görünüm denetleyicileri otomatik olarak atanır, bu nedenle manuel olarak alloc ve init gerek yoktur.

Son olarak, Storyboard'lar en iyi şekilde birden fazla görünüm denetleyicisi içeren senaryolar için kullanılsa da, üç nedenden dolayı tek bir tablo görünümü denetleyicisiyle çalışırken bir Storyboard kullanmak da savunulabilir:

• Masa hücresi prototiplerini yerinde tasarlama yeteneği, parçaları bir arada tutmaya yardımcı olur.
• Ana tablo görünümü denetleyicisi içinde birden çok hücre şablonu tasarlanabilir.
• Statik tablo görünümleri oluşturmak mümkündür (ne yazık ki yalnızca Storyboard'larda bulunan uzun zamandır beklenen bir ekleme).

Birden fazla hücre şablonunun NIB'ler kullanılarak da tasarlanabileceği iddia edilebilir. Gerçekte, bu sadece bir tercih meselesidir: Bazı geliştiriciler her şeyi tek bir yerde bulundurmayı tercih ederken, diğerleri umursamıyor.

iOS Storyboard'ları Ne Zaman Kullanılmamalı

Birkaç vaka:

• Görünüm, en iyi şekilde kodla uygulanan karmaşık veya dinamik bir düzene sahiptir.
• Görünüm, NIB'ler veya kodla zaten uygulandı.

Bu durumlarda, görünümü Storyboard'un dışında bırakabilir veya bir görünüm denetleyicisine gömebiliriz. İlki, Storyboard'un görsel akışını bozar, ancak herhangi bir olumsuz işlevsel veya geliştirme etkisi yoktur. İkincisi bu görsel akışı korur, ancak görünüm görünüm denetleyicisine entegre edilmediğinden ek geliştirme çabaları gerektirir: yalnızca bir bileşen olarak gömülüdür, bu nedenle görünüm denetleyicisi onu uygulamak yerine görünümle etkileşime girmelidir.

Genel Artıları ve Eksileri

Artık Storyboard'ların iOS UI tasarımında ne zaman yararlı olduğuna dair bir fikrimiz olduğuna ve bu eğitimde NIB'lere geçmeden önce, genel avantajlarını ve dezavantajlarını gözden geçirelim.

Profesyonel: Performans

Sezgisel olarak, bir Storyboard yüklendiğinde, tüm görünüm denetleyicilerinin hemen başlatıldığını varsayabilirsiniz. Neyse ki, bu yalnızca bir soyutlamadır ve gerçek uygulama için doğru değildir : bunun yerine, varsa yalnızca ilk görünüm denetleyicisi oluşturulur. Diğer görünüm denetleyicileri, bir segue gerçekleştirildiğinde veya koddan manuel olarak dinamik olarak başlatılır.

Profesyonel: Prototipler

Storyboard'lar, kullanıcı arayüzlerinin ve akışının prototip oluşturmasını ve taklit edilmesini basitleştirir. Aslında, görünümleri ve navigasyonu olan eksiksiz bir çalışan prototip uygulaması, Storyboard'lar ve sadece birkaç satır kod kullanılarak kolayca uygulanabilir.

Eksileri: Yeniden Kullanılabilirlik

Taşıma veya kopyalama söz konusu olduğunda, iOS Storyboard'ları kötü konumlandırılmıştır. Bir Storyboard, tüm bağımlı görünüm denetleyicileriyle birlikte hareket ettirilmelidir. Başka bir deyişle, tek bir görünüm denetleyicisi tek başına çıkarılamaz ve başka bir yerde tek bir bağımsız varlık olarak yeniden kullanılamaz; Storyboard'un geri kalanının çalışmasına bağlıdır.

Con: Veri akışı

Bir uygulama geçiş yaptığında verilerin genellikle görünüm denetleyicileri arasında iletilmesi gerekir. Ancak, Arayüz Oluşturucu'da bunun olduğuna dair hiçbir iz olmadığından Storyboard'un görsel akışı bu durumda bozulur. Storyboard'lar, veri akışını değil, görünüm denetleyicileri arasındaki akışı idare etmeye özen gösterir. Bu nedenle, hedef denetleyici, görsel deneyimi geçersiz kılarak kodla yapılandırılmalıdır.

Bu gibi durumlarda, aşağıdaki gibi bir if/else-if iskeleti olan bir prepareForSegue:sender 'a güvenmemiz gerekir:

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

Bu yaklaşımı hataya açık ve gereksiz yere ayrıntılı buluyorum.

NIB'ler

NIB'ler, iOS arayüz tasarımı gerçekleştirmenin eski(er) yoludur.

Bu durumda, "eski", "kötü", "modası geçmiş" veya "kullanımdan kaldırılmış" anlamına gelmez. Aslında, iOS Storyboard'larının NIB'lerin evrensel bir alternatifi olmadığını anlamak önemlidir; sadece bazı durumlarda UI uygulamasını basitleştirirler.

NIB'lerle, geliştiricinin daha sonra gerektiğinde bir görünüm denetleyicisine ekleyebileceği herhangi bir isteğe bağlı görünüm tasarlanabilir.

Kullanıcı arayüzlerimize nesne yönelimli tasarım uygularsak, bir görünüm denetleyicisinin görünümünü, her biri kendi NIB dosyasıyla (veya aynı dosyada gruplandırılmış birden çok modülle) bir görünüm olarak uygulanan ayrı modüllere bölmek mantıklı olur. Bu yaklaşımın açık avantajı, her bileşenin daha kolay geliştirilmesi, test edilmesi ve hatalarının daha kolay ayıklanmasıdır.

NIB'ler, Storyboard'larda gördüğümüz birleştirme çakışması sorunlarını paylaşır, ancak NIB dosyaları daha küçük ölçekte çalıştığı için daha az ölçüde.

iOS Kullanıcı Arayüzü Tasarımı için NIB'ler Ne Zaman Kullanılır?

Tüm kullanım durumlarının bir alt kümesi şöyle olacaktır:

• Kalıcı görünümler
• Basit giriş ve kayıt görünümleri
• Ayarlar
• Açılır pencereler
• Yeniden kullanılabilir görünüm şablonları
• Yeniden kullanılabilir tablo hücresi şablonları

Bu sırada…

NIB'ler Ne Zaman Kullanılmamalı

NIB'leri aşağıdakiler için kullanmaktan kaçınmalısınız:

• Düzenin içeriğe bağlı olarak önemli ölçüde değiştiği dinamik içeriğe sahip görünümler.
• Arabirim Oluşturucu'da doğası gereği kolayca tasarlanamayan görünümler.
• Storyboarding ile basitleştirilebilecek karmaşık geçişlere sahip denetleyicileri görüntüleyin.

Genel Artıları ve Eksileri

Daha genel olarak, NIB'leri kullanmanın artılarını ve eksilerini inceleyelim.

Profesyonel: Yeniden Kullanılabilirlik

Aynı düzen birden fazla sınıf arasında paylaşıldığında NIB'ler kullanışlı olur.

Basit bir kullanım durumu olarak, her ikisi de aynı NIB'den kaynaklanabilecek varsayımsal TTLoginView ve TTSignupView görünümleriyle bir kullanıcı adı ve bir parola metin alanı içeren bir görünüm şablonu uygulanabilir. TTLoginView parola alanını gizlemesi ve her ikisinin de karşılık gelen statik etiketleri ('Kullanıcı adınızı girin' ve 'Parolanızı girin' gibi) belirtmesi gerekir, ancak etiketler aynı temel işlevselliğe ve benzer düzenlere sahip olacaktır.

Artıları ve Eksileri: Performans

NIB'ler tembelce yüklenir, bu nedenle gerekmedikçe bellek kullanmazlar. Bu bir avantaj olsa da, tembel yükleme işleminde gecikme vardır ve bu da onu bir dezavantaj haline getirir.

iOS Özel Kodu (Programatik Kullanıcı Arabirimleri)

Storyboard'lar ve NIB'ler ile yapılabilecek herhangi bir iOS arayüz tasarımı ham kodla da uygulanabilir (elbette, geliştiricilerin bu kadar zengin bir araç setinin lüksüne sahip olmadığı bir zaman vardı).

Belki daha da önemlisi, NIB'ler ve Storyboard'lar ile yapılamayacak şeyler, elbette teknik olarak mümkün olması koşuluyla, her zaman kodla uygulanabilir. Buna bakmanın başka bir yolu, NIB'lerin ve Storyboard'ların kodla uygulanmasıdır, bu nedenle işlevleri doğal olarak bir alt küme olacaktır. Hemen artılarına ve eksilerine geçelim.

Profesyonel: Kaputun Altında

Programlı olarak bir iOS kullanıcı arabirimi oluşturmanın en büyük avantajı: Bir kullanıcı arabirimini nasıl kodlayacağınızı biliyorsanız, kaputun altında ne olduğunu bilirsiniz , oysa aynı şey NIB'ler ve Storyboard'lar için geçerli değildir.

Bir karşılaştırma yapmak için: hesap makinesi kullanışlı bir araçtır. Ancak hesaplamaları manuel olarak yapmayı bilmek kötü bir şey değil.

Bu, iOS ile sınırlı değildir, herhangi bir görsel RAD aracıyla (örneğin, Visual Studio ve Delphi, sadece birkaçını belirtmek gerekirse) sınırlıdır. Görsel HTML RAD ortamları tipik bir sınır durumunu temsil eder: HTML bilgisinin gerekli olmadığını ve her şeyin görsel olarak yapılabileceğini iddia ederek (genellikle kötü yazılmış) kod oluşturmak için kullanılırlar. Ancak hiçbir web geliştiricisi, ellerini kirletmeden bir web sayfasını uygulamaz: Ham HTML ve CSS'yi manuel olarak kullanmanın daha modüler, daha verimli koda yol açacağını bilirler.

Bu nedenle, iOS kullanıcı arayüzlerinin kodlanmasında uzmanlaşmak, bu parçaların nasıl bir araya geldiği konusunda size daha fazla kontrol ve daha fazla farkındalık verir, bu da bir geliştirici olarak üst sınırınızı yükseltir.

Profesyonel: Kod Tek Seçenek Olduğunda

UI tasarımı için özel iOS kodunun tek seçenek olduğu durumlar da vardır. Görünüm öğelerinin hareket ettirildiği ve akış veya düzenin içeriğe göre önemli ölçüde ayarlandığı dinamik düzenler tipik örneklerdir.

Pro: Çatışmaları Birleştir

NIB'ler ve Storyboard'lar birleştirme çakışmalarından önemli ölçüde zarar görse de, kod aynı hataya sahip değildir. Tüm kodların anlamsal anlamı vardır, bu nedenle çakışmaları çözmek normalden daha zor değildir.

Con: Prototipleme

Bir düzenin nasıl görüneceğini, onu çalışırken görene kadar anlamak zor. Ayrıca, görünümleri ve kontrolleri görsel olarak konumlandıramazsınız, bu nedenle düzen özelliklerini somut bir görünüme çevirmek, işlerin nasıl oluşturulacağına dair anında bir önizleme sağlayan NIB'ler ve Storyboard'lara kıyasla çok daha uzun sürebilir.

Con: Yeniden Düzenleme

Uzun zaman önce veya başka biri tarafından yazılan kodu yeniden düzenleme de çok daha karmaşık hale gelir: öğeler özel yöntemlerle ve sihirli sayılarla konumlandırıldığında ve canlandırıldığında, hata ayıklama oturumları zor olabilir.

Profesyonel: Performans

Performans açısından, Storyboard'lar ve NIB'ler, yükleme ve ayrıştırma ek yüküne tabidir; ve sonunda, dolaylı olarak koda çevrilirler. Söylemeye gerek yok, bu kodlu kullanıcı arayüzlerinde olmaz.

Profesyonel: Yeniden Kullanılabilirlik

Programlı olarak uygulanan herhangi bir görünüm, yeniden kullanılabilir bir şekilde tasarlanabilir. Birkaç kullanım örneğini görelim:

• İki veya daha fazla görünüm ortak bir davranışı paylaşır, ancak bunlar biraz farklıdır. Bir temel sınıf ve iki alt sınıf, sorunu zarif bir şekilde çözer.
• Tek bir kod tabanı oluşturmak, ancak her biri belirli özelleştirmelere sahip iki (veya daha fazla) farklı uygulama oluşturmak amacıyla bir proje çatallanmalıdır.

Aynı UI tasarım süreci, NIB'ler ve Storyboard'lar ile çok daha karmaşık olacaktır. Şablon dosyaları devralmaya izin vermez ve olası çözümler aşağıdakilerle sınırlıdır:

• NIB ve Storyboard dosyalarını çoğaltın. Bundan sonra ayrı hayatları var ve orijinal dosyayla hiçbir ilişkileri yok.
• Basit durumlarda işe yarayabilecek, ancak diğerlerinde önemli karmaşıklığa yol açabilecek kodla görünüm ve davranışı geçersiz kılın. Kodlu ağır geçersiz kılmalar ayrıca görsel tasarımı işe yaramaz hale getirebilir ve örneğin belirli bir kontrol Arayüz Oluşturucu'da bir şekilde görüntülendiğinde, ancak uygulama çalışırken tamamen farklı göründüğünde, sürekli bir baş ağrısı kaynağına dönüşebilir.

Kod Ne Zaman Kullanılır?

Aşağıdaki durumlarda iOS kullanıcı arabirimi tasarımı için özel kod kullanmak genellikle iyi bir çağrıdır:

• Dinamik düzenler.
• Yuvarlatılmış köşeler, gölgeler vb. gibi efektli görünümler.
• NIB'leri ve Storyboard'ları kullanmanın karmaşık veya olanaksız olduğu herhangi bir durum.

Kod Ne Zaman Kullanılmamalı

Genel olarak, kodlu kullanıcı arayüzleri her zaman kullanılabilir. Nadiren kötü bir fikirdirler, bu yüzden bir burada.

NIB'ler ve Storyboard'lar tabloya bazı avantajlar getirse de, kod kullanımını caydırmak için bir listeye koymamın makul bir dezavantajı olmadığını hissediyorum (belki tembellik dışında).

Tek Proje, Çoklu Araçlar

Storyboard'lar, NIB'ler ve kod, iOS kullanıcı arabirimi oluşturmak için üç farklı araçtır. Onlara sahip olduğumuz için şanslıyız. Programatik UI fanatikleri muhtemelen diğer iki seçeneği hesaba katmayacaktır: kod, teknik olarak mümkün olan her şeyi yapmanıza izin verirken, alternatiflerin sınırlamaları vardır. Dışarıdaki geliştiricilerin geri kalanı için, Xcode çakısı aynı projede aynı anda etkin bir şekilde kullanılabilecek üç araç sağlar.

Nasıl, soruyorsun? Nasıl istersen. İşte bazı olası yaklaşımlar:

• İlgili tüm ekranları ayrı gruplar halinde gruplandırın ve her grubu kendi farklı Storyboard'u ile uygulayın.
• Tablo görünümü denetleyicisinin içinde bir Storyboard ile yerinde yeniden kullanılamaz tablo hücreleri tasarlayın.
• Yeniden kullanımı teşvik etmek ve tekrardan kaçınmak için NIB'lerde yeniden kullanılabilir tablo hücreleri tasarlayın, ancak bu NIB'leri özel kod aracılığıyla yükleyin.
• NIB'leri kullanarak özel görünümler, kontroller ve ara nesneler tasarlayın.
• Son derece dinamik görünümler için ve daha genel olarak Storyboard'lar ve NIB'ler aracılığıyla kolayca uygulanamayan görünümler için kod kullanın ve bir Storyboard'da görünüm geçişlerini muhafaza edin.

Kapatmak için, hepsini birbirine bağlayan son bir örneğe bakalım.

Basit Bir Kullanım Örneği

Birkaç farklı görünüme sahip temel bir mesajlaşma uygulaması geliştirmek istediğimizi varsayalım:

• Takip edilen arkadaşların listesi (kullanıcı arayüzünü gelecekteki listelerde tutarlı tutmak için yeniden kullanılabilir bir hücre şablonuyla).
• Ayrı bölümlerde (profil bilgileri, istatistikler ve bir araç çubuğu dahil) oluşturulmuş bir profil ayrıntısı görünümü.
• Bir arkadaşa gönderilen ve bir arkadaştan alınan mesajların listesi.
• Yeni bir mesaj formu.
• Kullanıcı mesajlarında kullanılan farklı etiketleri görüntüleyen bir etiket bulutu görünümü, her bir etiketin boyutu, kullanım sayısıyla orantılıdır.

Ayrıca, görüşlerin aşağıdaki gibi akmasını istiyoruz:

• Takip edilen arkadaşlar listesindeki bir öğeye tıklamak, ilgili arkadaşın profil ayrıntılarını görüntüler.
• Profil ayrıntıları, profil adını, adresini, istatistikleri, en son mesajların kısa bir listesini ve bir araç çubuğunu gösterir.

Bu iOS uygulamasını uygulamak için, kullanabileceğimiz UI araçlarımızın üçü de kullanışlı olacaktır:

• Dört görünüm denetleyicisine sahip bir Storyboard (liste, ayrıntılar, mesaj listesi ve yeni mesaj formu).
• Yeniden kullanılabilir profil listesi hücre şablonu için ayrı bir NIB dosyası.
• Profil ayrıntıları görünümü için üç ayrı NIB dosyası, onu oluşturan ayrı bölümlerin (profil ayrıntıları, istatistikler, son üç ileti) her biri için birer tane olmak üzere, daha iyi sürdürülebilirlik sağlamak için. Bu NIB'ler, görünümler olarak somutlaştırılacak ve ardından görünüm denetleyicisine eklenecektir.
• Etiket bulutu görünümü için özel kod. Bu görünüm, ne StoryBoard'lar ne de NIB'ler aracılığıyla Arayüz Oluşturucu'da tasarlanamayan görünümün tipik bir örneğidir. Bunun yerine, tamamen kod aracılığıyla uygulanır. Storyboard'un görsel akışını korumak için Storyboard'a boş bir görünüm denetleyicisi eklemeyi, etiket bulutu görünümünü bağımsız bir görünüm olarak uygulamayı ve görünümü program aracılığıyla görünüm denetleyicisine eklemeyi seçiyoruz. Açıkçası, görünüm bağımsız bir görünüm yerine görünüm denetleyicisi içinde de uygulanabilir, ancak daha iyi yeniden kullanım için onları ayrı tutuyoruz.

Gerçekten basit bir maket şöyle görünebilir:

Bununla, temel görünümleri UI tasarımına yönelik üç temel yaklaşımımızı birbirine bağlayan oldukça karmaşık bir iOS uygulamasının temel yapısını özetledik. Unutmayın: Her aracın güçlü ve zayıf yönleri olduğundan ikili bir karar verilemez.

Toplama

Bu eğitimde incelendiği gibi, Storyboard'lar iOS UI tasarımına ve görsel akışa gözle görülür bir sadeleştirme ekler. Ayrıca ortak kod kodunu da ortadan kaldırırlar; ama tüm bunların bir bedeli var, esneklik içinde ödeniyor. Bu arada NIB'ler, tek bir görünüme odaklanarak ancak görsel akış olmadan daha fazla esneklik sunar. Elbette en esnek çözüm, oldukça düşmanca ve doğası gereği görsel olmayan koddur.

Bu makale ilginizi çektiyse, NIB'ler, Storyboard'lar ve kod yapımı UIS üzerine bir tartışmaya harcanan 55 dakikalık Ray Wenderlich'in büyük tartışmasını izlemenizi şiddetle tavsiye ederim.

Kapanışta bir şeyi vurgulamak istiyorum: Ne pahasına olursa olsun uygun olmayan iOS UI tasarım aracını kullanmaktan kaçının . Bir görünüm Storyboard ile tasarlanamıyorsa veya NIB'ler veya kodla daha basit bir şekilde uygulanabiliyorsa, Storyboard kullanmayın . Benzer şekilde, bir görünüm NIB'ler kullanılarak tasarlanamıyorsa, NIB'leri kullanmayın. Bu kurallar basit olmakla birlikte, bir geliştirici olarak eğitiminizde uzun bir yol kat edecektir.