Dolap.com Android Uygulamasına Genel Bir Bakış

Murat Can Bur
Dolap Tech
Published in
4 min readFeb 16, 2018

Dolap.com Android uygulaması, ilk oluşumundan beri yer alma şansına sahip olduğum bir uygulama. Kodlamaya başlamadan 3 aylık geliştirmenin çalışan prototipine sahip olma şansını da yakaladım, canlıda davranışa/dataya göre hızlı değişen plana adaptasyon dönemini de deneyimledim.

Yapısal tüm kararların sorumluluğu tek android developer olduğum için bana aitti. Bu ağırlığı teknik lead’im Yiğit Darçın ve iOS takım arkadaşım Ahmet Keskin ile yapılacak işler üzerinden bol bol fikir alışverişinde bulunarak hafiflettim.

Bu deneyimler doğrultusunda hem süreçlere hem teknik yapıya dair detayları aktarmak için aşağıdaki başlıkları toparladım.

1. Package yapısı

Uygulama içerisinde bulunan package yapısı Package-by-feature” mantığı esas alınarak düzenlenmiş durumdadır. Bu sayede daha modüler, birbirine daha az bağımlı package düzeni elde edilmiş durumda. Birbiriyle ilişkili bütün sınıflar/arayüzler aynı alan içinde yer almaktadır.

2. Uygulama mimarisi

Uygulama geliştirilme sürecinde temel anlamda MVP mimarisi kullanılmaktadır. Burada temel olarak amaçladığım nokta, uygulamanın modüler olarak yazılması ve her bir katmanın kendi sorumluluğunu yerine getirmesidir.

activity/fragment : Burada tamamen arayüz elemanları ile ilgili kodlar yer almaktadır. Activity veya fragment arayüze sağlanan verilerin nasıl elde edileceğinden öte, bunların ekranda gösterilmesinden sorumlu durumda.

presenter : Uygulama içerisinde presenter olarak isimlendirdiğimiz katman ise activity veya fragment’ ın ihtiyacı olan verinin sağlanmasını gerçekleştirmektedir.

repository: Repository olarak isimlendirdiğimiz katman, presenter’ dan aldığı veri isteklerini ilgili kaynaklardan sağlamakla görevlidir.

localDataSource: LocalDataSource olarak isimlendirdiğimiz katman ise uygulama içerisinde temel anlamda SharedPreferences içerisinde yer alan verilerin okunması, güncellenmesi, silinmesi gibi işlemlerden sorumludur.

remoteDataSource: RemoteDataSource olarak isimlendirdiğimiz katman uygulama ile Dolap.com API arasında gerçekleşen iletişimden sorumludur.

3. Git-branch yapısı

Uygulamanın geliştirilme sürecinde tek developer bulunmasına rağmen basit olarak bile olsa temel aldığımız bir branch yapısı bulunmaktadır. Uygulamanın kaynak kodlarının bulunduğu repo’ da 3 tip branch kullanmaktayız. Bunlar sırasıyla prod, master, feature branch’leri olarak isimlendirilmektedir.

feature-branch: Feature’ ları geliştirirken kullandığımız branch. Biraz daha pratik hareket etmek için burada kullandığımız branch sprint’ in doğrudan kendisine karşılık gelmektedir. Örnek isimlendirme sprint83.

master: O hafta koştuğumuz sprint içerisinde tamamlanan işler bu branch’ e merge edilir ve regression testleri master branch üstünden yapılmaktadır.

prod: Google Play Store ‘ da yer alan uygulama ile aynı koda sahip branch. Release APK’ sı bu branch üzerinden sağlanmaktadır.

4. Sprint yapısı

Sprint yönetimi için kullandığımız en önemli iki araç JIRA ve konuşmak. JIRA’nın faydaları zaten açık, sözlü iletişimin avantajları ise iki rutinimiz üzerinden özetlenebilir:

Retrolar:
Sprint’i kapatırken retrospektif toplantıları ile o haftayı değerlendiriyoruz; nelerin iyi işlediğini nelerin ters gittiğini konuşuyoruz. Bu konuşmalar ilerleyen sprintlerde aynı problemlerin daha az yaşanmasını sağlıyor. Örneğin birbirine bağımlı API ile Client işini aynı sprinte koymamak deneyerek öğrendiğimiz, retro sonrası da hep dikkat ettiğimiz bir konu oldu.

İşleri Analiz aşamasında konuşmak:
İşlerin hazırlanma sürecinde product’ın development tarafıyla sürekli konuşur halde olması işi yapılabilir parçalara bölmede ve kafamızdaki kod yapısının önceden netleşmesinde oldukça etkili oluyor. Önceden konuşmak ayrıca iş sprinte geldiğinde son dakika süprizlerinin çoğu zaman önüne geçiyor.

5. Bir feature geliştirmek için ortalama olarak yapılması gerekenler

Şu an aktif olarak bir end-to-end feature geliştirilmesi gerektiğinde yapılması gereken adımlar sırayla şu şekildedir;

  1. Uygulama içerisindeki pek çok özellik API’ ye paralel olarak çalışmaktadır. O yüzden ilk aşama olarak Repository katmanın yazılması ve özelliğe bağlı olarak remote/local data source sınıflarının yazılması.
  2. Gelen datanın yönetilmesini sağlayan presenter katmanın yazılması ve activity/fragment davranışını yöneten methodların kodlanması.
  3. Tasarıma bağlı olarak bir arayüz geliştirilmesi. Bunun için duruma bağlı olarak activity/fragment ve içeriklerinin yazımı varsa adapter ve ilişkili arayüz elemanlarının kodlanması.
image credit : https://www.theodysseyonline.com/heres-future

6. Android uygulaması için gelecek hedefleri neler olabilir?

Uygulamanın geleceği adına yapılabilecekleri ise aşağıda ki gibi sırayalabiliriz;

  1. Son zamanlarda Databinding kullanımının mantıklı olabileceğini düşünmeye başladım. Bundan dolayı projede adım adım databinding kullanarak Butter Knife kullanımından vazgeçilebilir.
  2. Databinding kullanımına paralel olarak MVP yapısından MVVM mimarisine kayılması da düşünebilir. Bu sayede daha reactive çalışan bir uygulama elde edebiliriz.
  3. Mimari değişimi sırasında architecture components içerisinden kütüphanelerinde kullanımı ile kod içerisinde daha fazla kontrol mekanizması elde edilebilir.
  4. Son zamanlarda Unit Test ve UI Test yazımlarına başlamıştım. Bu süreç aynı zamanda öğrenme süreci ile paralel devam etmektedir. Sanırım bu yıl içerisinde de bu test yazım sürecine devam edip aynı zaman da refactor süreci de devam edecektir.
  5. Uygulamada local olarak tuttuğumuz veriler genelde basit anlamda olan flag değerleri ya da içeriği son derece sade olan bazı model sınıflarıdır. Burada ise Room kullanılarak biraz daha mimariyi geliştirebilir hem de popüler akımlardan birisini de kullanabilmiş olabiliriz.
  6. Uygulama geliştirilme sürecinde test APK’ sı dağıtımı bitrise.com üzerinden bir slack entegrasyonu ile gerçekleşmektedir. Slack üzerinde ayarladığımız bir kanalda ilgili komutları kullandığımızda test için APK oluşturulmaktadır. Gelecek hedeflerinden bir tanesi ise bu işlemin Play Store ‘ da release APK’sı yayınlanırken de tekrarlanmasıdır :)

Dolap.com Android uygulamasının ve sürecinin gelişim hikayesi kısaca bu şekilde. Yorumlarınızı bekliyorum. Bu arada yazıyı beğendiyseniz alkış ile beni haberdar edebilirsiniz.

--

--

Murat Can Bur
Dolap Tech

Blogger , Public Speaker, Mobile Engineering Team Lead @Trendyol