29 Ocak 2016 Cuma

Android Üzerinde Basit MVP Uyarlaması


Merhaba Arkadaşlar,

Bu blog yazısında android uygulama geliştirirken MVP kalıbı nasıl uygulanır temel haliyle anlatmaya çalışacağım. MVP MVC, MVVM gibi MV* (mv-whatever) kalıplarının farklılaşmış bir şekli olup Model View Presenter kelimelerinin kısaltmasıdır. Temel mantığı kullanıcı arayüzü (ui) ile iş kurallarını (business logic) birbirinden ayırmak (bkz. separation of concerns). MVP kendi içinde supervising presenter ve passive view olarak ikiye ayrılır, ben passive view üzerinde duracağım.

MVP deseni kullanılarak geliştirilen yazılımın parçaları daha modüler ve esnek bir yapıya kavuşmuş oluyor. Bu sayede yazılımın hata eğilimi azalıp, modüllerin birbirinden iyi ayrıştırılmasıyla daha test edilebilir ve bakımı kolay kaliteli bir kod bütünü oluşuyor. Sorumlulukların ayrışması ve modüllerinin daha izole çalışması sayesinde birim testlerinden entegrasyon testlerine kadar test yazımı kolaylaşıyor çünkü model, view ve presenter birbirinin implementasyonu hakkında çok az bilgiye sahip ve aralarında ilişkiler soyut yapılara (interface, abstract class) dayandırılmış oluyor. (bkz. program to interfaces, not implementations)

MVP tasarım kalıbında kullanıcıdan gelen tüm hareketleri view karşılıyor ve ilgili hareketleri presenter'a iletiyor sonrasında presenter model ve view'ı koordine ederek akışı yönetiyor, özünde olay bu. MVP'nin temel yapılarını ele alırsak:

Model
Adından da anlaşılacağı üzere veri yönetimi burada yapılıyor. Burayı salt veriyi temsil eden model sınıfları olarak görmemeliyiz; model katmanı veriye erişim sınıfları ve iş mantığını da barındırır. MVC'den farklı olarak model, view'i güncelleyemez; ikisi arasında direkt etkileşim yoktur.

View
Uygulamanın arayüz yapılarını (layout, button, edittext vs) barındırır, bunun yanında kullanıcıdan gelen hareketleri (click, scroll vs) presenter'a iletir. Android'de view interface'lerini activity ve fragment'lar implemente eder böylece android geliştirmede en sık karşılaşılan ve sistemin test edilebilirliğini katleden bir anti-pattern olan god object'den kaçınılmış olunur.

Presenter
MVP kalıbının kalbinde yer alır, diğer modülleri koordine eder. Genelde model'den hizmet alıp view'i günceller.

Örnek üzerinden gitmek daha anlaşılır olacaktır; misal üye modülü olan bir uygulamamız olduğunu düşünelim ve açılışta kullanıcıyı doğruladıktan sonra ana ekranı gösteriyor olalım. Böyle bir senaryoda kullanıcı, username ve password'ünü girip login'e bastığında, bu talep view üzerinden presenter'a delege edilir sonra presenter bu bilgileri model ile sorgulayıp sonucu view'i güncelleyerek kullanıcıya yansıtır.

Bu basit senaryoyu MVP ile gerçekleyen gradle bazlı android projesine linkten ulaşabilirsiniz, önemli noktaları mümkün mertebe yorum satırlarıyla açıkladım.

MVP desenini uygularken bazen bir işlevin hangi katmanda uygulanması gerektiği kafanızı karışabilir. Örneğin kullanıcıya bir bildirim gösterileceğinde bunu presenter'da mı yoksa view tarafında mı ele almak gerek? Bu gibi durumlarda şöyle düşünmekte fayda var; aynı android uygulamasını desktop (swing) için de yazarken sadece view implementasyonu değişmeli. Eğer ilgili işlevi uygulama şekliniz bu kuralı bozuyorsa hatalıdır.

Son zamanlarda android bloglarında artık daha fazla test konusuna eğilimler görmek mümkün zira artık mobil framework'ler ve ekosistemler olgunlaşmaya başladı dolayısyla en rekabetçi unsur, ortaya çıkan ürünün kalitesi. Bu noktada yazılım projesinin uçtan uca (unit, integration, ui, user acceptance tests) test edilmesi çok önemli. Mevcut yapının test edilebilmesi için eldeki yazılım altyapısının buna elverişli (loosely coupled, srp, modular vs) olması şart. Bu yolda MVP deseni de biz yazılım gelişitiriciler için güçlü bir araç.

Aşağıdaki popüler Android MVP kütüphanelerini incelemenizi tavsiye ederim:



Umarım faydalı olur, iyi çalışmalar.

4 yorum: