Yerel Android Uygulaması Geliştirme: 7 Gerçek Ders

Yerel Android uygulaması geliştirme, genel amaçlı bir mobil uygulama hazırlamaktan farklı problemler ortaya çıkarabiliyor. Çünkü geliştirdiğiniz uygulamanın başarısı yalnızca kodun çalışmasına değil; bölgedeki işletme ve mekân bilgilerinin doğruluğuna, konum verilerine, güncel duyurulara, hava durumuna ve kullanıcıların uygulamayı gerçekten günlük hayatlarında kullanabilmesine bağlı.

Kotlin ve Jetpack Compose ile geliştirdiğim Çemişgezek Rehberi uygulaması bu açıdan benim için oldukça öğretici bir proje oldu.

Çemişgezek gibi belirli bir ilçeyi merkezine alan uygulamada amaç yalnızca tarihi ve doğal güzellikleri listelemek değildi.

Uygulamanın içerisinde zamanla:

gezilecek yerler,
restoran ve kafeler,
marketler,
fırınlar,
kuaför ve berberler,
eczaneler,
nöbetçi eczane bilgileri,
acil telefonlar,
ulaşım bilgileri,
yöresel ürünler,
işletmeler,
hava durumu,
duyurular ve etkinlikler,
konum ve yol tarifi

gibi birbirinden farklı kullanım senaryoları oluştu.

Bu da projeyi klasik bir “ilçe tanıtım uygulaması” olmaktan çıkarıp küçük bir yerel dijital rehbere dönüştürdü.

Bu yazıda Çemişgezek Rehberi’ni geliştirirken karşılaştığım gerçek problemlerden çıkardığım 7 önemli dersi paylaşacağım.

Çemişgezek Rehberi Nedir?

Çemişgezek Rehberi, Tunceli’nin Çemişgezek ilçesindeki yerleri, işletmeleri, ulaşım seçeneklerini ve güncel bilgileri tek mobil uygulama içerisinde toplamayı amaçlayan bir Android projesi.

Projeyi geliştirirken temel hedefim oldukça basitti:

Çemişgezek’te yaşayan veya ilçeyi ziyaret eden biri ihtiyaç duyduğu temel bilgiye farklı sitelerde arama yapmak yerine tek uygulamadan ulaşabilsin.

Ancak geliştirme ilerledikçe yerel uygulamaların kendilerine özgü teknik ve içerik problemleri olduğu ortaya çıktı.

Bir restoranın konumu yanlışsa uygulama teknik olarak kusursuz çalışsa bile kullanıcı açısından başarısızdır.

Bir işletme kapanmışsa kart tasarımının ne kadar güzel olduğu önemli değildir.

Bir duyuru geç ulaşıyorsa güncelliğini kaybeder.

Bu nedenle yerel uygulamalarda kod kalitesi kadar veri kalitesi de ürünün temel bileşenlerinden biri.

Çemişgezek Rehberi’nin Teknik Yapısı

Projenin Android tarafındaki ana teknolojileri şu şekilde özetleyebilirim:

Alan	Teknoloji / Yaklaşım
Programlama dili	Kotlin
Kullanıcı arayüzü	Jetpack Compose
Mimari yaklaşım	MVVM
Hava durumu	Open-Meteo API
Push bildirimleri	Firebase Cloud Messaging
Reklam	Google AdMob
Konum	Enlem / boylam tabanlı yönlendirme
Minimum Android	API 23
Compile / Target SDK	API 36
Dağıtım	Google Play

Teknik yapı ilk bakışta çok karmaşık görünmeyebilir.

Ancak asıl zorluk bu servislerin gerçek yerel verilerle doğru şekilde bir araya getirilmesinde ortaya çıkıyor.

1. Yerel Android Uygulaması Geliştirme Sürecinde Veri Koddan Daha Kritik Olabiliyor

Çemişgezek Rehberi’nde öğrendiğim en önemli ders bu oldu.

Bir yazılımcı olarak doğal olarak önce:

mimari,
performans,
UI,
state yönetimi,
kod kalitesi

gibi konulara odaklanıyoruz.

Yerel bir rehber uygulamasında ise başka bir gerçek ortaya çıkıyor:

Yanlış veri, çalışan koddan daha büyük bir problem.

Örneğin bir işletmenin koordinatı birkaç yüz metre yanlışsa kullanıcı yol tarifi aldığında yanlış noktaya gidebilir.

İşletmenin adı değişmişse uygulamadaki eski isim güvenilirliği azaltır.

Telefon numarası yanlışsa kullanıcı uygulamanın tamamına güvenmemeye başlayabilir.

Veri Girerken Kontrol Ettiğim Alanlar

Yeni bir işletme veya mekân eklerken mümkün olduğunca şu bilgileri ayrı ayrı kontrol etmek gerekiyor:

işletme adı,
kategori,
telefon numarası,
adres,
enlem,
boylam,
açıklama,
fotoğraf,
yol tarifi için kullanılan konum.

Özellikle enlem ve boylam değerleri kritik.

Çünkü birkaç rakamlık hata kullanıcıyı tamamen farklı bir noktaya yönlendirebilir.

Yerel Bilginin Bir Başka Problemi: Sürekli Değişmesi

Bir API’nin response formatı aylarca aynı kalabilir.

Fakat gerçek hayattaki işletmeler değişiyor.

Yeni işletmeler açılıyor.

Bazıları kapanıyor.

Telefon numaraları değişebiliyor.

Minibüs ve feribot saatleri güncellenebiliyor.

Bu nedenle yerel rehber uygulamalarında bakım sürecinin büyük bölümü kod güncellemekten değil, veriyi güncel tutmaktan oluşabiliyor.

2. Kategori Tasarımı Kullanıcı Deneyimini Doğrudan Etkiliyor

Başlangıçta az sayıda kategori olduğunda liste oldukça basit görünüyor.

Ancak içerik büyüdükçe şu kategoriler ortaya çıkmaya başladı:

Gezilecek Yerler
Restoranlar
Kafeler
Marketler
Fırınlar
Kuaförler ve Berberler
GSM Bayileri
Terziler
Eczaneler
Tüpçüler
Basın & Medya
Ulaşım
Acil Telefonlar
Yöresel Lezzetler

Burada yazılım tarafındaki problem yalnızca yeni kategori eklemek değil.

Kullanıcının istediği bilgiye mümkün olduğunca hızlı ulaşmasını sağlamak gerekiyor.

Bir rehber uygulamasında kullanıcı:

“Bir kategoriye kaç dokunuşta ulaşabiliyor?”

sorusu oldukça önemli.

Bu nedenle kategorileri yalnızca veri organizasyonu için değil, kullanıcı navigasyonunun temel parçalarından biri olarak görmek gerekiyor.

Her İşletmeyi Ayrı Ekran Mantığıyla Kodlamak Ölçeklenmez

Yerel uygulamalarda yapılabilecek hatalardan biri her yeni işletme veya yer için ayrı UI kodu yazmak.

İçerik sayısı arttığında bu yöntem hızla yönetilemez hale gelir.

Daha doğru yaklaşım genel bir veri modeli kullanmak.

Örneğin kavramsal olarak:

Place
 ├─ id
 ├─ name
 ├─ category
 ├─ description
 ├─ phone
 ├─ latitude
 ├─ longitude
 └─ image

gibi ortak bir yapı oluşturulduğunda aynı Compose bileşeni farklı işletmeler için tekrar kullanılabilir.

UI’ın veriden ayrılması burada projenin büyümesini ciddi şekilde kolaylaştırıyor.

3. Konum Özelliğinde “Haritayı Açmak” Yetmiyor

Çemişgezek Rehberi’nin temel özelliklerinden biri kullanıcıyı seçtiği yere yönlendirmek.

Teknik açıdan bakıldığında bu işlem oldukça basit görünebilir:

Enlem ve boylam değerini alıp harita uygulamasına göndermek.

Ancak burada ilk problem yine veri doğruluğu.

Yanlış koordinat gönderildiğinde harita uygulaması görevini doğru yapıyor; hata bizim verimizde oluyor.

Koordinat Doğrulamasını Ayrı Bir İş Olarak Görmek

Bu nedenle bir konumu uygulamaya eklemeden önce:

koordinatı harita üzerinde kontrol etmek,
işletmenin gerçek giriş noktasına yakın olup olmadığını görmek,
yol tarifi açıldığında hedefi doğrulamak

gerekiyor.

Özellikle küçük ilçelerde adres bilgilerinin büyük şehirlerdeki kadar standart olmaması koordinat kullanımını daha değerli hale getirebiliyor.

Konum Özelliğini Uygulama İçinde Baştan Yazmak Gerekli mi?

Her zaman değil.

Bir rehber uygulamasının temel görevi navigasyon motoru geliştirmek değilse mevcut harita uygulamalarına yönlendirme yapmak daha doğru olabilir.

Böylece:

trafik,
rota hesaplama,
harita güncellemeleri,
navigasyon

gibi son derece karmaşık problemlerin tamamını uygulama içerisinde yeniden çözmek gerekmiyor.

Benim için buradaki önemli ders şuydu:

Her özelliği kendiniz yazmak zorunda değilsiniz.

4. Open-Meteo ile Hava Durumu Eklemek Kolay, Doğru Sunmak Daha Önemli

Yerel rehber uygulamasında hava durumu oldukça doğal bir özellik.

Özellikle ilçeyi ziyaret edecek bir kullanıcı:

sıcaklığı,
hissedilen sıcaklığı,
yağış ihtimalini,
hava koşullarını

uygulamadan görmek isteyebilir.

Çemişgezek Rehberi’nde bu ihtiyaç için Open-Meteo kullanıyorum.

Open-Meteo Forecast API koordinat tabanlı çalışıyor ve JSON formatında hava tahmini sağlayabiliyor.

Temel mantık şu:

Çemişgezek koordinatı
        ↓
Open-Meteo Forecast API
        ↓
JSON response
        ↓
Repository / ViewModel
        ↓
Compose UI

API tarafında örneğin:

latitude
longitude
current
daily
timezone

gibi parametrelerle ihtiyaç duyulan veriler talep edilebiliyor.

Open-Meteo’nun resmi dokümantasyonuna göre Forecast API varsayılan olarak 7 günlük tahmin sağlıyor ve uygun parametreyle 16 güne kadar tahmin alınabiliyor.

API’den Gelen Her Veriyi Kullanıcıya Göstermek Gerekmiyor

Hava durumu API’leri onlarca farklı değişken sağlayabiliyor.

Örneğin:

basınç,
nem,
rüzgâr yönü,
bulutluluk,
görüş mesafesi,
toprak sıcaklığı

gibi pek çok veri alınabilir.

Ancak kullanıcı açısından daha fazla veri her zaman daha iyi deneyim anlamına gelmiyor.

Yerel rehber uygulamasında benim için daha önemli soru:

“Kullanıcının dışarı çıkmadan önce gerçekten hangi bilgiye ihtiyacı var?”

oldu.

Open-Meteo’nun güncel API dokümantasyonuna resmi Open-Meteo dokümantasyonundan ulaşılabilir.

5. Firebase Bildirimleri Güçlü Bir Özellik Ama Dikkatli Kullanılmalı

Çemişgezek Rehberi’nde duyuru ve etkinlikler önemli olduğu için push notification mantıklı bir özellik.

Bu tarafta Firebase Cloud Messaging (FCM) kullanıyorum.

FCM sayesinde uygulamanın yeni sürümünü yayınlamadan kullanıcılara belirli bilgilendirmeler göndermek mümkün.

Örneğin:

önemli bir yerel duyuru,
etkinlik,
uygulamaya eklenen önemli özellik,
özel gün bilgilendirmesi

push notification olarak gönderilebilir.

Firebase’in resmi Android dokümantasyonu FCM istemcilerinin mesaj alabilmesi için Firebase Messaging SDK entegrasyonunu ve Android istemci yapılandırmasını açıklıyor.

Teknik Olarak Gönderebilmek Yeterli Değil

Push notification konusunda öğrendiğim en önemli şey teknik değil.

Kullanıcıya mesaj gönderebiliyor olmak her gelişmede bildirim göndermek gerektiği anlamına gelmiyor.

Örneğin uygulamadaki küçük bir işletme açıklamasını değiştirmek için bütün kullanıcılara bildirim göndermek gereksiz olabilir.

Buna karşılık:

önemli bir etkinlik,
ulaşım değişikliği,
gerçek kullanıcı değeri sağlayan yeni özellik

bildirime daha uygun olabilir.

Çünkü çok sık bildirim göndermek:

bildirim izninin kapatılmasına,
uygulamanın rahatsız edici bulunmasına,
uygulamanın kaldırılmasına

kadar gidebilir.

Firebase Cloud Messaging Android entegrasyonu için Firebase’in resmi Android rehberi incelenebilir.

6. AdMob Eklemek “Ekrana Reklam Koymak”tan Daha Fazlası

Çemişgezek Rehberi’nde Google AdMob entegrasyonu da bulunuyor.

Reklam entegrasyonunda ilk teknik düşünce oldukça basit:

Banner alanını oluştur, reklamı yükle.

Gerçek uygulamada ise reklamın kullanıcı deneyimini bozmaması gerekiyor.

Özellikle bir rehber uygulamasında kullanıcı:

telefon numarasına dokunurken,
işletme kartını açarken,
yol tarifi seçerken,
içeriği kaydırırken

yanlışlıkla reklama dokunmamalı.

Adaptif Banner Neden Mantıklı?

Google’ın güncel AdMob Android dokümantasyonunda anchored adaptive banner formatı destekleniyor.

Adaptif banner’ın önemli avantajı, cihazın kullanılabilir genişliğine göre uygun reklam boyutunun hesaplanabilmesi.

Jetpack Compose kullanılan projelerde de Android View tabanlı AdView bileşeni Compose içerisine entegre edilebiliyor.

Burada amaç yalnızca reklam göstermek değil.

Reklamın:

farklı ekran boyutlarında taşmaması,
içeriği kapatmaması,
navigasyonu engellememesi,
yanlış tıklamaya yol açmaması

gerekiyor.

Test Reklamı Kullanmak Zorunlu Bir Alışkanlık Olmalı

Google’ın resmi Mobile Ads SDK rehberi geliştirme ve test sırasında canlı reklam yerine test reklamı kullanılmasını özellikle belirtiyor.

Bu yüzden uygulama geliştirme sırasında gerçek reklam birimiyle sürekli test yapmak yerine Google’ın test reklam birimleri kullanılmalı.

Adaptive Banner dokümantasyonu için Google Developers AdMob Android rehberi incelenebilir.

7. Google Play’e Çıkmak Projenin Sonu Değil

Çemişgezek Rehberi’nde de Dolap Hafızası projesinde yaşadığım önemli bir gerçek tekrar ortaya çıktı:

Production yayını bitiş noktası değil.

Google Play’e çıktıktan sonra yeni bir süreç başlıyor.

Artık:

gerçek cihazlar,
gerçek kullanıcılar,
gerçek işletme bilgileri,
kullanıcı geri bildirimleri,
Android güncellemeleri,
Google Play politikaları

işin içerisine giriyor.

API 36 Geçişi

Uygulamanın güncel sürümü Android 16, yani API 36 hedefleyecek şekilde güncellendi.

Bu yalnızca teknik bir tercih değil.

Google Play’in güncel şartına göre 31 Ağustos 2026’dan itibaren yeni standart Android uygulamaları ve uygulama güncellemelerinin API 36 veya üzerini hedeflemesi gerekiyor.

Bu nedenle Android uygulaması geliştirirken platform gereksinimlerini düzenli takip etmek gerekiyor.

Google Play hedef API gereksinimleri için Android Developers resmi sayfası takip edilebilir.

Target SDK’yı Artırmak Neden Sadece Bir Sayı Değişikliği Değil?

Gradle dosyasında:

targetSdk = 36

yazmak teknik olarak oldukça kolay.

Fakat yeni Android sürümünü hedeflemek uygulamayı yeni platform davranışlarına da dahil ediyor.

Bu yüzden benim uyguladığım yaklaşım:

target SDK’yı yükseltmek,
Android behavior changes dokümanlarını incelemek,
projeyi yeniden derlemek,
gerçek cihaz testleri yapmak,
kapalı veya internal test kanalında doğrulamak,
sonrasında production’a geçmek.

şeklinde.

Bu süreç önceki yazımda anlattığım Google Play uygulama geliştirme deneyimi ile de büyük ölçüde örtüşüyor.

Yerel Uygulamada İçerik Tasarımı Neden Teknik Tasarım Kadar Önemli?

Çemişgezek Rehberi’nde yalnızca teknik bilgiler bulunmuyor.

Tarihi yerler ve doğal güzellikler de uygulamanın önemli bir parçası.

Bu tarz içeriklerde açıklamanın tonu önemli.

Örneğin bir işletme açıklaması:

“Çemişgezek’in en iyi restoranıdır.”

şeklinde yazıldığında uygulama objektif rehber olmaktan uzaklaşabilir.

Bunun yerine:

“İlçe merkezinde hizmet veren aile restoranıdır.”

gibi nötr bir ifade daha doğru.

Aynı yaklaşımı tarihi ve kültürel içeriklerde de uygulamak gerekiyor.

Bilgi ile tanıtım metnini birbirinden ayırmak kullanıcı güvenini artırıyor.

Yerel Bir Uygulama Merkezi Sunucu Olmadan Çalışabilir mi?

Her yerel uygulamanın büyük bir backend altyapısına ihtiyacı yok.

Projenin kapsamına göre bazı bilgiler uygulamanın kendi veri katmanında tutulabilirken güncel olması gereken servisler API üzerinden alınabilir.

Örneğin Çemişgezek Rehberi’nde mantıksal olarak iki farklı veri türü bulunuyor:

Nispeten kalıcı bilgiler:

tarihi yerler,
işletme temel bilgileri,
acil telefonlar,
kategori yapısı.

Dinamik bilgiler:

hava durumu,
duyurular,
etkinlikler,
push notification içerikleri.

Bu ayrımı erken yapmak sistem tasarımını ciddi şekilde kolaylaştırabiliyor.

Open-Meteo Kullanırken Öğrendiğim Bir Başka Ders: API’yi UI’a Bağlamamak

API response’unu doğrudan Compose ekranına bağlamak başlangıçta hızlı görünebilir.

Ancak API değiştiğinde veya daha sonra farklı veri sağlayıcı kullanmak gerektiğinde UI kodu da değişmeye başlar.

Daha sürdürülebilir yaklaşım:

Open-Meteo
    ↓
API Model
    ↓
Repository
    ↓
Domain / UI Model
    ↓
ViewModel
    ↓
Compose

şeklinde katmanlar kullanmak.

Böylece örneğin API’nin hava kodunu:

weather_code = 61

şeklinde UI’a göndermek yerine ViewModel veya mapper tarafında:

Rainy

gibi uygulamanın anlayacağı bir modele dönüştürmek mümkün.

UI’ın hangi API’nin kullanıldığını bilmesine gerek kalmıyor.

Yerel Uygulamalarda En Büyük Avantaj: Kullanıcıya Çok Net Bir Değer Sunmak

Genel amaçlı uygulamalarda kullanıcıya uygulamanın neden gerekli olduğunu anlatmak zor olabilir.

Yerel uygulamalarda değer önerisi çok daha net.

Kullanıcı:

restoran arıyor,
eczane arıyor,
bir tarihi yere gitmek istiyor,
hava durumuna bakmak istiyor,
ulaşım bilgisine ihtiyaç duyuyor

ve uygulama bu ihtiyaca doğrudan cevap verebiliyor.

Ancak bu avantajın çalışabilmesi için bilgi güvenilir olmalı.

Yerel uygulamadaki en önemli ürün metriği yalnızca indirme sayısı değil:

Kullanıcı aradığı bilgiyi gerçekten bulabiliyor mu?

Küçük Bir İlçe İçin Uygulama Geliştirmenin Avantajı Ne?

Çemişgezek gibi daha küçük ve belirli bir bölgeyi hedeflemek ilk bakışta kullanıcı kitlesini sınırlandırıyor gibi görünebilir.

Ancak bunun önemli bir avantajı var:

Problem çok daha net tanımlanabiliyor.

Uygulamanın herkese hitap etmesi gerekmiyor.

Hedef kullanıcı:

Çemişgezek’te yaşayan,
Çemişgezek’i ziyaret eden,
ilçedeki işletme veya hizmetleri arayan

kişiler.

Bu da ürün kararlarında önemli bir filtre oluşturuyor.

Yeni bir özellik düşünürken:

“Bu özellik Çemişgezek’teki kullanıcıya gerçekten değer sağlıyor mu?”

sorusu sorulabiliyor.

Yeni Özellik Eklerken Kendime Sorduğum 3 Soru

Projeye yeni bir özellik eklemeden önce artık üç temel soru soruyorum.

1. Kullanıcı bunu gerçekten kullanacak mı?

Teknik olarak yapılabiliyor olması özelliğin gerekli olduğu anlamına gelmiyor.

2. Bu bilginin güncelliğini sürdürebilir miyim?

Bir özellik sürekli manuel veri güncellemesi gerektiriyorsa uzun vadede bakım maliyeti hesaplanmalı.

3. Bu özellik uygulamayı karmaşıklaştırıyor mu?

Yeni özellik kullanıcıya küçük bir değer sağlarken uygulamanın navigasyonunu ciddi şekilde karmaşıklaştırıyorsa tekrar düşünmek gerekebilir.

Çemişgezek Rehberi’nden Çıkardığım 7 Ana Ders

1. Yerel uygulamada veri kalitesi kod kalitesi kadar önemlidir.

Yanlış adres veya konum, mükemmel çalışan uygulamayı kullanıcı açısından kullanışsız hale getirebilir.

2. Kategori sistemi baştan ölçeklenebilir tasarlanmalıdır.

İçerik sayısı arttıkça navigasyon ve veri modeli hızla karmaşıklaşabilir.

3. Harita özelliğinde en önemli şey doğru koordinattır.

Navigasyon uygulaması doğru çalışsa bile yanlış koordinat kullanıcıyı yanlış yere götürür.

4. API’den alınabilecek her bilgiyi göstermek gerekmez.

Open-Meteo onlarca veri sunabilir; kullanıcıya gerçekten gerekli olanları seçmek daha iyi deneyim sağlar.

5. Push notification bir iletişim kanalıdır, reklam kanalı değildir.

Her küçük güncelleme için kullanıcıyı rahatsız etmek uzun vadede ters etki yaratabilir.

6. Reklam kullanıcı deneyiminin önüne geçmemelidir.

AdMob entegrasyonunda reklam yerleşimi ve ekran boyutları en az reklamın çalışması kadar önemlidir.

7. Google Play yayını ürün geliştirme sürecinin başlangıcıdır.

Gerçek kullanıcılar, cihazlar ve geri bildirimler production sonrasında ortaya çıkar.

Uygulamayı İncelemek İsteyenler İçin

Bu yazıda anlattığım teknik ve ürün kararlarının gerçek uygulamadaki sonucunu görmek isteyenler Çemişgezek Rehberi’ni Google Play üzerinden inceleyebilir.

👉 Çemişgezek Rehberi – Google Play

Uygulamanın özellikleri ve proje hakkında daha fazla bilgi için:

👉 Çemişgezek Rehberi proje sayfası

Sonuç

Yerel Android uygulaması geliştirme bana klasik bir mobil uygulama projesinden farklı dersler öğretti.

Çemişgezek Rehberi’nde Kotlin ve Jetpack Compose kodunu yazmak projenin yalnızca bir bölümüydü.

Gerçek zorluk:

yerel veriyi doğru tutmak,
işletmeleri doğru kategorize etmek,
koordinatları doğrulamak,
hava durumu servisini anlamlı şekilde sunmak,
bildirimleri kullanıcıyı rahatsız etmeden kullanmak,
reklamı kullanıcı deneyimini bozmadan yerleştirmek,
Google Play değişikliklerine sürekli uyum sağlamak

oldu.

Bir yazılım geliştirici açısından en değerli tarafı ise gerçek bir problemi baştan sona çözmeye çalışmak.

Çünkü eğitim projelerinde çoğu zaman veri kontrolümüz altında.

Gerçek uygulamalarda ise dünya sürekli değişiyor.

Bir işletme kapanabiliyor, Android’in politika şartı değişebiliyor, API davranışı değişebiliyor veya kullanıcının uygulamayı hiç tahmin etmediğimiz şekilde kullandığını görebiliyoruz.

Benim bu projeden çıkardığım en önemli sonuç şu:

İyi bir yerel uygulama yalnızca bulunduğu yeri anlatmaz; o yerde gerçekten işe yarar.

İlerleyen yazılarda Çemişgezek Rehberi’ndeki Open-Meteo hava durumu entegrasyonunu, Firebase bildirim yapısını, Jetpack Compose ekran mimarisini ve AdMob entegrasyonunu ayrı teknik yazılar halinde daha ayrıntılı ele alacağım.

Sık Sorulan Sorular

Çemişgezek Rehberi hangi teknolojiyle geliştirildi?

Android uygulaması Kotlin ve Jetpack Compose kullanılarak geliştirildi. Mimari tarafta MVVM yaklaşımı kullanılıyor.

Çemişgezek Rehberi hava durumunu nereden alıyor?

Hava durumu verileri koordinat tabanlı tahmin sağlayan Open-Meteo API üzerinden alınmaktadır.

Open-Meteo kaç günlük hava tahmini sağlayabiliyor?

Open-Meteo Forecast API varsayılan olarak 7 günlük tahmin sağlar ve forecast_days parametresi kullanılarak tahmin aralığı 16 güne kadar çıkarılabilir.

Uygulamada push notification için ne kullanılıyor?

Android kullanıcılarına push notification göndermek için Firebase Cloud Messaging kullanılıyor.

Uygulamada reklam var mı?

Evet. Uygulamada Google AdMob entegrasyonu bulunmaktadır. Reklam yerleşiminde kullanıcı deneyimini koruyacak adaptif banner yaklaşımı kullanılmaktadır.

2026’da Google Play için target SDK kaç olmalı?

31 Ağustos 2026’dan itibaren Google Play’e gönderilen yeni standart Android uygulamaları ve güncellemeler Android 16, yani API 36 veya daha yüksek bir API seviyesini hedeflemelidir.

Yerel rehber uygulamasında en önemli konu nedir?

Teknik altyapının yanında veri doğruluğu ve güncelliği en kritik konulardan biridir. Yanlış adres, telefon veya koordinat kullanıcı güvenini doğrudan etkiler.

Yerel uygulama geliştirmek için mutlaka backend gerekli mi?

Hayır. Uygulamanın ihtiyaçlarına göre nispeten statik bilgiler uygulamanın kendi veri katmanında tutulabilirken hava durumu veya bildirim gibi dinamik özellikler harici servislerle sağlanabilir.