Tek Geliştirici, Yaklaşık İki Düzine Android Uygulaması

Nesim Razon, bağımsız Android geliştiricisi · 2026-11-12

#Geliştirici notları#Android#Araçlar ve hesaplayıcılar

Yaklaşık iki düzine küçük Android uygulamasını ve oyununu tek başıma yönetiyorum: bulmaca oyunları ve günlük kullanım araçları karışık. Bu ancak tekrar eden hemen her şeyin ya bilinen sağlam bir kalıptan kopyalanması ya da uygulamanın dışına çıkarılması sayesinde işliyor. Bu yazı ayakta kalan kalıpları ve etraflarındaki alışkanlıkları anlatıyor.

Her şeyin arkasındaki kural: bir kez yaz, şekli kopyala

Tek uygulamada kurnaz olmayı göze alabilirsiniz. İki düzine uygulamada icat ettiğiniz her özel durum, unutacağınız bir özel durumdur. Bu yüzden birden fazla uygulamada görünen her özelliğin bir referans uygulaması var, yeni uygulamalar onu baştan icat etmek yerine kopyalıyor. Referans, daha yeni oyunlardan birinde duruyor ve sıradaki uygulama o dosyadan, testiyle birlikte başlıyor.

Kopyalamak şık değil ve ortak bir kütüphane kâğıt üzerinde daha derli toplu olurdu. Pratikte uygulamaların paket adları, reklam kurulumları ve ekranları farklı, kendi takvimlerinde yayınlanıyorlar ve ortak bir modül her değiştiğinde hepsinin eşgüdümlü sürümünü gerektirirdi. Küçük, iyi sınanmış bir dosyayı kopyalamak her uygulamayı bağımsız tutuyor. Kalıp iyileştiğinde eski uygulamalar bunu telaşsız, kendi doğal sürümlerinde alıyor.

Çapraz tanıtım kod değil, veri olarak

Her oyunun, ailenin geri kalanını listeleyen bir Diğer oyunlarım penceresi var. Başta bu liste her uygulamanın içine gömülüydü; yani yeni bir oyun çıkarmak, bütün eski oyunlar için güncelleme yayınlamak demekti. Bu ölçeklenmiyor.

Şimdi liste, statik bir web sitesinden sunulan küçük bir JSON dosyası. Her uygulamadaki tek bir sınıf onu en çok 48 saatte bir indirir ve cihazda önbelleğe alır. Ağ yoksa ya da önbellekteki dosya eksik veya bozuksa uygulama, kendi varlıklarında gömülü bir kopyaya döner; pencere asla boş kalmaz. Yeni bir oyun, JSON'da bir yeni satır ve bir ikon demek; hiçbir eski uygulamanın yeni sürüme ihtiyacı yok.

Dosya ağdan geldiği için uygulama onu güvenilmez sayar. Yalnızca Play Store bağlantıları açar, paket adını ve anahtarı katı kalıplara karşı denetler, kayıt sayısını ve dosya boyutunu sınırlar, beklediği sunucudan başka hiçbir adresi reddeder. Pencere cihazın dilini okur, bulamazsa İngilizceye düşer. Dosyayı bir oyun listesinden kısa bir betik üretir; JSON'u elle düzenlemem.

Güncelleme istemi ve bulut kaydı: tek referanstan kopya

Oynanışa odaklanırken iki özellik kolay unutulur, sonradan eklemesi pahalıdır: kullanıcıya yeni sürümün var olduğunu söylemek ve telefon değiştirdiğinde ilerlemesini korumak. İkisi de artık herhangi bir yeni uygulamanın ilk sürümü için kontrol listemde.

Güncelleme için Play uygulama içi güncelleme API'sini esnek kipte kullanıyorum. Küçük bir nesne, uygulama öne geldiğinde denetler. Yalnızca gerçekten bir güncelleme varsa, yeni sürüm en az bir gündür çıkmışsa (Play yayını kademeli açar) ve aynı sürüm için üç günde en çok bir kez sorar. İndirme bitince yeniden başlatmayı önerir. Uygulama Play'den kurulmamışsa ya da cihaz çevrimdışıysa denetim sessizce hiçbir şey yapmaz. Karar mantığı saf bir fonksiyon, dolayısıyla birim testleri var; pencere metinleri dört dilde.

İlerleme için, anlamlı bir ilerleme durumu olan oyunlarda Play Games kayıtlı oyunlarını kullanıyorum; böylece yeni telefon eskisinin kaldığı yerden devam eder. Her yeni oyunun bunu ilk sürümden alması, bir kez verilmiş bilinçli bir karar. Birkaç eski oyun, durumları önemsiz olduğu için bilerek istisna.

Tek yükleme anahtarı, Play App Signing

Yeni uygulamalar Play App Signing kullanıyor. Gerçek imza anahtarını Google tutuyor, bende yalnızca yeni uygulamalar arasında ortak kullanılan bir yükleme anahtarı var. Yükleme anahtarı kaybolur ya da sızarsa Play üzerinden sıfırlanabilir; bu, gerçek bir imza anahtarını kaybetmekten çok daha az korkutucu. Bu düzenden önceki eski uygulamalar özgün imzalarını koruyor ve ayrı ele alınıyor; iki grubu notlarımda net biçimde ayırıyorum ki karıştırmayayım.

Yayın betikleri anahtar parolasını imzalama anında soruyor; gizli hiçbir şey bir dosyaya, depoya ya da koda yazılmıyor.

Kendi kendini üreten bir web sitesi

Her uygulamanın bir tanıtım sayfası, bir gizlilik sayfası ve bir kullanım şartları sayfası gerekir; oyunlar için ayrıca rehberler ve blog yazıları yazıyorum. İki düzine uygulama için bunu elle ve dört dilde yapmak hızla geride kalmanın yolu, bu yüzden site üretiliyor.

Tek komut her şeyi yeniden kurar. Üreticileri sabit sırayla çalıştırır: ana sayfa, uygulama detay sayfaları, oyun rehberleri ve blog; en sonda dört dilli tek bir kaynağı dil başına ayrı sayfalara bölen bir adım. İngilizce kökte durur, diğerleri dil klasörlerinde. Bu adım ayrıca hreflang bağlantılarını, kanonik adresleri, son değişiklik tarihli bir site haritasını ve yapılandırılmış veriyi yazar. Ana sayfanın verisi tek bir JSON dosyasında; yeni uygulama bir satır ekler, yayınlanmamış uygulama çok yakında diye işaretlenebilir ve kart yayın gününde kendiliğinden görünür.

Koyduğum bir kural: üretilen dosyalar asla elle düzenlenmez. Bir sayfa yanlışsa üreteci ya da veriyi düzeltir, yeniden kurarım. Dil klasörleri her derlemede silinip yeniden yazılır; yani elle yapılan düzenleme zaten kaybolur ve amaç da bu. Çıktıyı tutarlı tutar, tutarlılık ise tek başına çalışan bir geliştiricinin kaybetmeyi göze alamayacağı şeydir.

Sıkıcı işler için betikler

İkiden fazla yaptığım her iş betik oluyor. Bir senkron betiği, her uygulama için bir tane olan tüm depoları çeker, sonra hangilerinde işlenmemiş ya da gönderilmemiş iş olduğunu raporlar; makine değiştirmenin güvenli olup olmadığını tek ekranda görürüm. Her uygulamanın bir derleme betiği ve imzalı paketi üreten bir yayın betiği var; derleme çıktısı benzersiz adlı bir günlük dosyasına gidiyor ve akışı izlemek yerine o dosyada önemli sözcükleri arıyorum.

İki farklı yerde iki bilgisayarla çalışıyorum; bu yüzden senkron betiği beni birden fazla kez unutulmuş işlemelerden kurtardı. Küçük bir şey ve her hafta kendini amorti ediyor.

Aynı mantık derleme günlüğü için de geçerli: çıktıyı bir boruya bağlayıp beklemek yerine dosyaya yönlendirmek, uzun bir derleme sırasında takılıp kalmayı önlüyor ve sonradan hata satırlarını aramayı kolaylaştırıyor. Bir derleme başarısız olduğunda önce günlüğün ve çıktı dosyasının zamanına bakıyorum; projeyi suçlamadan önce, eski bir çıktıya bakmadığımdan emin oluyorum.

Notlar ve iş listesi, dürüst tutulan

Hafıza iki düzine projeye yetmiyor. Her uygulamanın kökünde güncel durumu anlatan bir not dosyası var: ne yayınlandı, hangi sürüm yayında, neler bekliyor ve geçmişteki bir karar neden verildi. Tek bir üst düzey iş listesi tüm uygulamalardaki açık işleri tutuyor ve kısa bir akan günlük her çalışma oturumunda olanları kaydediyor.

Önemli olan disiplin, bunları doğru tutmak. Bir işi bitirdiğimde iş listesini ve uygulamanın notlarını aynı oturumda güncelliyorum; bir şey planlamadan önce yazılı durumu gerçeğiyle doğruluyorum, örneğin geçen hafta yazdığıma güvenmek yerine Play'e hangi sürümün yayında olduğunu soruyorum. Bitmiş işi açık, ya da tersini gösteren bir iş listesi hiç olmamasından kötü; çünkü hepsine güvensizlik yaratır.

Bu yaklaşımın bedeli

Bedelsiz değil. Kopyalanan dosyalar zamanla ayrışır; eski bir uygulama bir sonraki sürümüne kadar kalıbın biraz eski bir halini taşıyabilir. Üretilen bir site, üretecin kendisinin bakımını ve sınanmasını gerektiren bir yazılım parçası demek. Uzaktaki bir liste de kırılabilecek bir şey daha; bu yüzden her uzak özelliğin gömülü bir yedeği ve katı bir doğrulaması var.

Karşılığında öngörülebilirlik alıyorum. Yeni bir uygulama güncellemeler, bulut kaydı, bir menü, bir gizlilik sayfası, çapraz tanıtım ve bir site kaydı çoktan çözülmüş olarak başlıyor; zamanımı uygulamayı kurmaya değer kılan kısma harcıyorum. Birkaç uygulamadan fazlasına bakıyorsanız önerim: sürekli yeniden yaptığınız iki üç şeyi seçin, her birine bir referans uygulaması verin ve veri olabilecek her şeyi ikili dosyanın dışına çıkarın.