Refactoring the Eldest p.1
Herkese merhaba,
Bugünkü yazımda birkaç gün önce ekipçe üzerinde çalışmaya başladığımız görev ile alakalı minik araştırmalarımı size aktaracağım. Konumuz Android proje mimarileri ve alakalı design pattern çeşitleri.
Üzerinde çalışmaya başladığımız görev zamanın gerisinde kalmış bir Android projesini sıfırdan yazmadan, refactor ederek günümüzde kullanılan güncel teknoloji ve yapılara taşımak.
Yani elimizde tam 229 sayfadan (Activity) oluşan kompleks yapılara sahip ve MVC mimarisi kullanılarak yazılmış bir Android uygulaması var ve zamanda 4–5 sene ileri atlaması gerekiyor.
Loodos Tech. Android ekibinin göreviyse bu projeyi artık Google’ın da adını vermeden önerdiğini düşündüğümüz MVVM mimarisine dönüştürmek ve bu dönüşüm sırasında uygulamayı ileride modüler bir hale sokabileceğimiz güçlü ve sağlam bir altyapı oturtmaya çalışmak. Korku ve heyecanla karışık benim bu dönüşümdeki başlıca hedefim ilk kanı dökmek; yani MVVM mimarisine dayanan abstract bir yapı oluşturmak.
Proje mimarisi
Google I/O 17'de Android Architecture Components’ın tanıtılması ve sonrasında gelen örneklerle aslında bize net bir şekilde şunu söylüyorlar diyebilirim; bir Android uygulaması geliştirmek için hangi mimariyi seçeceğiniz size kalmış, biz sadece örnekleri gösteriyoruz, yani biz olsak böyle yapardık :)
Android’in Github hesabındaki architecture-samples deposunu ziyaret ederseniz branch dağılımlı bir “todo” uygulamasının çeşitli mimariler ve araçlarla tasarlanmış halini görebilirsiniz:
Bütün bu branch dağılımı aslında iki farklı yaklaşımda şekilleniyor:
- MVP (+Clean Architecture, +Data binding, +RxJava, +Dagger)
Uygulamanın bu versiyonunda her ekran aşağıdaki sınıf ve arayüzler kullanılarak oluşturulmuş:
- View ile presenter arasındaki bağlantıyı sağlayan bir contract sınıfı.
- Fragment ve presenter oluşturan bir activity.
- View arayüzünü implement eden bir fragment.
- Karşılık gelen contract sınıfındaki presenter arayüzünü implement eden bir presenter.
2. MVVM (+Data binding, +Lifecycle-aware)
Bu mimaride elimizde presenter yapısı yerine view model bulunuyor. Kısaca özetlersek;
- Model — Business logic’i içinde bulunduracak data modeli
- View — Cihaz ekranında gözükecek layout yapıları
- ViewModel — View ve model arasındaki bağlantıyı sağlayacak ve herhangi bir view logic ile ilgilenecek yapı
Aşırı basitleştirilmiş temsillerinden anlaşılamadığı üzere iki mimari birbirinden farklılık gösteriyor. Fakat ‘todo-mvvm’ adlı branch’in açıklamasındaki şu kısım en çok dikkatimi çeken kısım:
Benim varmış olduğum sonuç şu ki MVVM mimarisini tam anlamıyla öğrenmek için önce MVC, MVP ve son olarak Android özelinde MVP+Databinding gibi yapılara da aşina olmak gerekiyor.
Peki hangi özgüven ile demode kalmış, iri ve yaşlı projemiz için MVVM seçiyoruz?
- MVP ile geliştirdiğimiz projeler olması.
- Databinding yapısına az çok hakim olmamız.
- “Her haliyle şu ankinden daha iyi olacak zaten” rahatlığı.
İlk kısmı burada bitirelim. Okuduğunuz için teşekkürler.
