Auzef Mobil Programlama 2025-2026 Final Soruları
https://lolonolo.com/2026/06/11/mobil-programlama-2025-2026-final-sorulari-bahar/
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Selam millet. Bu final sınavı özet
0:02
rehberine hoş geldiniz. Sınav döneminin
0:04
ne kadar stresli olabileceğini biliyorum
0:06
ama bugün bu konuyu ezberlenecek sıkıcı
0:09
bir metin gibi değil, sıfırdan canavar
0:11
gibi çalışan bir mobil uygulama inşa
0:13
etmenin heyecan verici yolculuğu olarak
0:15
ele alacağız. Bu rehberin sonunda o
0:17
mobil programlama finalinde karşınıza
0:19
çıkacak en zorlu soruları bile
0:21
tereyağından kıl çeker gibi
0:23
çözeceksiniz. Hadi vakit kaybetmeden
0:25
başlayalım. Evet, incelememizin yol
0:28
haritası şöyle. Önce paketler ve
0:30
araçlarla temel atacağız. Ardından durum
0:32
yönetimine geçeceğiz. Sonra düzen
0:34
mimarisi ile arayüzü şekillendirip
0:37
entegrasyonlar ve performansla işi
0:39
zirvede bırakacağız. Birinci bölüm
0:41
paketler ve araçlar. Temeli sağlam
0:44
atmaya hazır mısınız? Başarılı bir
0:46
uygulama geliştirmek istiyorsak
0:48
geliştirici araç setimiz çok sağlam
0:50
olmalı değil mi? Kum üzerine bina
0:52
yapılmaz. İlk olarak Flutter Doctor
0:55
komutumuz var. Bu bizim başekimimiz.
0:57
Terminale yazıyorsunuz. SDK kurulumunuzu
1:00
ve ortam değişkenlerinizi sizin için
1:02
şipşak denetliyor. Sonra Dart Steve
1:04
Tools geliyor. Uygulamanın çalışma
1:07
zamanındaki davranışlarını izlemek,
1:09
bellek ne alemde görmek veya o karmaşık
1:11
vigit ağacının röntgenini çekmek için
1:13
birebir ve tabii ki Mokito. Birim
1:16
testleri yazarken canlı veri tabarına
1:18
bağlanıp işleri karıştırmak istemeyiz.
1:20
Mokito sayesinde sahte nesneler üreterek
1:23
testlerimizi tamamen izole ve güvenli
1:25
bir şekilde yapabiliyoruz. Gerçekten
1:27
hayat kurtarıyor. Yalnız popspec.
1:31
dosyasındaki dependencies bloğu ile
1:33
ilgili aklınızdan asla ama asla
1:35
çıkarmamanız gereken çok katı bir kural
1:37
var. Dışa bağımlılıklarınızı PUBDV
1:39
üzerinden, GitHub'dan ya da kendi
1:42
bilgisayarınızdaki yerel dosyalardan
1:44
rahatlıkla çekebilirsiniz. Bunda hiçbir
1:45
sorun yok. Ama standart paket yönetimi
1:49
doğrudan bir ZIP dosyasını yol olarak
1:51
göstermenize kesinlikle izin vermez.
1:53
Doğrudan zip dosyaları net bir şekilde
1:55
kural dışıdır. Sınavda bu detaya sakın
1:58
düşmeyin. Bölüm Durum yönetimi yani
2:02
hepimizin bildiği o meşhur adıyla state
2:04
management. Temelimizi attık. Şimdi
2:07
uygulamanın beynine yani verileri nasıl
2:09
yönettiğimize bakıyoruz. Burada iki
2:11
kavramı birbirinden ayırmak çok kritik.
2:14
Uygulama durumu yani App State dediğimiz
2:16
şey evdeki herkesin ortak kullandığı o
2:19
devasa mutfak buzdolabıdır. Tema
2:21
ayarları, oturum bilgileri veya
2:23
alışveriş sepeti gibi uygulamanın her
2:25
yerinden erişilmesi gereken verileri
2:27
burada tutarız. Ama diyelim ki tek bir
2:29
widgetin içinde dönüp duran basit bir
2:30
yükleme animasyonu var. E bunun için
2:32
koskoca buzdolabına ne gerek var? Bu
2:34
sadece sizin kendi cebinizdeki bir
2:36
detaydır. İşte sadece o anlık ve o
2:39
widgeta özel olan bu duruma da yerel
2:41
durum yani epimeral state diyoruz. Peki
2:44
bu veriler widget ağacında nasıl seyahat
2:46
ediyor? Burada can alıcı nokta şu.
2:48
Dışarıdaki yani üstteki bir widget state
2:51
set ile güncellendiğinde elindeki o tap
2:54
taze veriyi altındaki iç widget aktarmak
2:56
zorundadır. Bunu tam olarak nasıl
2:58
yapıyor dersiniz? İçteki widget'ın
3:00
yapıcı yani constructor fonksiyonunu
3:03
kullanarak yeni veriyi alırsınız ve
3:05
yukarıdan aşağıya doğrudan constructor
3:07
aracılığıyla teslim edersiniz. Olay
3:09
aslında bu kadar basit. Provider
3:11
kütüphanesini kullanırken performansı
3:14
zirveye taşımanın gerçekten çok şık bir
3:16
yolu var. Consumer Vigeton'ın child
3:19
parametresi. Düşünün arayüz
3:21
güncelleniyor ama ekranda hiç
3:23
değişmesine gerek olmayan sabit statik
3:26
kısımlar da var. İşte bu statik
3:28
elemanları consumer child parametresine
3:31
verdiğinizde sistem o kısımları tamamen
3:33
rahat bırakıyor. Gereksiz yere yeniden
3:36
çizmiyor. Bu da işlemci gücünden
3:38
inanılmaz bir tasarruf sağlıyor. Tam bir
3:40
performans canavarı özelliği
3:42
diyebiliriz. Durum yönetiminden
3:43
bahsetmişken arka planda bizim için kod
3:46
üreten serializable gibi kütüphaneleri
3:49
de unutmak olmaz. Kod yazarken
3:51
değişikliklerin arka planda eş zamanlı
3:53
olarak derlenmesini istiyorsanız
3:55
terminale yazacağınız tek bir sihirli
3:57
komut var. Flutter pub run build runner
4:00
watch. Bu watch komutu sayesinde her
4:03
kodu değiştirdiğinizde manuel olarak
4:05
tetikleme yapmakla uğraşmazsınız. Sistem
4:07
sizi arka planda izler ve her şeyi
4:09
anında halleder. 3ünc bölüm düzen
4:12
mimarisi ve sliver yapıları. Şimdi yavaş
4:15
yavaş uygulamamıza şekil verme zamanı.
4:18
Verilerimiz pürüzsüzce akıyor. Peki ya
4:21
arayüz? Kullanıcı arayüzü bileşenlerini
4:23
organize etmek için temel düzenleri
4:25
adımız gibi bilmeliyiz. Bileşenleri yan
4:28
yana yatay bir düzlemde mi dizeceksiniz?
4:30
Adınız row. Alt alta dikey bir dizilim
4:33
mi lazım? O zaman colalum
4:35
kullanıyorsunuz. Ama eğer iki boyutlu
4:37
hem satır hem de sütunlardan oluşan
4:39
kaydırılabilir bir ızgara matrisi
4:41
yaratmak istiyorsanız işte orada sahneye
4:44
grid viw çıkıyor. Kullanıcı arayüzünüze
4:46
asıl hayat veren şeylerden biri de
4:48
kesinlikle Sliver ailesidir. Düz sıkıcı
4:51
bir liste yerine kullanıcı sayfayı aşağı
4:53
kaydırdığında üst başlığın zarifçe
4:55
küçülerek kaybolmasını veya dinamik bir
4:58
şekil almasını istiyorsunuz diyelim.
5:00
İşte bunun için Sliver Upar veya Sliver
5:03
List gibi widgetlara başvurursunuz.
5:05
Uygulamanızın sıradan bir ödev projesi
5:07
gibi değil de gerçekten profesyonel ve
5:10
modern hissettirmesini sağlayan sihir
5:12
tam olarak budur. Şimdi sınavlarda
5:15
öğrencilerin en çok tuzağa düştüğü yere
5:17
geldik. Lütfen burayı çok iyi dinleyin.
5:20
Sayfalar arası geçişi sağlayan o
5:21
karmaşık yönlendirme mantığı var ya o
5:24
Navigator 2.0'dır. İçinde router, page,
5:28
router delegate gibi bileşenler
5:29
barındırır. Öte yandan scauffled
5:32
dediğimiz şey uygulamanızın sadece ve
5:34
sadece görsel iskeletidir. Size üstte
5:36
bir bar, altta bir içerik boşluğu açar.
5:39
Yani Scuffold kesinlikle bir navigasyon
5:41
bileşeni değildir. Sadece yapısal bir
5:43
kabuktur. Bu kritik ayrımı sınavda sakın
5:46
unutmayın. Müfredatınızdaki winforms
5:48
yapılarından birini de hızlıca
5:49
hatırlayalım. Table layout panel. Bu
5:52
yapı formunuzu tıpkı bir Excel tablosu
5:54
gibi satır ve sütunlara bölüyor. Ama
5:56
burada çok önemli bir kısıt var. Bu yapı
5:59
her bir hücreye tam olarak sadece bir
6:01
adet kontrol yerleştirmenize izin verir.
6:03
İkinciyi koyamazsınız. Hücreleri son
6:05
derece sıkı bir düzende kitler. sınavda
6:08
çıkarsa hücre başına tek kontrol
6:10
kuralını hemen aklınıza getirin. 4.üncü
6:13
ve son bölümümüz platform
6:14
entegrasyonları ve performans. Artık
6:17
uygulamamızı cilalama ve sahaya çıkarma
6:19
vakti geldi. Bir uygulama dış dünyayla
6:22
iletişim kurmak zorundadır. Eğer
6:24
uygulamanız kamerayı, konumu veya
6:26
interneti kullanacaksa bu sistem
6:28
izinlerini Android tarafında gidip
6:30
tıpıştıpışroidmanifest.xml
6:32
dosyasına yazmalısınız. Başka çare yok.
6:35
Cihaz hafızasında tema tercihi gibi
6:36
küçük ayarları anahtar değer çiftleri
6:38
olarak tutmak için shared preferences
6:41
kullanıyoruz. Ve eğer farklı işletim
6:43
sistemlerinin karmaşık dosya yolu
6:44
farklılıklarıyla uğraşmadan standart bir
6:46
yol bulmak istiyorsak Path Provider
6:49
paketi hızır gibi yetişiyor. Formül
6:51
basit. İzinler manifeste, yerel veriler
6:54
preferencesa. Düşünün ki binlerce öğelik
6:57
uçsuz bucoksuz bir listeniz var. Hepsini
6:59
aynı anda belleğe yüklemeye çalışırsanız
7:02
cihaz muhtemelen donar uygulamada çöker.
7:04
İşte burada tembel yükleme yani lazy
7:07
loading hayat kurtarıyor. List view
7:08
builder gibi yapılarla kullandığımız bu
7:10
performans hilesi sadece kullanıcının o
7:13
an ekranda gördüğü kısımları yükler.
7:15
Aşağı kaydırdıkça yenileri gelir,
7:17
eskiler uçar. Bu sayede bellekten
7:19
inanılmaz bir tasarruf elde edersiniz.
7:21
Animasyonlar harikadır ama pillerin en
7:24
büyük düşmanıdır. Diyelim ki bir
7:26
animasyon oynuyor. Kullanıcı o sırada
7:28
başka bir sayfaya geçti. Eğer önlem
7:30
almazsanız o animasyon arka planda
7:32
çalışmaya, işlemciyi yormaya ve pili
7:35
sömürmeye devam eder. Çözüm mü? Çok
7:37
basit. Animasyonunuza ekleyeceğiniz
7:39
vsing dis parametresi. Bu küçük sihirli
7:42
parametre widget ekran dışına çıktığı
7:44
animasyonu dondurur ve pil tüketimini
7:47
bıçak gibi keser. Ekran dışı öğeler için
7:49
bu kelimenin tam anlamıyla nihai pil
7:52
tasarrufu hilesidir. Uygulamalarınızda
7:54
mutlaka kullanın. Evet. temel araçlara,
7:58
sağlam bir mimariye ve uygulamanızı yağ
8:00
gibi akıcı yapacak performans ipuçlarına
8:02
artık sahipsiniz. Kodun sadece nasıl
8:05
yazıldığını değil, arka planda neden o
8:08
şekilde çalıştığını da birlikte çözdük.
8:10
Bu bilgiler sayesinde sadece finaldeki
8:13
soruları ezberden değil, mantığını
8:15
bilerek, anlayarak yanıtlayacaksınız.
8:18
Peki, öğrendiğiniz tüm bu sırları
8:20
kullanarak sadece o finali tam puanla
8:22
geçmeye değil, milyonlarca insanın
8:24
severek kullanacağı o harika uygulamayı
8:26
inşa etmeye hazır mısınız? Sınavda
8:28
hepinize yürekten başarılar diliyorum. O
8:30
kağıtları parçalayın.
#Jobs & Education

