Android’in kullanıcı arabirimi yeniden kullanılabilirliğini en üst düzeye çıkarma - 5 genel hata

Son birkaç ay boyunca, Groupon'daki mevcut kullanıcı arayüzümüzden bazılarını tekrar ziyaret etme fırsatım oldu. Bu sürecin bir parçası olarak, UI’nizde neyin iyi olduğunu ve en yaygın hatalarımızın neler olduğunu, Grup’un kullanıcı arayüzünü bir sonraki seviyeye çıkarmak umuduyla belirleyerek başladık.

Kullanıcı arabirimini iyi yapan nedir? İyi, görecelidir, ancak herhangi bir yazılıma uygulanabilecek üç ana ilke üzerinde anlaşmak kolaydı:

  • Okunabilir. İyi UI bileşenlerinin okunması kolaydır. Android Studio’nun tasarım sekmesini ziyaret etmenize gerek yok, xml açıklayıcı.
  • Test edilebilir. Her UI bileşeni, bağımlı veya harici bileşenlere gerek kalmadan kolayca test edilebilir.
  • Yeniden kullanılabilir. UI bileşenleri orijinal davranışlarını değiştirmeden yeniden kullanılabilir ve genişletilebilir.

Bu makalede, kullanıcı arayüzümüzün yeniden kullanılabilirliğini etkileyen bazı yaygın hatalardan geçeceğiz ve yeniden kullanılabilir kullanıcı arayüzlerinin kodumuzu nasıl daha okunaklı ve test edilebilir hale getirebileceğini göreceğiz.

1. İş modeli özel görünümlerde

Bazen, zamandan tasarruf etmek ve tekrarlanan kodlardan kaçınmak için, ağımızda ve veritabanı modellerimizde kullandığımızla aynı görüşlerimizi tekrar kullanmaya karar veriyoruz. Bir örnek ele alalım:

Kullanıcı bilgilerini arka uçtan çekmek için userApiClient kullanıyoruz:

Başarıda, modeli alırız:

Aynı modeli, kullanıcının adını ve adresini gösterecek olan özel kullanıcı görünümümüze aktarıyoruz. Bu kolay bir kazanç gibi görünebilir ama değil. Yeniden kullanılabilirlik ilkemize aykırıdır ve uzun vadede ciddi sorunlara neden olabilir. Nedenini görelim.

Bu neden kötü?

  • Arka uç modellerimizi tekrar kullanmamamızın en önemli nedeni, görüşümüzü uygulamanın farklı bir bölümünde tekrar kullanamayacağımızdır. Kullanıcı arayüzümüzü bir son nokta yanıtı ile birleştiriyoruz ve şimdi kullanıcı arayüzünü oluşturmak için bu son noktaya ihtiyacımız var.
  • Arka uç model muhtemelen bizim ihtiyaç duyduğumuzdan daha fazla bilgiye sahiptir. Ekstra bilgi, ekstra karmaşıklık anlamına gelir. Model ne kadar fazla bilgi içeriyorsa, yanlış alan kullanmak o kadar kolay olur. Yukarıdaki örnekte basitleştirilmiş bir model kullanabilirdik:
  • Arka uç değişirse ne olur? Uygulamamızı destekleyen arka uç hizmetlerinin hiçbir zaman değişmeyeceğini varsayıyoruz. Bu kesinlikle doğru değil, arka uçlarımız değişecek ve buna hazır olmamız gerekiyor. Kullanıcı arayüzümüzü değiştirmemeliyiz çünkü arka uçta bir şey değişti.

Nasıl düzeltilir?

Bu sorunu çözmek kolaydır ancak bazı ekstra kodlar gerektirir. Bir UI modeli ve arka uç modelini UI modeline dönüştürmek için bir yöntem oluşturmamız gerekecek.

Örneğimizde, UserModel'i UserUIModel'e çevirip parametre olarak UserView'e geçireceğiz:

Yeni uygulamamız biraz ekstra tesisat gerektiriyor ve yeni bir dönüşümün karmaşıklığını arttırıyor, ancak bu, kullanıcı arayüzümüzü arka uçtan ayırmak için ödenmesi gereken küçük bir bedel. Yeni tasarımımız görüşümüze gereksiz veriler göndermemizi engelliyor ve görüşlerimizi ihtiyaç duyduğumuz her yerde tekrar kullanmamızı sağlıyor.

2. Monolitik görüşler

Hiç bir düzen dosyası açtınız ve tüm etkinliğin kullanıcı arayüzünü içeren büyük bir belge gördünüz mü? Bu, ne yazık ki, Android'de bize çok sıkıntı veren çok yaygın bir kalıp.

Bu neden kötü?

Üç prensibimize aykırıdır:

  • Bu dosyaların okunması çok zor, çok fazla bilgi ve birlikte yaşayan çok fazla bileşen katmanı var.
  • Xml’nin her bir bölümünü ayrı ayrı test etmek mümkün değildir. Kullanıcı arayüzümüzü yalnızca espresso'da gerçekleştirilen entegrasyon testlerinin bir parçası olarak test etme eğilimindeyiz. Entegrasyon testleri harika ancak UI ile işletme mantığını birleştirerek bir hatanın altında yatan sebebin ne olduğunu bilmeyi zorlaştırıyor. Monolitik xml'lerimizi küçük özel görünümlere ayırarak ve tüm iş mantığını kullanıcı arayüzümüzden kaldırarak, yalnızca kullanıcı arayüzü testlerini etkinleştiririz. Bu testler, kullanıcı arayüzümüzdeki sorunları düzenli entegrasyon testlerinden daha hassas bir ayrıntı düzeyinde algılayabilir.
  • Xml'mizin ayrı bölümlerini tekrar kullanamayız, bu da onları ayrı bir ekranda tekrar kullanmak için bu bileşenleri kopyalayıp yapıştırmaya zorlar. Zamanla, kopyalanan bileşenler farklılaşmaya başlayacak ve bu da uygulamamızda tutarsızlığa neden olacaktır.

Nasıl düzeltilir?

Tüm kullanıcı arayüzü mantığımızı bir xml dosyasında oluşturmak, tüm işletme mantığımızı aktivite sınıfında oluşturmaya eşdeğerdir. İş mantığımız için DAO'lar, modeller ve arka uç müşteriler oluşturduğumuz gibi, kullanıcı arayüzümüzü daha küçük parçalara bölmeliyiz.

Özel görünümler ve ve etiketleri en iyi arkadaşlarımızdır. Her zaman yeni bir özelliğin başlangıcında kullanıcı arayüzümüzü kırmak için bunları kullanmalıyız. Bir monolitik xml'den kopabilmek için bir UI bileşeninin yeniden kullanılmasını beklemek ciddi sorunlara neden olabilir. O zaman, kullanıcı arabirimimiz, refactoru daha zorlaştıracak ve uygulamamızın mevcut işlevlerini tehlikeye sokacak şekilde, faaliyetlerimizle / parçamızla büyük ölçüde birleştirilecektir.

Açık kaynak kodlu bir projenin gerçek düzeninden ilham alan bir örnek görelim. Mülkleri kaldırdım ve mizanpajın okunmasını kolaylaştırmak için yorumlar ekledim:

Özellikleri çıkardıktan ve yorum ekledikten sonra bile, bunun gibi bir xml okumak zor. Her bir bileşenin nereye yerleştirildiğini anlamak zor, iç içe geçmiş birkaç katman vardır. Yorumlar olmadan, farklı etiketlerin nasıl ilişkili olduğunu ve neyi temsil ettiğini söylemek zordur.

Xml'de en az 6 tane iyi tanımlanmış UI bileşeni tanımlayabiliriz. Bu bileşenler için özel bir görünüm oluşturursak, bu düzenin nasıl görüneceğini görelim:

Her bir görüşümüz için özel bir görünüm oluşturarak kodumuzu basitleştirdik, görünümlerimizi yeniden kullanılabilir hale getirdik ve gelecekteki refaktörlerin yan etkilerini önledik. Bu yeni uygulamada, kodlarımız kendiliğinden açıklayıcı olduğu için yorumlar artık gerekli değildir.

Tüm faaliyetlerimiz ProgressOverlay kullanıyorsa, yeni bir ilerleme animasyonu uygulamanın ne kadar kolay olacağını düşünün. Monolitik yaklaşımı kullanarak sadece bir sınıfı değiştirmemiz gerekir.

Groupon’un monolitik xml’ler üzerinde küçük UI bileşenlerini tercih etme yaklaşımı Brad Frost’un Atom Tasarım adlı kitabından ilham alıyor. Özellikle UI konusunda tutkuluysanız, bu kitaba bir göz atmanızı öneririm.

Özel görünümlerde 3. İş mantığı

Bir önceki noktada, özel görünümleri kullanmanın yararlarından bahsettik, özel görünümler harika bir araçtır ancak bunları dikkatli kullanmazsak iki ucu keskin bir kılıç olabilir. İş mantığımızı özel bir görünüme bağlamak şaşırtıcı derecede kolaydır. Günlükleri, AB testlerini ve karar verme mantığını eklemek, kodumuzu bölümlendirmek için harika bir yol olabilir, ancak değildir.

Bu neden kötü?

  • Görüşlerimizdeki mantık, mantık görüşümüzü mevcut kullanım durumumuzla birleştirdiği için onları yeniden kullanmamızı zorlaştırır. Görüşlerimizin tamamen yeniden kullanılabilir olması için iş mantığına sade ve agnostik kalmaları gerekir. İyi uygulanmış bir görüş yalnızca bir devlet almalı ve herhangi bir karar vermeden onu vermelidir.
  • Görüşlerimize iş mantığı eklemek, görüşlerimizi test etmeyi zorlaştırır. İyi uygulanmış görünümler yalnızca daha küçük UI bileşenlerine bağlıdır. Otomasyon testinin bir parçası olarak izolasyonda kolayca test edilebilirler. Görünüm düzeyinde iyi otomasyon kapsamı, refactorlerin daha önce istenmeyen yan etkilerini ve kullanıcı arayüzümüzde kod değişikliklerini tespit etmemize yardımcı olacaktır.

Nasıl düzeltilir?

İş mantığını görüşlerimizden çıkarmanın birçok yolu vardır. Bunu yapmanın yolu, tercih ettiğiniz mimariye bağlı olacaktır. MVP kullanıyorsanız, herhangi bir mantık Sunucuna aittir. MVVM'yi tercih ediyorsanız, mantığınız ViewModel'inizin bir parçası olmalıdır.

Groupon'da MVI ve tek yönlü veri akışlarının bu sorunu çözmenin harika bir yolu olduğunu bulduk. İş mantığı, bizim görüşümüzün getireceği değişmez bir devlet nesnesi üretecek olan Niyetimizin bir parçası olmalıdır.

Tek yönlü veri akışları ve yeniden kullanılabilir UI bileşenlerinin nasıl uygulanacağıyla ilgileniyorsanız. Pratyush Kshirsagar ve Yichen WU makalesini, Grox kullanarak çapraz görüş iletişimini okumanızı şiddetle tavsiye ediyorum. Tek yönlü veri akışlarının kullanıcı arayüzümüzü oluşturmamıza nasıl yardımcı olabileceğini açıklayan harika bir iş çıkarırlar.

4. Aşırı optimizasyon

Bu noktada, performans hakkında konuşmadığımızı fark etmiş olabilirsiniz. Performansı iyi UI'ler için ilkelerimizden biri olarak görmediğimize bile şaşırmış olabilirsiniz.

Performansın önemli olduğuna inanmamıza rağmen, okunabilir, tekrar kullanılabilir ve test edilebilir kod, optimize edilmiş koddan daha önemlidir. Sonuçta, daha verimli assembler kodu yazmak yerine üst düzey programlama dilleri kullanmamızın nedeni budur.

Android'de yuvalanmış düzenler ve çifte vergilendirme, kullanıcı arayüzümüzün performansını etkileyen iki büyük sorundur. Bu nedenle, ConstrainLayout'u kullanmamızı ve iç içe yerleşimlerden kaçınmamızı söyleyen makaleler, podcast ve konuşmalar ile sürekli bombalanıyoruz. ConstrainLayout inanılmaz bir araçtır, RelativeLayout'tan daha güçlüdür ve çifte vergilendirmeye tabi değildir. Sorun, her zamanki gibi, bunu aşırı noktaya götürdüğümüzde olur.

Duyduğumuz tüm makalelere ve konuşmalara dayanarak, faaliyetimizin kullanıcı arayüzünü yalnızca bir ConstraintLayout kullanarak uygulayacağımıza karar verebiliriz.

Bu neden kötü?

  • Tüm UI'larımızı tek bir ConstraintLayout'ta oluşturarak, yekpare bir UI oluşturuyoruz. Yukarıda tartıştığımız gibi, okunması zor, test edilmesi zor ve yeniden kullanılamayan kodlar üretir.
  • Kullanıcı arayüzümüzü birinci sınıf vatandaş olarak görmüyoruz. Tüm iş mantığımızı aktivite / fragman sınıfında oluşturmayı asla düşünmeyeceğiz. Kesinlikle aynı nedenler, kullanıcı arayüzümüzün bir xml dosyasını oluşturmamak için de geçerlidir.

Nasıl düzeltilir?

Performans için iyi kodu feda etmek zor bir seçimdir ve her zaman son çare olmalıyız. Aşırı optimizasyonu önlemek için performans testlerini geliştirme sürecimizin bir parçası olarak yapmamız gerekir. Testimiz bize bir sorunumuz olduğunda bize söylemeli ve başka hiçbir çözümün mümkün olmadığı durumlarda yalnızca yekpare bir görüş oluşturmalıyız. UI performans sorunlarının kaç kez bağlanmasının bağlayıcı mantığımızdan çok fazla kaynaklanmasından veya kodumuzun kullanıcı arayüzünü gereğinden fazla yenilemesinden dolayı şaşıracaksınız.

5. Kod incelemelerinde kullanıcı arayüzümüzün ihmal edilmesi

Kodları incelemek zor, zaman alıcı ve en kötüsünü yapmak için, xml dosyalarının anlaşılması kolay değil (özellikle monolitik xmls). Bu nedenlerden dolayı, kodu gözden geçirirken kullanıcı arayüzümüzü ihmal etme eğilimindeyiz.

Bu neden kötü?

  • Uygulamamızın kullanıcı arayüzü kullanıcılarımızın tanıtım mektubu. Tutarlı, temiz ve iyi yapılandırılmış bir UI, uygulamamızda kalan veya uygulamadan çıkan kullanıcılarımız arasındaki fark olabilir.
  • Kullanıcı arayüzümüzü birinci sınıf vatandaş olarak görmüyoruz. Kullanıcı arayüzümüz uygulamanın yarısıdır, xmls ve görünümleri gözden geçirmek için zaman harcamak, en azından iş mantığımızı gözden geçirmek kadar önemlidir.

Nasıl düzeltilir?

İnceleme sürecimizi iyileştirmek için yapabileceğimiz birkaç şey var.

Bir yorumcu olarak:

  • Bir xml'i anlayamadığımızı kabul etmek gayet iyi. Muhtemelen doğru içeriğe sahip değilsiniz veya kullanıcı arayüzü çok karmaşık. Kodun yazarından yardım isteyin.
  • Yazardan bir xml'yi daha küçük görünümlere bölmesini isteme konusunda üzülmeyin. Aynı şeyi büyük sınıf veya büyük bir yöntem için de yapacaksınız.
  • Kod incelemesini kullanıcı arayüzü ile başlatın. Dediğim gibi, xml dosyaları incelemesi en zor kısımdır, okumaya başlamak için yorulmayı beklemeyin.
  • Materyal Tasarımı kurallarına aşina olun. Her zaman kontrol ettiğim bazı kolay şeyler şunlardır: “Sıkıştırılmış” durumumuzun bir parçası olarak dalgalanma etkimiz var mı? Düğmelerimizin yükselmesine ihtiyacımız var mı? veya Animasyonlarımız doğru süreye sahip mi?

Hakem olarak:

  • Çekme İsteğinize kullanıcı arayüzünüzün ekran görüntülerini ekleyin. Bu, ekibinizin kodu daha hızlı incelemesine yardımcı olur.
  • Tasarımcınızdan uygulamanızı incelemesini isteyin. Tasarımcınız en büyük müttefikinizdir. Kullanıcı arayüzünüzü geliştirme döngüsünde mümkün olduğunca erken incelemelerini isteyin.
  • Monolitik xml dosyalarından kaçının. Bunu yeterince söyleyemem, küçük UI bileşenlerinin incelenmesi daha iyi ve daha kolaydır.
  • Kullanıcı adınızla başlayın. Kullanıcı arayüzünüze adanmış bir Çekme İsteği oluşturarak herhangi bir yeni özelliği başlatın. Bu şekilde, kullanıcı arayüzünüzün gözden geçirenin dikkatinin% 100'üne sahip olacağını biliyorsunuz.

Sonuçlar

Yeniden kullanılabilir UI bileşenleri oluşturmak zor değil ama disiplin gerektiriyor. Ekranlar açısından düşünmeyi bırakmamızı, bileşenler ve ilişkileri açısından düşünmeye başlamamızı gerektirir.

Kullanıcı arayüzümüzü tekrar kullanmak, yeni işlevleri daha hızlı oluşturmamıza yardımcı olur. Mevcut UI bileşenlerini oluşturmak ve sıfırdan eksiksiz bir UI oluşturmak arasında hız ve kalite açısından büyük bir fark var. Ayrıca, yeniden kullanılan bileşenler hata düzeltmeleri içerir ve hiç düşünmediğimiz son durumları düşünür.

Tartıştığımız bazı ipuçlarını özetleyerek:

  • İş modellerini görünümler için kullanmak kötü bir fikirdir. Görünümlerinizi daima arka uç ve iş mantığınızdan ayırın.
  • Monolitik xml'lerden kaçının. Kodunuzu okumayı zorlaştırır, test etmeyi zorlaştırır ve bir uygulamadaki tutarsızlıkların ana nedenidir. Atomic Design, kullanıcı arayüzünü tekrar kullanılabilir bileşenlere bölmenize yardımcı olabilir.
  • İş mantığı kullanıcı arayüzüne ait değil. Günlük kaydı, AB testi veya karar verme mantığı bir görünüme ait değildir. Görüşler yalnızca değişmez bir hal almalı ve onu göstermelidir. MVI, değişmezlik ve tek yönlü veri akışlarını benimsemek size yardımcı olacaktır.
  • Kod kalitesi pahasına optimizasyon bir istisna olmalı, asla bir kural olmamalıdır. Başka seçenek olmadığında yuvalanmış mizanpajın cezalarını önlemek için yalnızca yekpare görünümler oluşturmalıyız. Kullanıcı arayüzünüzü doğru şekilde oluşturun ve performans sorunları yalnızca gerçekleştiğinde ele alın.
  • UI kodunuzu birinci sınıf vatandaş olarak kabul edin. Herhangi bir özelliği önce kullanıcı arayüzünü oluşturarak başlatın, tasarımcınızdan mümkün olan en kısa sürede incelemesini isteyin ve ekibinizden bağımsız olarak incelemesini isteyin.

Umarım bu ipuçları bir sonraki Android serüveninizde size yardımcı olur. Groupon Android ekibinden Carlos Palacin Rubio ile birlikte.