Daha iyi bir Türkiye mümkün! Türkiye'nin girişimcilik ve inovasyon topluluğu·2018'den beri

Mobil Uygulama Geliştirme

/mobiluygulama

Fikirden App Store ve Google Play'e uzanan yolun tamamı tek kanalda. Swift, Kotlin, Flutter, React Native — platform fark etmez; uygulamanı nasıl yapacağını burada konuşuruz. Mimari kararlar, arayüz desenleri, yayın süreçleri, test ve sürüm yönetimi; ilk satırdan ilk indirmeye kadar ne varsa burada. Takıldığın yeri sor, öğrendiğini paylaş, uygulamanı yapan diğer üreticilerle omuz omuza ilerle.

#mobil uygulama geliştirme akışına dön
@damon · 11 gün önce

Klinik randevu uygulamam dikey kilitli: Android 17'nin büyük ekran kuralına nasıl hazırlanırım?

Birkaç klinik için yazdığım randevu ve hasta takip uygulaması üç yıldır manifestte dikey yöne kilitli duruyor. Bilinçli bir tercihti; sekreterler telefonda kullanıyordu, tablet kimsenin aklında yoktu. Şimdi iki klinik resepsiyona tablet koydu ve uygulamayı orada yatay kullanmak istiyorlar. Tam bu sırada Android 17 duyurusunda okudum: API 37'yi hedefleyen uygulamalarda büyük ekranlarda yön ve yeniden boyutlandırma kısıtlamaları kaldırılıyor, uygulamanın her pencere boyutuna uyum sağlaması bekleniyor.

Yani hedef API'yi yükselttiğim gün manifestteki kilidin tabletlerde bir anlamı kalmayacak. Bugün Play API 36 istiyor, ama her yıl olduğu gibi er geç 37'ye çıkmak zorunda kalacağız. Bunu son dakikaya bırakmak istemiyorum.

Denediklerim şunlar oldu. Emülatörde 10 inç tablet profili açıp kilidi kaldırdım. Randevu takvimi ekranı yatayda yarıya kadar boş kalıyor, liste tek sütun ve sağda koca bir beyaz alan var. Hasta formunda klavye açılınca kaydet düğmesi görünmez oluyor. Döndürmede yarım doldurulmuş form sıfırlanıyor, çünkü state'i doğru saklamamışım; telefonda dönme olmadığı için hiç fark etmemişim. En çok bu son madde korkuttu, sekreter yarım hasta kaydını kaybederse ilk beni arar.

Uygulama hâlâ büyük ölçüde XML layout, sadece iki yeni ekran Compose ile yazıldı. Google'ın yeni kütüphaneleri artık hep Compose tarafına verdiği de ortada.

Sorum şu: sıfırdan Compose'a geçiş bütçesi yok, iki kişilik bir işiz. Önce state kaybını çözüp, sonra en çok kullanılan üç ekranı genişliğe göre iki sütuna bölsem, gerisini tek sütun ama ortalanmış bıraksam mantıklı bir ara adım olur mu? Benzer bir geçişi yapan var mı, öncelik sırasını nasıl kurdunuz?
3 2 yorum
Yorumlar (2)
@endof · 11 gün önce 5
State kaybını en başa koyman çok doğru, onu çözmeden geri kalan her şey makyaj. ViewModel ve SavedStateHandle ile formu tutarsan hem döndürmede hem de sistem uygulamayı arka planda öldürdüğünde kurtulursun. Ekranları bölme kısmında bizim yaptığımız şey liste ve detayı, genişlik eşiği aşıldığında yan yana göstermekti. Bu tek değişiklik tablette uygulamanın yarısını derli toplu gösterdi. Takvimi en sona bırak, en zahmetlisi o.
@lamer · 10 gün önce 3
Tasarım tarafından bir not: resepsiyon tableti genelde masaya sabit, yatay ve kol mesafesinde duruyor. Dokunma alanlarını telefona göre biraz büyütmek ve formu iki sütun yerine ortalanmış, okunabilir genişlikte tek sütun bırakmak çoğu zaman daha iyi çalışıyor. İki sütunlu form göze güzel gelir ama klavyeyle alan alan ilerlerken sıra karışabiliyor. Bir gün klinikte sekreterin yanında oturup on dakika izlemen her şeyden değerli olur.