Masif Görüş Kontrol Cihazı - IOS - Çözümler

Eminim her yeni iOS geliştiricisi aşağıdaki soruna sahiptir: Görünüm Kontrolörleri çeşitli amaçlar için kodlarla çok hızlı bir şekilde kalabalıklaşır, 500 + kod satırına kolayca ulaşır.

İki temel ve ortak ekran için şu şekilde görünür:

1) Form Ekranı:

2) Tablo Görünümü Denetleyici Ekranı

Şimdiye kadar iki farklı çözüm okudum:

1. İlk Çözüm: https://bendyworks.com/single-responsibility-principle-ios/ . Bu, Bildirimlere dayanır, Görünüm Denetleyicisini (Niyetler) Görünüm Modelinden tamamen ayırır ve böylece Görünüm Denetleyicisindeki kodu azaltır. Ben Go-To yapıları gibi, kod kırma dezavantajı olduğunu düşünüyorum. Şöyle görünüyor:

2. İkinci çözüm aynı kalabalık Görünüm Denetleyicilerini tutar (düğme eylemleri VC içinde yürütülür ve bu şekilde devam eder). ancak çoğu kategoriye göre TPKeyboardAvoiding , BlocksKit veya diğer çözümleri kullanır . Bu ikinci çözümle, kod önemli ölçüde azalır, ancak görünüm denetleyicisinin hala çok fazla sorumluluğu vardır.

Bu çözümler hakkında ne düşünüyorsunuz? Hangisi daha iyi? Daha iyisi var mı?

Bu sorunu çözmek için MVVM'yi kullanabiliriz.

Model-View-ViewModel veya yaygın olarak bilindiği gibi MVVM deseni bir UI tasarım modelidir. VM, VC'den UI için model verileri hazırlama hakkındaki tüm mantığı alır.

Örnek:
Bazı alanlara sahip model nesneniz var, bazılarını biçimlendirmek, hesaplama yapmak ve birleştirmek istiyorsunuz.

MVC durumda ViewController bulunan tüm bu mantık.
MVVM'de hepsini VC'den VM'ye taşırsınız.

VM, UI ve VC için tüm verileri hazırlar ve bu şekilde ayarlar.

(VC sınıfında)

self.descriptionLabel = self.viewModel.textForDescriptionLabel;

Öğreticiler ve konular:

• MVVM'ye Giriş
• ReactiveCocoa ile MVVM Eğitimi
• iOS Tasarım Desenleri: MVC ve MVVM

Daha önce büyük boyutlu Görünüm Denetleyicilerindeki kodu çözmek zorunda kaldım ve gerçekten ilk başta içerikte gezinme yeteneğimi engelledi. Fark ettiğim önemli bir nokta, View Controller'ın tek başına boyutunun işleri parçalamak için yeterli bir neden olmadığı. 1 büyük dosyaya sahip olma karmaşıklığı ve bir sürü küçük dosyaya sahip olma karmaşıklığı vardır. Bir Denetleyiciyi daha küçük parçalara bölmek için yeniden düzenleme yapmanın bazı geçerli nedenleri şunlardır:

MVC

View Controller, View ve Model arasındaki bağlantı tutkalı olmaktan daha fazlasını yapmamalıdır. Çok fazla ağ bağlantı kodu, görüntü işleme kodu vb. Varsa, bunları yardımcı sınıflara bölmeyi düşünün.

Veri kaynağı olarak View Controller ile Çoklu Kontroller

Ekranda Görünüm Denetleyicinizi veri kaynağı olarak kullanan bir sürü denetiminiz varsa, bunları ayrı veri kaynağı nesnelerine bölmeyi ve veri kaynağı olmasını sağlayın. Ya da bunları ayrı Görünüm Denetleyicilerine bölebilirsiniz (Görünüm Denetleyicisinin diğer denetleyiciye ek olarak bir tablo görünümü varsa, bunu kendi Tablo Görünümü Denetleyici sınıfına ayırabilirsiniz).

Yinelenen Kod

Farklı Görünüm Denetleyicilerinde tam olarak aynı koda sahipseniz, bunu 1 paylaşılan konuma yerleştirin. Bu, kodunuzu yeniden kullanılabilir hale getirecek ve karmaşıklığı yönetmeye yardımcı olacaktır.

Görünüm Denetleyicisi karmaşıklığını en aza indirmek için bazı ek öneriler:

Programlı yerine film şeridi

Görünüm öğeleri oluşturmak çok kod ve çerçeve geometrisi kodu da çok iş. Önceden otomatik düzen kısıtlamaları kullanmayı ve Görünüm öğelerinin çoğunu film şeridine mümkün olduğunca koymayı düşünün.

Gereksiz kod / yorumlar

Ayrıca gereksiz kodu / yorumları kaldırdığınızdan emin olun. Çoğu zaman yeni bir View Controller dosyası kullanmadığınız yöntemlerle birlikte gelir. Böyle bir yöntem kullanmıyorsanız, didReceiveMemoryWarningo zaman bu yöntemi kullanmak güvenlidir. Ayrıca, View Controller dosyası çok büyük olduğu için bazen eski kodu veya yorumları kaldırmak korkutucu olabilir. Bunu ertelemeyin! Sadece karmaşıklığı arttırır.

Bildirimler

Bildirimlerle ilgili sorunuzu yanıtlamak için: Bildirimler, her şeyle kullanılacak bir Altın Çekiç değildir. Birden fazla Görünüm Denetleyicisinin 1 belirli işlem nedeniyle aynı anda güncellenmesi gerektiğinde bildirimleri yararlı buluyorum. Ancak bildirimlere dikkat edin, onları aşırı kullanmak, onları izlemeye çalışırken çok fazla acıya neden olabilir.

VIPER olarak adlandırdıkları özel bir mimari var (Görünüm, Etkileşim, Sunum Yapan Kişi, Varlık ve Yönlendirme). Bilmeniz gerekenler burada özgeçmişinizi deneyeceğim:

Görünüm

• kukla görüşlerdir;
• UIView, UIViewController, UILabel, vb. nesneleri içerir;
• içerik bekler Sunum ;
• kullanıcı etkileşimini yönetme ve Presenter katmanına aktarma .

sunucu

• UI nesnelerini bilmiyor;
• Görünüm katmanından girdi alma ;
• görünüm mantığını işlemek (ekleme yöntemi diğer ekranı gösterecektir);

Yönlendirme

• gezinme mantığını ve geçiş animasyonlarını yönetme;
• UINavigationController, UIWindow, vb. nesneleri bilir;

Yani, kodunuzda temizleyeceğinizi düşündüğüm:

• veri doğrulamaları Presenter katmanına taşınır ;

• gezinme Tel Kafes nesnelerine ( Yönlendirme katmanı) geçecektir ;

• bakış kontrol cihazınızı KURU prensibine göre ayırın ;

• Karmaşık ekranlarda iki veya daha fazla Görünüm ve Sunum Yapılır.

VIPER mimarisi ile ilgili aşağıdaki bağlantıyı görmelisiniz http://mutualmobile.github.io/blog/2013/12/04/viper-introduction/

İyi şanslar!