Flutter tutorial'ına hoş geldin! Dart'ı sağlam bir şekilde öğrendiğin için, bu bölümde artık dil sözdizimiyle değil, Flutter'a özgü kavramlarla ilgileneceğiz.

#Flutter Nedir?

Flutter, Google tarafından geliştirilen, tek bir kod tabanından iOS, Android, Web, Windows, macOS ve Linux için native performanslı uygulamalar üretmeni sağlayan bir UI framework'üdür. "Framework" kelimesi önemli — Flutter bir dil değil (dili Dart'tır, zaten öğrendin), bir kütüphane/araç setidir; sana widget'lar, layout sistemi, animasyon motoru, render motoru gibi bir uygulama geliştirmek için gereken her şeyi sağlar.

#"Diğer Çözümlerden Farkı Ne?" — Kısa Bir Karşılaştırma

Mobil geliştirmede birkaç temel yaklaşım vardır:

1. Native geliştirme (Swift/iOS, Kotlin/Android) — en yüksek performans, ama iki ayrı kod tabanı yazman gerekir.
2. Köprü tabanlı framework'ler (React Native gibi) — JavaScript kodu yazarsın, bu kod native bileşenlere köprülenir (bridge). Bu köprü, bir performans darboğazı yaratabilir.
3. Flutter'ın yaklaşımı — Dart kodu, doğrudan native makine koduna derlenir (Bölüm 12'de öğrendiğin AOT derleme) ve Flutter, ekrana kendi çizim motoruyla (birazdan göreceğiz) her pikseli kendisi çizer. Native UI bileşenlerine (Android'in Button'u, iOS'un UIButton'u gibi) hiç dokunmaz — bunun yerine, aynı görünümü kendi motoruyla her platformda birebir aynı şekilde üretir.

Bu üçüncü yaklaşım, Flutter'ın "her platformda piksel piksel aynı görünüm" vaadinin temelidir — native bileşenlere bağımlı olmadığı için, bir Android'de görünen bir buton ile iOS'ta görünen aynı buton, gerçekten aynı kod tarafından çizilir.

#Widget Ağacı — "Her Şey Widget'tır" Felsefesi

Flutter'ın en temel felsefesi şudur: ekranda gördüğün her şey bir widget'tır. Bir metin, bir buton, bir boşluk (padding), hatta bazı durumlarda bir animasyon bile — hepsi birer widget'tır.

// Bu, ileride yazacağın gerçek koda çok benzer bir önizleme
Widget build(BuildContext context) {
  return Center(
    child: Text("Merhaba Flutter"),
  );
}

Burada Center bir widget, Text de bir widget — ve Text, Center'ın çocuğu (child). Bu, Bölüm 7'de (Dart) öğrendiğin kalıtım ve kompozisyon kavramlarının somut bir uygulamasıdır — Flutter'daki her widget, aslında Dart'ta bir class'tır (Widget'tan türeyen).

Widget'lar, bu şekilde iç içe geçerek bir ağaç (tree) yapısı oluşturur:

MaterialApp
  └── Scaffold
        └── Center
              └── Text("Merhaba Flutter")

Bu ağaç yapısı kavramı, Bölüm 4'te (Dart) öğrendiğimiz koleksiyon/veri yapıları kavramına benzer bir mantıkla çalışır — her widget'ın çocukları olabilir, ve tüm uygulama, bu iç içe geçmiş widget'lar ağacından oluşur.

#Üç Katmanlı Mimari — Widget, Element, RenderObject

Flutter'ın iç mimarisi, aslında üç ayrı ağaçtan oluşur — bu, Flutter'ın performansının ve esnekliğinin temelidir. Bunu anlamak, ileri seviye Flutter geliştirmede (özellikle performans optimizasyonu, Bölüm 9'da göreceğiz) kritik önemde.

#1. Widget Ağacı — "Ne İstiyorum" (Konfigürasyon)

Widget'lar, Bölüm 2'de (Dart) öğrendiğimiz immutable (değişmez) veri sınıfları gibi düşünülebilir — bir widget, "ekranda bunu şöyle görmek istiyorum" diyen basit bir açıklama (blueprint)'tir. Widget'ların kendisi, hiçbir görsel çizim yapmaz — sadece "ne istediğini" tarif eder.

#2. Element Ağacı — "Hayat Döngüsü ve Konum" (Yönetim)

Her widget, bir Element ile eşleştirilir. Element, widget ağacındaki konumu ve yaşam döngüsünü yönetir — widget'lar sürekli yeniden oluşturulurken (Bölüm 2'de bunu detaylı göreceğiz), Element'ler daha kalıcıdır ve widget'ların "kimliğini" (aynı widget'ın güncellenmiş bir versiyonu mu, yoksa tamamen yeni bir widget mı olduğunu) takip eder.

#3. RenderObject Ağacı — "Nasıl Çizilecek" (Gerçek Çizim)

RenderObject'ler, gerçek layout hesaplamasını (boyut, konum) ve gerçek çizimi yapan katmandır. Bölüm 2'de öğreneceğimiz "constraints go down, sizes go up" prensibi, tam olarak bu katmanda gerçekleşir.

Neden üç ayrı katman? Bu ayrım, Flutter'a büyük bir performans avantajı sağlar: bir widget her "yeniden oluşturulduğunda" (rebuild), Flutter, Element ve RenderObject ağaçlarını sıfırdan yeniden oluşturmak zorunda kalmaz — sadece neyin gerçekten değiştiğini karşılaştırır (buna "diffing" denir, Bölüm 13'te öğrendiğimiz kod üretimi kavramına benzer bir "akıllı güncelleme" mantığı) ve sadece gerekli değişiklikleri uygular. Bu, Bölüm 13'te (Dart) öğrendiğimiz garbage collection'ın "gereksiz nesne oluşturmaktan kaçınma" felsefesine paralel bir performans optimizasyonudur.

#Skia ve Impeller — Flutter'ın Çizim Motorları

Widget'ların "ne çizileceğini" belirlediğini, RenderObject'lerin "nasıl çizileceğini" hesapladığını gördük. Peki bu çizim, fiziksel olarak ekrana nasıl aktarılıyor?

Skia, Google'ın geliştirdiği, açık kaynaklı bir 2D grafik motorudur — Flutter'ın uzun süredir kullandığı render motoru. Skia, RenderObject'lerin ürettiği "çizim talimatlarını" alıp, bunları doğrudan GPU'ya (ekran kartına) göndererek pikselleri boyar.

Impeller, Flutter ekibinin geliştirdiği daha yeni bir render motorudur — Skia'nın bazı performans sınırlamalarını (özellikle "shader derleme takılması" denen, ilk kez çizilen bir efektte oluşan kısa donmalar) çözmek için tasarlandı. Impeller, önceden derlenmiş shader'lar kullanarak, çalışma zamanında beklenmedik takılmaları önlemeyi hedefliyor.

Şu anki durum: Flutter, platforma göre kademeli olarak Impeller'a geçiş yapıyor (iOS'ta varsayılan hale geldi, Android'de de aktif geliştirme altında). Bu, Bölüm 12'de (Dart) öğrendiğimiz JIT/AOT derleme ikiliğine benzer bir mühendislik kararı — Impeller, "önceden hazırlanmış" bir yaklaşımla, çalışma zamanı sürprizlerini azaltmayı hedefliyor.

#Bu Bilgi Neden Şimdi Önemli?

Bu ders, biraz soyut görünebilir — henüz hiç kod yazmadık. Ama bu mimariyi baştan anlamak, ileride:

• Bölüm 6'da (Flutter) setState()'in neden ve nasıl çalıştığını,
• Bölüm 9'da (Flutter) performans optimizasyonlarının neden işe yaradığını,
• Ve genel olarak "widget ağacı" mantığıyla düşünmeyi

çok daha kolay kavramanı sağlayacak. Şimdi, bir sonraki derste elini koda değdireceksin — ortam kurulumuyla.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Flutter, Dart kodunu native makine koduna derleyip, kendi çizim motoruyla ekranı kendisi çizen bir UI framework'üdür — native bileşenlere bağımlı değildir.
• "Her şey widget'tır" — ekrandaki her öğe, iç içe geçmiş bir widget ağacı oluşturur.
• Flutter'ın iç mimarisi üç katmandan oluşur: Widget (ne isteniyor), Element (yaşam döngüsü/konum), RenderObject (nasıl çizilecek) — bu ayrım, performanslı güncellemeleri mümkün kılar.
• Skia, Flutter'ın köklü render motoru; Impeller, shader takılmalarını önlemek için geliştirilen daha yeni motor.

#📝 Ödevler

• [ ] Kendi cümlelerinle, "Flutter'ın native bileşenlere bağımlı olmaması" ile "her platformda piksel piksel aynı görünüm" arasındaki ilişkiyi açıkla.
• [ ] Widget/Element/RenderObject üçlüsünü, gerçek hayattan bir benzetmeyle (örneğin bir mimari plan, inşaat yöneticisi, inşaat işçisi gibi) kendi örneğinle açıkla.
• [ ] Skia ile Impeller arasındaki temel farkı (shader derleme takılması bağlamında) kendi cümlelerinle özetle.
• [ ] React Native'in "köprü" (bridge) yaklaşımı ile Flutter'ın yaklaşımını karşılaştıran kısa bir not yaz — hangi senaryoda hangisinin avantajlı olabileceğini düşün.

Sıradaki konu: Bölüm 1 — Konu 2: Ortam Kurulumu (Flutter SDK, Android Studio/VS Code, Emulator/Simulator, Flutter DevTools'a İlk Bakış)

#Flutter SDK Kurulumu

Dart tutorial'ında Dart SDK'yı bağımsız kurmuştuk (Dart Bölüm 1 Konu 2'yi hatırla). Flutter SDK'sı, kendi içinde zaten bir Dart SDK'sı barındırır — yani Flutter'ı kurduğunda, aslında uyumlu bir Dart sürümü de otomatik olarak gelir.

Kurulum adımları (özet, platforma göre değişir):

1. flutter.dev üzerinden, işletim sistemine uygun Flutter SDK'yı indir.
2. SDK'yı bir klasöre çıkar (örneğin C:\src\flutter veya ~/development/flutter).
3. Flutter'ın bin klasörünü PATH ortam değişkenine ekle (Dart Bölüm 1'de PATH kavramını görmüştük — aynı mantık).
4. Terminali aç, kurulumu doğrula:

flutter doctor

flutter doctor — Kurulumun "Sağlık Kontrolü"

Bu komut, Flutter geliştirme ortamının eksiksiz olup olmadığını kontrol eder ve şuna benzer bir çıktı verir:

[✓] Flutter (Channel stable, 3.x.x)
[✓] Android toolchain - develop for Android devices
[✗] Xcode - develop for iOS and macOS (Xcode kurulu değil)
[✓] Chrome - develop for the web
[✓] Android Studio
[✓] VS Code
[✓] Connected device

Her [✗] işareti, eksik bir bileşeni gösterir — flutter doctor, genelde ne yapman gerektiğini de açıklar (örneğin "Xcode'u App Store'dan indirin" gibi). Tüm maddeleri yeşile çevirmek zorunda değilsin — örneğin sadece Android geliştirmek istiyorsan, Xcode'a (sadece iOS/macOS için gerekir) ihtiyacın olmaz.

#IDE Seçimi — VS Code vs Android Studio

Dart tutorial'ında VS Code'u önermiştik (Dart Bölüm 1 Konu 2). Flutter geliştirmede de iki ana seçenek var:

Pratik öneri: VS Code ile başla (Dart'ta zaten kullandığın araç) — Flutter ve Dart eklentilerini kur. Android emulator'ü yönetmek için Android Studio'yu sadece o amaçla (arka planda) kurman gerekecek, ama günlük kodlamayı VS Code'da yapabilirsin.

VS Code'a eklenti kurulumu:

1. Extensions (Uzantılar) sekmesine git.
2. "Flutter" ara, kur (bu otomatik olarak Dart eklentisini de kurar).

#Emulator / Simulator — Sanal Cihaz Kurulumu

Uygulamanı test etmek için gerçek bir telefona ihtiyacın yok — bir emulator (Android için sanal cihaz) veya simulator (iOS için sanal cihaz, sadece macOS'ta çalışır) kullanabilirsin.

Android Emulator kurulumu:

1. Android Studio'yu aç.
2. "Device Manager" (Cihaz Yöneticisi) bölümüne git.
3. "Create Device" ile bir sanal telefon modeli seç (örneğin Pixel 7).
4. Bir Android sürümü (system image) indir ve seç.
5. Emulator'ü başlat.

iOS Simulator (sadece macOS):

• Xcode kurulduğunda otomatik olarak gelir, open -a Simulator komutuyla açılabilir.

Gerçek cihaz kullanmak da mümkün:

• Android: Telefonda "Geliştirici Seçenekleri"ni açıp USB hata ayıklamayı (USB debugging) etkinleştir, USB ile bağla.
• iOS: Bir Apple geliştirici hesabıyla, cihazı Xcode üzerinden "güvenilir" olarak işaretle.

#İlk Kontrol — Bağlı Cihazları Listeleme

flutter devices

Bu komut, o anda kullanılabilir tüm cihazları (açık emulator'ler, bağlı gerçek cihazlar, hatta Chrome tarayıcısı — web geliştirme için) listeler:

2 connected devices:

sdk gphone64 x86 64 (mobile) • emulator-5554 • android-x64
Chrome (web)                 • chrome        • web-javascript

#Flutter DevTools — İlk Bakış

Dart tutorial'ında DevTools'a değinmemiştik (o zaman henüz görsel bir uygulama yoktu) — şimdi kısaca tanıyalım. Flutter DevTools, uygulamanı çalışırken analiz etmeni sağlayan bir dizi görsel araçtır — tarayıcıda açılan bir web arayüzü şeklinde çalışır.

DevTools'un sunduğu bazı araçlar (her birini ileride, ilgili bölümlerde derinlemesine işleyeceğiz):

• Widget Inspector: Widget ağacını (Bölüm 1 Konu 1'de öğrendiğimiz) görsel olarak inceleme.
• Performance/Timeline: Uygulamanın hangi noktalarda yavaşladığını analiz etme (Bölüm 9'da işleyeceğiz).
• Memory: Bellek kullanımını izleme (Dart Bölüm 13'te öğrendiğimiz garbage collection'ı görsel olarak gözlemleme).
• Network: API çağrılarını izleme (Bölüm 5'te işleyeceğiz).

DevTools, bir uygulama çalışırken otomatik olarak erişilebilir hale gelir — bunu bir sonraki derste, ilk projemizi çalıştırdığımızda gerçekten göreceğiz.

#Kurulumu Doğrulama — Örnek Bir Proje ile Test

Henüz kendi projemizi oluşturmadık (Bölüm 1 Konu 3'te yapacağız), ama Flutter'ın kendi örnek projesiyle hızlı bir test yapabilirsin:

flutter create test_projesi
cd test_projesi
flutter run

Eğer her şey doğru kurulduysa, bu komutlar bir emulator/cihaz üzerinde, Flutter'ın varsayılan sayaç uygulamasını (counter app) açacaktır. Bunu bir sonraki derste, kendi projemizi oluştururken detaylı olarak inceleyeceğiz.

#Sık Karşılaşılan Kurulum Sorunları

#🎯 Bu Dersten Çıkarılması Gerekenler

• Flutter SDK, kendi içinde uyumlu bir Dart SDK'sı barındırır — ayrıca Dart kurmana gerek yoktur.
• flutter doctor, geliştirme ortamının eksiksiz olup olmadığını kontrol eder ve eksikleri raporlar.
• VS Code (hafif, günlük kullanım) ve Android Studio (emulator yönetimi, derin Android ayarları) birlikte kullanılabilir.
• Emulator/simulator, gerçek cihaz olmadan test yapmanı sağlar; flutter devices ile bağlı cihazları listeleyebilirsin.
• Flutter DevTools, widget inceleme, performans analizi, bellek izleme gibi görsel araçlar sunan bir web arayüzüdür.

#📝 Ödevler

• [ ] Flutter SDK'yı kur, flutter doctor çalıştır, çıkan tüm maddeleri (eksik olanlar dahil) not al.
• [ ] VS Code'a Flutter ve Dart eklentilerini kur.
• [ ] Bir Android emulator oluştur (Android Studio üzerinden), başlat ve çalıştığını doğrula.
• [ ] flutter devices komutunu çalıştır, çıkan cihaz listesini incele.
• [ ] flutter create test_projesi ile örnek bir proje oluştur, flutter run ile çalıştır, varsayılan sayaç uygulamasının açıldığını gözlemle (bu projeyi silmene gerek yok, bir sonraki derste kendi projemizi ayrıca oluşturacağız).

Sıradaki konu: Bölüm 1 — Konu 3: İlk Proje Yapısı (pubspec.yaml, lib/, Klasör Mimarisi, flutter create Anatomisi)

#Proje Oluşturma

flutter create merhaba_dunya
cd merhaba_dunya

Bu komut, Dart Bölüm 12'de öğrendiğimiz dart create'e çok benzer, ama çok daha fazla dosya ve klasör üretir — çünkü Flutter, sadece Dart kodu değil, her platform için (Android, iOS, web, masaüstü) gerekli yapılandırma dosyalarını da oluşturur.

#Klasör Yapısına Genel Bakış

merhaba_dunya/
  android/          # Android'e özgü native yapılandırma
  ios/              # iOS'a özgü native yapılandırma
  web/              # Web'e özgü yapılandırma
  windows/          # Windows masaüstü yapılandırması
  macos/            # macOS masaüstü yapılandırması
  linux/            # Linux masaüstü yapılandırması
  lib/              # ⭐ SENİN YAZACAĞIN DART KODU BURADA
  test/             # Testler (Dart Bölüm 12'de öğrendiğimiz test yapısına benzer)
  pubspec.yaml      # Proje yapılandırması (Dart Bölüm 12'yi hatırla)
  analysis_options.yaml  # Lint kuralları (Dart Bölüm 13'ü hatırla)

Önemli gözlem: android/, ios/, windows/ gibi klasörler, native platform kodunu içerir — bunlara günlük geliştirmede neredeyse hiç dokunmayacaksın. Flutter, bu klasörleri otomatik olarak yönetir; sen sadece lib/ klasöründe Dart/Flutter kodu yazarsın, Flutter bunu her platform için uygun native pakete (APK, IPA, vb.) derler.

#lib/ Klasörü — Asıl Çalışma Alanın

lib/
  main.dart

Yeni bir proje, lib/ içinde tek bir dosyayla (main.dart) başlar. Bu, Dart tutorial'ında öğrendiğimiz main() fonksiyonunun (Dart Bölüm 1 Konu 3) bulunduğu dosyadır — Flutter uygulaması da, tıpkı bir Dart programı gibi, main() ile başlar.

Proje büyüdükçe, lib/ içinde kendi klasör yapını oluşturursun — Dart Bölüm 12'de öğrendiğimiz proje organizasyonu prensiplerini (models/, services/, screens/ gibi) burada uygularsın:

lib/
  main.dart
  screens/
    ana_ekran.dart
    detay_ekran.dart
  models/
    kullanici.dart
  services/
    api_servisi.dart

Bunu ilerleyen bölümlerde, gerçek bir uygulama büyüdükçe canlı olarak deneyimleyeceğiz.

#pubspec.yaml — Flutter Bağlamında

Dart Bölüm 12 Konu 53'te pubspec.yaml'ı detaylı işlemiştik. Flutter projelerinde bu dosya, ek olarak Flutter'a özgü bölümler içerir:

name: merhaba_dunya
description: "İlk Flutter projem"
publish_to: 'none'
version: 1.0.0+1

environment:
  sdk: '>=3.0.0 <4.0.0'

dependencies:
  flutter:
    sdk: flutter
  cupertino_icons: ^1.0.6

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^3.0.0

flutter:
  uses-material-design: true

Yeni gördüğümüz kısımlar:

• flutter: sdk: flutter — Flutter framework'ünün kendisini, bir bağımlılık olarak ekler (Dart Bölüm 12'de dependencies kavramını hatırla — Flutter, aslında kendisi de bu mekanizmayla projene "eklenir").
• version: 1.0.0+1 — Dart Bölüm 12'de gördüğümüz semantic versioning'e ek olarak, +1 kısmı build number'dır — her yayınladığın sürümde bu sayı artmalıdır (Bölüm 11'de, uygulama yayınlama konusunda tam olarak işleyeceğiz).
• flutter: uses-material-design: true — Google'ın Material Design ikon setini kullanmanı sağlar (bir sonraki bölümde MaterialApp'i öğrenirken bunu göreceğiz).
• cupertino_icons — iOS tarzı (Apple'ın "Cupertino" tasarım dili) ikonlar için.

#flutter create'in Ürettiği Varsayılan Kod

lib/main.dart dosyasını açtığında, Flutter'ın kendi örnek uygulamasını (sayaç uygulaması) göreceksin. Şimdilik kodun tamamını anlamana gerek yok (bunu Bölüm 1'in ilerleyen konularında ve Bölüm 2'de adım adım işleyeceğiz), ama genel yapısını tanıyalım:

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

Dikkatini çekmek istediğim noktalar (detaylı işlemeden önce):

• import 'package:flutter/material.dart'; — Dart Bölüm 12'de öğrendiğimiz import mekanizması, burada Flutter'ın kendi kütüphanesini (Material Design widget'larını içeren) dahil ediyor.
• runApp(const MyApp()); — Bu, Dart'taki main()'in Flutter'a özgü karşılığı; uygulamayı başlatan fonksiyon.
• class MyApp extends StatelessWidget — Dart Bölüm 7'de öğrendiğimiz extends (kalıtım) burada karşımıza çıkıyor! MyApp, Flutter'ın kendi StatelessWidget sınıfından türüyor — bir sonraki bölümde bunu tam olarak işleyeceğiz.
• const MyApp({super.key}); — Dart Bölüm 7'de öğrendiğimiz super (üst sınıf constructor'ına erişim) burada da geçerli.
• @override Widget build(...) — Dart Bölüm 7'de öğrendiğimiz @override — StatelessWidget'tan gelen bir metodu override ediyoruz.

Bu senin için harika bir haber: Bu kodun her satırı, Dart'ta öğrendiğin kavramların doğrudan uygulamasıdır. Yeni bir dil öğrenmiyorsun — sadece Flutter'ın kendi sınıflarını (StatelessWidget gibi) tanımaya başlıyorsun.

#Uygulamayı Çalıştırma

flutter run

Bu komut:

1. Kodunu JIT derler (Dart Bölüm 12'de öğrendiğimiz JIT/AOT ayrımını hatırla — geliştirme modunda JIT kullanılır).
2. Bağlı bir emulator/cihaza yükler.
3. Uygulamayı başlatır, terminalde canlı bir konsol açar (burada r tuşuna basarak hot reload tetikleyebilirsin — Bölüm 1 Konu 4'te tam olarak işleyeceğiz).

#build/ Klasörü — Derleme Çıktıları

Uygulamayı ilk kez çalıştırdığında, projede otomatik olarak bir build/ klasörü oluşur — burada, derlenmiş ara dosyalar bulunur. Bu klasör elle düzenlenmez, ve genelde versiyon kontrolüne (Git) dahil edilmez (.gitignore dosyasında zaten hariç tutulmuştur).

#.gitignore — Neyin Paylaşılmayacağı

Flutter projeleri, otomatik olarak bir .gitignore dosyasıyla gelir — bu, Dart Bölüm 12'de öğrendiğimiz pubspec.lock mantığına benzer bir "neyi paylaşma, neyi paylaşma" kararı içerir: build/ gibi otomatik üretilen klasörler, versiyon kontrolüne dahil edilmemelidir (çünkü herkesin kendi makinesinde yeniden üretilebilir).

#🎯 Bu Dersten Çıkarılması Gerekenler

• flutter create, her platform (Android, iOS, web, masaüstü) için native yapılandırma klasörleri üretir — ama sen sadece lib/ klasöründe çalışacaksın.
• pubspec.yaml, Dart'takiyle aynı temel yapıya sahiptir, ek olarak flutter: bölümü ve +build_number içerir.
• Varsayılan main.dart, Dart'ta öğrendiğin extends, super, @override gibi kavramları doğrudan kullanır — Flutter, yeni bir dil değil, Dart'ın üzerine kurulu bir framework.
• flutter run, kodu JIT derler ve bağlı bir cihaza yükler.
• build/ klasörü otomatik üretilir, elle düzenlenmez, versiyon kontrolüne dahil edilmez.

#📝 Ödevler

• [ ] flutter create ilk_projem ile yeni bir proje oluştur, klasör yapısını incele — her üst düzey klasörün ne işe yaradığını not al.
• [ ] pubspec.yaml dosyasını aç, flutter: bölümünü ve dependencies'i incele, Dart'taki pubspec.yaml'dan farkını belirle.
• [ ] lib/main.dart dosyasını aç, içindeki extends, super, @override kullanımlarını bul ve her birinin Dart'ta ne anlama geldiğini (öğrendiğin derslerden) hatırla.
• [ ] flutter run ile projeyi çalıştır, terminaldeki çıktıyı incele (hangi cihaza yüklendiği, hangi modda çalıştığı gibi bilgiler).
• [ ] Proje çalışırken oluşan build/ klasörünü bul, içeriğine göz at (düzenlemene gerek yok, sadece ne tür dosyalar olduğunu gör).

Sıradaki konu: Bölüm 1 — Konu 4: Hot Reload / Hot Restart Ne Yapıyor, Neden Önemli

Bölüm 1'in son konusundayız. Dart Bölüm 12 Konu 57'de JIT/AOT derlemeyi işlerken hot reload'a değinmiştik — şimdi bunu gerçek anlamda deneyimleyerek tam olarak anlayacağız.

#Hot Reload Nedir?

Hot reload, uygulamanı yeniden başlatmadan, kod değişikliklerini anında (genelde bir saniyeden kısa sürede) uygulamana yansıtma özelliğidir.

Nasıl tetiklenir?

• Terminalde flutter run çalışırken, r tuşuna bas.
• VS Code'da, kaydettiğinde (Ctrl+S/Cmd+S) otomatik tetiklenecek şekilde ayarlanabilir, ya da yıldırım simgesine tıklanır.

#Somut Bir Deney

lib/main.dart dosyasında (varsayılan sayaç uygulamasında), şu satırı bulalım:

Text(
  '$_counter',
  style: Theme.of(context).textTheme.headlineMedium,
),

Bu metnin rengini değiştirelim:

Text(
  '$_counter',
  style: Theme.of(context).textTheme.headlineMedium?.copyWith(color: Colors.red),
),

Dosyayı kaydet (hot reload otomatik tetiklenir) — uygulamanın sayacı sıfırlanmadan, sayı rengi anında kırmızıya dönüşür!

#Hot Reload'ın Arkasında Ne Oluyor? — Dart Bölüm 12'ye Bağlantı

Dart Bölüm 12 Konu 57'de JIT derlemenin "kod her değiştiğinde tüm programı baştan derlemek gerekmez" özelliğini öğrenmiştik. Hot reload, tam olarak bunu kullanır:

1. Kod değiştiğinde, Flutter sadece değişen kısımların yeni bir versiyonunu, çalışan Dart VM'ine (JIT ile) enjekte eder.
2. Flutter, widget ağacını (Bölüm 1 Konu 1'de öğrendiğimiz) yeni kodla yeniden oluşturur (rebuild).
3. Önemli olan: uygulamanın state'i (durumu) korunur! Sayaç değeri 5 iken hot reload yaptıysan, hâlâ 5'tir — sadece görünüm/davranış güncellenir.

#Hot Restart — Farklı Bir Araç

Terminalde 'R' (büyük harf) tuşuna bas

Hot restart, hot reload'dan farklıdır — uygulamayı tamamen yeniden başlatır, ama yine de (AOT derlemeye göre) hızlıdır, çünkü tam bir "cold start" (sıfırdan derleme + yükleme) değildir.

Fark tam olarak nerede?

#Ne Zaman Hot Reload Yetmez, Hot Restart Gerekir?

Hot reload, her değişikliği yansıtamaz — çünkü sadece "aynı state ile devam edilebilecek" değişiklikleri güvenle uygulayabilir. Şu durumlarda hot restart gerekir:

// Örnek: Bir sınıfın alan yapısını değiştirmek
class Sayac {
  int deger = 0;
  // int yeniAlan = 10; // Bu tarz bir değişiklik, HOT RELOAD ile bazen sorun çıkarabilir
}

• main() fonksiyonunun içeriğini değiştirdiğinde (hot reload, main()'i tekrar çalıştırmaz).
• Global değişkenlerin başlangıç değerini değiştirdiğinde.
• Bir State sınıfının (Bölüm 1 Konu 6'da göreceğiz) alan yapısını (yeni bir alan eklemek gibi) değiştirdiğinde — bazen hot reload bunu doğru yansıtamaz, "state uyumsuzluğu" görebilirsin.
• Genel kural: Eğer hot reload sonrası garip/beklenmedik bir davranış görüyorsan, hot restart dene — bu, çoğu "hot reload çalışmıyor gibi" sorununun çözümüdür.

#Neden Bu Kadar Önemli? — Geliştirici Deneyimine Etkisi

Bölüm 1 Konu 1'de Flutter'ın Dart'ı seçme sebeplerinden birinin JIT'in hot reload'ı mümkün kılması olduğunu söylemiştik. Şimdi bunun pratik değerini görüyorsun:

Hot reload olmadan bir dünya hayal et: Bir butonun rengini değiştirmek istiyorsun. Kodu değiştiriyorsun, tüm uygulamayı yeniden derlemen (native derleme, birkaç dakika sürebilir), yeniden yüklemen, ve eğer bu buton, bir dizi tıklamadan sonra ulaşılan bir ekrandaysa, o tıklamaları tekrar tekrar yapman gerekiyor — her küçük görsel değişiklik için.

Hot reload ile: Rengi değiştir, kaydet, bir saniye içinde sonucu gör — hatta derinlemesine bir ekranda, belirli bir state'teyken bile, o state korunarak değişikliği anında görürsün.

Bu, Flutter'ın geliştirici verimliliğinin en büyük kaynaklarından biridir — "değiştir, gör, tekrar değiştir" döngüsünü saniyeler seviyesine indirir.

#flutter run Terminalindeki Diğer Kısayollar

r  -> Hot reload
R  -> Hot restart
p  -> Widget sınırlarını (performans overlay'ini) göster/gizle
o  -> Platform temasını değiştir (Android/iOS arası geçiş, test amaçlı)
q  -> Uygulamayı sonlandır (quit)

Bu kısayolları bir sonraki bölümlerde, gerçek geliştirme yaparken sürekli kullanacaksın.

#Küçük Bir Deney Daha — State'in Korunduğunu Kanıtlamak

1. Sayaç uygulamasında, butona birkaç kere tıkla (sayaç 3 olsun diyelim).
2. Kodda, Text('$_counter') satırının üzerine yeni bir Text widget'ı ekle (örneğin Text('Merhaba!')).
3. Hot reload yap (r).
4. Gözlemle: Sayaç hâlâ 3 gösteriyor, ve yeni eklediğin "Merhaba!" metni de görünüyor — state kaybolmadı, sadece widget ağacı güncellendi.

Bu deney, Bölüm 1 Konu 1'de öğrendiğimiz Widget/Element/RenderObject ayrımının neden var olduğunu somut olarak gösteriyor: Element ağacı, widget'lar değişse bile kalıcılığını ve state'ini koruyor.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Hot reload, kodu JIT ile çalışan uygulamaya enjekte ederek, state'i koruyarak, saniyeler içinde değişiklikleri yansıtır.
• Hot restart, uygulamayı tamamen yeniden başlatır (main() dahil), state sıfırlanır — ama tam bir cold start'tan daha hızlıdır.
• Hot reload, widget ağacı/UI değişiklikleri için idealdir; global değişken/state yapısı değişikliklerinde hot restart gerekebilir.
• Bu özellik, Flutter'ın "değiştir-gör" geliştirme döngüsünü dramatik şekilde hızlandırır ve geliştirici verimliliğinin temel taşlarından biridir.

#📝 Ödevler

• [ ] Sayaç uygulamasında bir metnin rengini/boyutunu değiştir, hot reload ile anlık güncellemeyi gözlemle.
• [ ] Sayacı birkaç kere artır, sonra hot reload yap — state'in korunduğunu doğrula.
• [ ] Aynı senaryoyu hot restart ile tekrarla — bu sefer state'in sıfırlandığını gözlemle.
• [ ] main() fonksiyonunun içine bir print() ekle, hot reload sonrası bu print'in çalışmadığını, hot restart sonrası çalıştığını terminalde gözlemle.
• [ ] flutter run terminalindeki diğer kısayolları (p, o) dene, her birinin ne yaptığını gözlemle.

#🏁 Bölüm 1 Tamamlandı!

Flutter'ın ne olduğunu, iç mimarisini (Widget/Element/RenderObject, Skia/Impeller), ortamı kurmayı, proje yapısını ve hot reload/restart mekaniğini öğrendin. Artık gerçek bir Flutter projesini çalıştırabiliyor ve üzerinde değişiklik yapabiliyorsun.

Sıradaki durak Bölüm 2 — Widget'larla Düşünmek: "her şey widget'tır" felsefesini derinleştirecek, StatelessWidget vs StatefulWidget ayrımını ve temel layout widget'larını (Container, Row, Column) işleyeceğiz — burada gerçekten kendi arayüzünü yazmaya başlayacaksın.

Bölüm 2'ye hoş geldin — artık gerçekten kod yazmaya başlıyoruz. Bölüm 1 Konu 1'de kısaca değindiğimiz "her şey widget'tır" felsefesini şimdi derinlemesine işleyeceğiz.

#Widget Nedir? — Dart Bilginle Tam Bir Tanım

Bölüm 1'de widget'ları "ekranda bir şeyi tarif eden açıklamalar" olarak tanımlamıştık. Şimdi Dart bilginle daha kesin bir tanım yapalım: her widget, Dart'ta Widget sınıfından türeyen bir class'tır (Dart Bölüm 7'de öğrendiğimiz extends kalıtımı).

import 'package:flutter/material.dart';

class SelamWidget extends StatelessWidget {
  const SelamWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return Text('Merhaba Flutter!');
  }
}

Bu, senin kendi yazdığın ilk widget'ın. Dikkat et — bu tamamen tanıdık bir Dart class'ı: extends (Bölüm 7), constructor (Bölüm 6), @override (Bölüm 7), bir metod (build) — hepsi zaten bildiğin kavramlar.

#"Her Şey" Derken Gerçekten Her Şey

Flutter'da şaşırtıcı derecede çok şey widget'tır — sadece görsel öğeler değil:

Padding(          // bu bile bir widget! (boşluk ekleme)
  padding: const EdgeInsets.all(16.0),
  child: Text('Merhaba'),
)

Padding, ekranda kendi başına görünmeyen, sadece çocuğuna (child) boşluk ekleyen bir widget'tır. Bu, Flutter'ın felsefesini gösteriyor: layout (yerleşim), stil, davranış — hepsi widget'lar aracılığıyla ifade edilir, ayrı bir "stil dili" veya "layout dili" yoktur. Bölüm 6'da (Dart) öğrendiğimiz kompozisyon ilkesinin, burada UI tasarımına uygulandığını görüyorsun.

#Widget Ağacı — Somut Bir Örnek

class OrnekWidget extends StatelessWidget {
  const OrnekWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return Center(
      child: Padding(
        padding: const EdgeInsets.all(16.0),
        child: Container(
          color: Colors.blue,
          child: Text('Merhaba, Flutter!'),
        ),
      ),
    );
  }
}

Bu kod, şu ağacı oluşturuyor:

Center
  └── Padding
        └── Container (mavi renk)
              └── Text('Merhaba, Flutter!')

Her widget'ın tek bir görevi var:

• Center: çocuğunu ortalar.
• Padding: çocuğunun etrafına boşluk ekler.
• Container: bir arka plan rengi (ve başka birçok özellik) sağlar.
• Text: metni gösterir.

Bu, Dart Bölüm 7'de öğrendiğimiz "her class'ın tek bir sorumluluğu olmalı" (single responsibility) mantığının UI'a uygulanmış hali — büyük, her şeyi yapan tek bir widget yerine, küçük, tek işi yapan widget'ları iç içe geçirerek karmaşık arayüzler kuruyorsun.

#child Parametresi — Tek Çocuklu Widget'lar

Yukarıdaki örnekte, her widget'ın bir child parametresi vardı — bu, Dart Bölüm 5'te öğrendiğimiz named parametreler'dir:

Center(
  child: Text('Merhaba'),
)

Center'ın constructor'ı, child adında bir named parametre alıyor (Dart Bölüm 5 Konu 21'i hatırla — {required this.child} gibi bir tanım, aslında Flutter'ın kendi kaynak kodunda böyle yazılmış). Bu widget'lar tek bir çocuk alabilir — o çocuğu "sarmalar" (wrap eder) ve ona bir davranış/stil ekler.

#children Parametresi — Çoklu Çocuklu Widget'lar

Bazı widget'lar, birden fazla çocuk alabilir — bu durumda parametre adı children (çoğul) olur ve bir List<Widget> alır (Dart Bölüm 4'ü hatırla!):

Column(
  children: [
    Text('Birinci satır'),
    Text('İkinci satır'),
    Text('Üçüncü satır'),
  ],
)

Column, çocuklarını dikey olarak sıralar (bunu Bölüm 2 Konu 7'de tam olarak işleyeceğiz). Buradaki children: [...], Dart Bölüm 4'te öğrendiğimiz liste literal sözdizimidir — hiçbir yeni şey öğrenmene gerek yok, sadece bir widget'ın parametresi olarak bir liste geçiriyorsun.

#Widget'lar Neden immutable (Değişmez)?

Dart Bölüm 2'de final ve const kavramlarını öğrenmiştik. Flutter'da widget'ların hemen tüm alanları final'dır ve widget'ın kendisi genelde const olarak oluşturulabilir:

class MyWidget extends StatelessWidget {
  final String mesaj; // final — Dart Bölüm 6'yı hatırla

  const MyWidget({super.key, required this.mesaj}); // const constructor

  @override
  Widget build(BuildContext context) {
    return Text(mesaj);
  }
}

Neden bu kadar önemli? Bölüm 1 Konu 1'de öğrendiğimiz Widget/Element/RenderObject ayrımını hatırlarsan — widget'lar, "ne isteniyor" açıklamasıdır ve her rebuild'de yeniden oluşturulabilirler (bu, ucuz bir işlemdir çünkü widget'lar hafif nesnelerdir). Değişmez olmaları, Dart Bölüm 13 Konu 62'de öğrendiğimiz const nesnelerin bellek paylaşımı avantajını doğrudan kullanmalarını sağlar — aynı const widget, birden fazla yerde tek bir bellek konumunu paylaşarak kullanılabilir, gereksiz yeniden oluşturmadan kaçınılır.

#build() Metodu — Widget'ın "Ne İstediğini" Tarif Etmesi

@override
Widget build(BuildContext context) {
  return Text('Merhaba');
}

Her widget'ın (StatelessWidget veya StatefulWidget, Bölüm 2 Konu 6'da tam olarak göreceğiz) bir build() metodu vardır — bu, Dart Bölüm 7'de öğrendiğimiz override edilen bir metoddur (üst sınıf StatelessWidget'tan geliyor). build()'in görevi, widget ağacının bu parçasının nasıl görünmesi gerektiğini döndürmektir — Flutter, bu metodu gerektiğinde (widget yeniden oluşturulması gerektiğinde) çağırır.

BuildContext context parametresi nedir? Şimdilik, context'i "bu widget'ın ağaçtaki konumu hakkında bilgi taşıyan bir nesne" olarak düşün — Bölüm 4'te (tema, MediaQuery gibi konularda) bunun gerçek gücünü göreceğiz. Şu an sadece build() metodunun her zaman bu parametreyi aldığını bil.

#Küçük Bir Pratik — Kendi Widget'ını Yazma

import 'package:flutter/material.dart';

class KarsilamaKarti extends StatelessWidget {
  const KarsilamaKarti({super.key});

  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: const EdgeInsets.all(20.0),
      child: Container(
        color: Colors.amber,
        child: Column(
          children: [
            Text('Hoş Geldin!'),
            Text('Flutter öğreniyorsun'),
          ],
        ),
      ),
    );
  }
}

Bu widget, kendi başına yeniden kullanılabilir bir bileşendir — Dart Bölüm 6'da öğrendiğimiz "sınıflar yeniden kullanılabilir yapı taşlarıdır" prensibinin, UI dünyasındaki karşılığı. Bunu, uygulamanın herhangi bir yerinde, KarsilamaKarti() yazarak kullanabilirsin — tıpkı kendi yazdığın bir Dart class'ını başka bir yerde Kisi() diye kullanman gibi.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Her widget, Dart'ta Widget'tan (veya StatelessWidget/StatefulWidget gibi ara sınıflardan) türeyen bir class'tır — Dart'ta öğrendiğin extends, @override, constructor kavramları doğrudan geçerlidir.
• Widget'lar, tek bir görevi olan küçük parçalar halinde tasarlanır ve iç içe geçirilerek (kompozisyon) karmaşık arayüzler oluşturulur.
• child (tekil) ve children (List, çoğul) parametreleri, widget'ların nasıl iç içe geçtiğini belirler.
• Widget'lar genelde immutabledır (final alanlar, const constructor) — bu, performans ve bellek avantajı sağlar (Dart Bölüm 13'ü hatırla).
• build(BuildContext context), her widget'ın "ne görüneceğini" tarif eden, override edilen bir metoddur.

#📝 Ödevler

• [ ] StatelessWidget'tan türeyen, en az 3 seviye iç içe widget (örn. Center → Padding → Text) içeren kendi widget'ını yaz.
• [ ] Column ile children parametresine en az 3 Text widget'ı ekleyen bir örnek yaz.
• [ ] Kendi widget'ının hangi alanlarının final olduğunu belirle, neden final olmaları gerektiğini (Dart Bölüm 6/13 bağlamında) açıkla.
• [ ] Bir widget'ı, uygulamanın (varsayılan sayaç uygulamasının) içinde iki farklı yerde kullanarak, yeniden kullanılabilirliğini kanıtla.
• [ ] Kendi cümlelerinle, "Flutter'da neden ayrı bir 'stil dili' yok, her şey widget üzerinden ifade ediliyor" sorusunu, kompozisyon kavramıyla ilişkilendirerek açıkla.

Sıradaki konu: Bölüm 2 — Konu 6: StatelessWidget vs StatefulWidget + setState() Derinlemesine (Rebuild Mekanizması)

Bu, Flutter'ın en kritik konularından biri — burada öğrendiklerin, yazacağın hemen her uygulamada karşına çıkacak.

#StatelessWidget — "Hiç Değişmeyen" Widget'lar

Bir önceki derste hep StatelessWidget kullandık. Bu, kendi başına hiçbir zaman değişmeyen bir widget türüdür — oluşturulduktan sonra, aldığı veriler (parametreler) hiç değişmez.

class SelamKarti extends StatelessWidget {
  final String isim;

  const SelamKarti({super.key, required this.isim});

  @override
  Widget build(BuildContext context) {
    return Text('Merhaba, $isim!');
  }
}

SelamKarti("Ahmet") oluşturduğunda, bu widget her zaman "Merhaba, Ahmet!" gösterir. Eğer farklı bir isim göstermek istersen, yeni bir SelamKarti widget'ı oluşturman gerekir (örneğin SelamKarti("Ayşe")) — var olan widget'ı "güncelleyemezsin", çünkü Dart Bölüm 2'de öğrendiğimiz gibi, final isim alanı bir kere atanır, değişmez.

#StatefulWidget — "Zamanla Değişebilen" Widget'lar

Peki, bir sayaç uygulamasında olduğu gibi, kullanıcı etkileşimiyle değişen bir değer (örneğin tıklama sayısı) göstermen gerekiyorsa? İşte burada StatefulWidget devreye girer.

class SayacWidget extends StatefulWidget {
  const SayacWidget({super.key});

  @override
  State<SayacWidget> createState() => _SayacWidgetState();
}

class _SayacWidgetState extends State<SayacWidget> {
  int _sayac = 0;

  void _arttir() {
    setState(() {
      _sayac++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Sayaç: $_sayac'),
        ElevatedButton(
          onPressed: _arttir,
          child: Text('Artır'),
        ),
      ],
    );
  }
}

Bu, StatelessWidget'tan yapısal olarak çok farklı — burada iki ayrı class var. Şimdi bunu parça parça açalım.

#İki Sınıflı Yapı — Neden?

1. SayacWidget (StatefulWidget'tan türeyen):

class SayacWidget extends StatefulWidget {
  const SayacWidget({super.key});

  @override
  State<SayacWidget> createState() => _SayacWidgetState();
}

Bu class'ın kendisi, hâlâ immutable'dır (Bölüm 2 Konu 5'i hatırla — const constructor, final alanlar olurdu eğer parametre olsaydı). SayacWidget'ın tek görevi, createState() metoduyla kendi state'ini oluşturan başka bir nesneyi işaret etmektir.

2. _SayacWidgetState (State'ten türeyen):

class _SayacWidgetState extends State<SayacWidget> {
  int _sayac = 0; // BU alan DEĞİŞEBİLİR — final değil!
  // ...
}

İşte gerçek "değişebilir" veri burada yaşıyor — _sayac, final değil, var gibi normal bir alan (Dart Bölüm 2'yi hatırla). Bu class, Dart Bölüm 9'da öğrendiğimiz generic sınıflara bir örnek: State<SayacWidget>, "bu state, SayacWidget tipindeki bir widget'a ait" anlamına gelir.

Neden alt çizgi ile başlıyor (_SayacWidgetState)? Dart Bölüm 6 Konu 30'u hatırlarsan — _ öneki, bu class'ı dosyaya özel (private) yapar. Bu, Flutter'ın bir konvansiyonudur: State class'ları genelde private tutulur, çünkü dışarıdan doğrudan erişilmesine gerek yoktur.

#setState() — Rebuild Mekanizmasının Kalbi

void _arttir() {
  setState(() {
    _sayac++;
  });
}

setState(), Flutter'a "state'im değişti, lütfen build()'i tekrar çağır" demenin yoludur. Bu, kritik bir kural: _sayac++; yazarak değeri değiştirmek tek başına yeterli değildir — eğer bunu setState() içine koymazsan, Dart'ın belleğinde değer değişir ama Flutter, ekranı güncellemesi gerektiğini bilmez!

void _arttirYanlisYontem() {
  _sayac++; // ❌ değer değişti AMA Flutter bunu bilmiyor, ekran GÜNCELLENMEZ
}

void _arttirDogruYontem() {
  setState(() { // ✅ Flutter'a "değişiklik oldu, build() çağır" diyoruz
    _sayac++;
  });
}

Bu, Dart Bölüm 5'te öğrendiğimiz closure kavramının doğrudan bir uygulamasıdır — setState(), parametre olarak bir anonim fonksiyon (Dart Bölüm 5 Konu 24-25'i hatırla) alıyor, bu fonksiyonu çalıştırıyor (içindeki değişiklikleri uyguluyor), sonra Flutter'a "artık build()'i tekrar çağırabilirsin" sinyalini veriyor.

#Rebuild Mekanizması — Adım Adım Ne Oluyor?

setState() çağrıldığında, arka planda şu adımlar gerçekleşiyor (Bölüm 1 Konu 1'de öğrendiğimiz üç katmanlı mimariyi hatırla):

1. setState() içindeki kod çalışır — _sayac değeri gerçekten değişir (bu, sıradan bir Dart değişken ataması).
2. Flutter, bu widget'ın (ve State'inin) "kirli" (dirty) olduğunu işaretler — yani "yeniden çizilmesi gerekiyor" der.
3. Flutter'ın zamanlayıcısı (scheduler), bir sonraki "frame" (ekran yenileme döngüsü) sırasında, bu widget'ın build() metodunu tekrar çağırır.
4. build(), yeni bir widget ağacı döndürür (yeni _sayac değeriyle).
5. Bölüm 1 Konu 1'de öğrendiğimiz gibi, Flutter, eski ve yeni widget ağacını karşılaştırır (diffing) ve sadece gerçekten değişen RenderObject'leri günceller — tüm ekranı sıfırdan çizmez.

Bu son adım kritik: setState(), "her şeyi sıfırdan çiz" demek değildir — Flutter, akıllıca, sadece neyin değiştiğini bulup minimum işi yapar. Bu, Dart Bölüm 13 Konu 62'de öğrendiğimiz performans bilinçli tasarım felsefesinin somut bir örneği.

#setState()'in Kapsamı — Sadece O Widget mı, Tüm Ağaç mı?

class _SayacWidgetState extends State<SayacWidget> {
  int _sayac = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('Sayaç: $_sayac'), // bu ve alt widget'lar YENİDEN OLUŞTURULUR
        BuyukResimWidget(), // bu da rebuild olur, EĞER const değilse!
      ],
    );
  }
}

Önemli detay: setState() çağrıldığında, o State'in build() metodu tamamen yeniden çalışır — bu, build() içinde tanımlanan tüm widget ağacının (o State'e ait kısmın) yeniden oluşturulacağı anlamına gelir. Eğer BuyukResimWidget() gibi, değişmeyen bir widget varsa, bunu const yaparak (Bölüm 2 Konu 5'i ve Dart Bölüm 13 Konu 62'yi hatırla), Flutter'ın bu widget'ı gereksiz yere yeniden oluşturmaktan kaçınmasını sağlayabilirsin — bunu Bölüm 9'da (performans optimizasyonu) tam olarak işleyeceğiz.

#Ne Zaman StatelessWidget, Ne Zaman StatefulWidget?

StatelessWidget kullan, eğer:

• Widget, oluşturulduktan sonra hiç değişmeyecekse (sadece dışarıdan aldığı parametrelere göre görünür).
• Widget'ın kendi iç durumu (internal state) yoksa.

StatefulWidget kullan, eğer:

• Widget'ın, kullanıcı etkileşimi, zamanlayıcı, ağ cevabı gibi bir şeyle zamanla değişen bir verisi varsa.
• Örnekler: bir form alanının içeriği, bir animasyonun ilerleme durumu, bir API çağrısının sonucu (Bölüm 5'te göreceğiz).

Pratik bir kural: Eğer bir widget içinde _degisken = yeniDeger; yazman gerekiyorsa ve bu değişikliğin ekranda görünmesini istiyorsan, bu bir StatefulWidget olmalı — ve o değişikliği her zaman setState() içine sarmalısın.

#initState() — İlk Bakış (Detaylı Olarak Bölüm 4/5'te)

class _SayacWidgetState extends State<SayacWidget> {
  int _sayac = 0;

  @override
  void initState() {
    super.initState(); // Dart Bölüm 7'de öğrendiğimiz super çağrısı — ÖNCE üst sınıfın davranışı çalışmalı
    print('Widget ilk kez oluşturuldu');
  }

  // ...
}

initState(), bir State nesnesi ilk kez oluşturulduğunda, bir kere çağrılan bir metoddur — Dart Bölüm 6'da öğrendiğimiz constructor mantığına benzer, ama Flutter'ın kendi yaşam döngüsüne özgü bir kavram. Bunu, Bölüm 5'te (asenkron veri çekme) ve Bölüm 8'de (state management) çok daha derinlemesine işleyeceğiz.

#🎯 Bu Dersten Çıkarılması Gerekenler

• StatelessWidget, oluşturulduktan sonra değişmeyen widget'lardır; StatefulWidget, zamanla değişebilen bir "state" nesnesine sahiptir.
• StatefulWidget, iki class'tan oluşur: widget'ın kendisi (immutable) ve State sınıfı (değişebilir veri burada tutulur).
• setState(), Flutter'a "state değişti, build()'i tekrar çağır" demenin tek doğru yoludur — setState() olmadan yapılan değişiklikler, veriyi değiştirir ama ekrana yansımaz.
• setState() çağrıldığında, Flutter build()'i tekrar çalıştırır, ama Widget/Element/RenderObject ayrımı sayesinde sadece gerçekten değişen kısımları günceller.
• State class'ları genelde _ ile private tutulur (Flutter konvansiyonu).

#📝 Ödevler

• [ ] Kendi basit bir sayaç StatefulWidget'ı yaz (artı/eksi butonlu), setState() ile doğru şekilde güncelle.
• [ ] Bilerek setState() kullanmadan bir değişkeni değiştir, ekranın güncellenmediğini gözlemle; sonra setState() ekleyip düzelt.
• [ ] initState() içine bir print() ekle, widget ilk oluştuğunda bunun bir kere çalıştığını, ama setState() sonrası tekrar çalışmadığını gözlemle.
• [ ] Bir StatefulWidget içinde, hem değişen (state'e bağlı) hem değişmeyen (const yapılabilecek) widget'lar bulundur — hangisinin hangisi olduğunu belirle.
• [ ] Kendi cümlelerinle, "neden StatefulWidget iki ayrı sınıfa bölünmüş, tek sınıfta neden olmuyor" sorusunu, immutability (değişmezlik) kavramıyla ilişkilendirerek açıkla.

Sıradaki konu: Bölüm 2 — Konu 7: Temel Layout: Container, Row, Column, Stack, Padding, Align, Center

Bu derste, Flutter'da arayüz kurmanın temel yapı taşlarını öğreneceğiz. Bölüm 2 Konu 5'te öğrendiğin child/children kavramları burada somutlaşacak.

#Container — "İsviçre Çakısı" Widget

Container(
  width: 200,
  height: 100,
  color: Colors.blue,
  padding: const EdgeInsets.all(16),
  margin: const EdgeInsets.all(8),
  child: Text('Merhaba'),
)

Container, tek başına birden fazla işi yapabilen (boyut verme, renk, boşluk, kenarlık) çok yönlü bir widget'tır. Bilmen faydalı bir detay: Container, aslında Flutter'ın kaynak kodunda kendi başına bir RenderObject'e sahip değildir — arka planda, verdiğin özelliklere göre (padding, color, margin vb.) Padding, DecoratedBox, ConstrainedBox gibi daha küçük widget'ları otomatik olarak birleştiren bir "kolaylık widget'ıdır" (bir nevi kompozisyon sarmalayıcısı). Yani Container yazdığında, Flutter arka planda senin için birden fazla widget'ı otomatik olarak iç içe geçiriyor. Bu, Bölüm 2 Konu 5'te öğrendiğimiz "küçük, tek işi yapan widget'ları birleştirme" felsefesinin, framework'ün kendi içinde de uygulandığını gösteriyor.

padding ile margin farkı:

• padding: içerik ile widget'ın kendi sınırı arasındaki boşluk (içeriden).
• margin: widget'ın sınırı ile çevresindeki diğer widget'lar arasındaki boşluk (dışarıdan).

#Row ve Column — Yatay ve Dikey Dizilim

Row(
  children: [
    Icon(Icons.star),
    Text('Yıldız'),
    Icon(Icons.favorite),
  ],
)

Row, çocuklarını yatay (soldan sağa) sıralar. Column, aynı mantıkla dikey (yukarıdan aşağıya) sıralar:

Column(
  children: [
    Text('Birinci satır'),
    Text('İkinci satır'),
    Text('Üçüncü satır'),
  ],
)

mainAxisAlignment ve crossAxisAlignment:

Row(
  mainAxisAlignment: MainAxisAlignment.spaceBetween, // ana eksen (yatay, Row için)
  crossAxisAlignment: CrossAxisAlignment.center,       // çapraz eksen (dikey, Row için)
  children: [
    Text('Sol'),
    Text('Sağ'),
  ],
)

"Ana eksen" (main axis) ve "çapraz eksen" (cross axis) kavramı önemli: Row için ana eksen yatay, çapraz eksen dikeydir. Column için bu tam tersidir — ana eksen dikey, çapraz eksen yataydır. Bu terminoloji tutarlı kalır, sadece Row/Column'a göre yön değişir.

MainAxisAlignment seçenekleri (Dart Bölüm 7'de öğrendiğimiz enum'ları hatırla — bu tam olarak bir enum'dur):

• start, end, center — başa, sona, ortaya yasla.
• spaceBetween — elemanlar arasına eşit boşluk (kenarlarda boşluk yok).
• spaceAround — her elemanın etrafına eşit boşluk.
• spaceEvenly — tüm boşluklar (kenarlar dahil) eşit.

#Stack — Üst Üste Bindirme

Stack(
  children: [
    Container(width: 200, height: 200, color: Colors.blue),
    Positioned(
      top: 20,
      left: 20,
      child: Text('Üstte yazı', style: TextStyle(color: Colors.white)),
    ),
  ],
)

Row/Column'ın aksine, Stack, çocuklarını üst üste (z-ekseninde) yerleştirir — listedeki ilk eleman en altta, son eleman en üstte görünür. Positioned, bir Stack çocuğunun tam olarak nereye yerleştirileceğini (üstten/soldan/sağdan/alttan mesafe ile) belirtir.

Ne zaman kullanılır? Bir resmin üzerine yazı bindirmek, bir bildirim rozeti (badge) eklemek gibi "katmanlı" tasarımlar için idealdir.

#Padding — Sadece Boşluk

Padding(
  padding: const EdgeInsets.all(16.0),
  child: Text('Etrafında boşluk olan metin'),
)

Container'ın aksine, Padding, sadece boşluk ekleme işini yapar — başka hiçbir şeyi yapmaz (renk veremez, boyut veremez). Bu, Bölüm 2 Konu 5'te öğrendiğimiz "tek sorumluluk" ilkesinin saf bir örneği.

EdgeInsets çeşitleri:

EdgeInsets.all(16)                      // her yönden 16
EdgeInsets.symmetric(horizontal: 20, vertical: 10) // yatay 20, dikey 10
EdgeInsets.only(left: 8, top: 4)        // sadece belirtilen yönler

#Align — Belirli Bir Konuma Hizalama

Align(
  alignment: Alignment.topRight,
  child: Icon(Icons.close),
)

Align, çocuğunu ebeveyninin içinde belirtilen konuma yerleştirir. Alignment, aslında -1.0 ile 1.0 arasında bir koordinat sistemidir: Alignment(-1, -1) sol üst köşe, Alignment(1, 1) sağ alt köşe, Alignment(0, 0) tam orta.

#Center — Align'ın Özel Bir Hali

Center(
  child: Text('Ortalanmış'),
)

Bilmen faydalı bir detay: Center, Flutter'ın kaynak kodunda aslında Align'dan türeyen bir sınıftır (Dart Bölüm 7'de öğrendiğimiz extends kalıtımı) — alignment: Alignment.center ile sabitlenmiş bir Align'dır. Yani Center(child: X) yazmak, aslında Align(alignment: Alignment.center, child: X) yazmakla birebir aynı şeydir, sadece daha kısa ve niyeti daha net bir isim. Bu, Dart Bölüm 7'de öğrendiğimiz kalıtımın, "özel bir durumu daha kolay ifade etmek için" kullanılmasının gerçek bir örneği.

#Bunları Bir Arada Kullanmak

class ProfilKarti extends StatelessWidget {
  const ProfilKarti({super.key});

  @override
  Widget build(BuildContext context) {
    return Container(
      padding: const EdgeInsets.all(16),
      color: Colors.grey[200],
      child: Row(
        mainAxisAlignment: MainAxisAlignment.spaceBetween,
        children: [
          Column(
            crossAxisAlignment: CrossAxisAlignment.start,
            children: [
              Text('Ahmet Yılmaz'),
              Text('Flutter Geliştirici'),
            ],
          ),
          Icon(Icons.more_vert),
        ],
      ),
    );
  }
}

Bu örnek, öğrendiğin widget'ların (Container, Row, Column) gerçek bir arayüz parçası oluşturmak için nasıl birleştiğini gösteriyor — sol tarafta isim/unvan dikey sıralı, sağ tarafta bir ikon, ikisi arasında maksimum boşluk (spaceBetween).

#🎯 Bu Dersten Çıkarılması Gerekenler

• Container, birden fazla küçük widget'ı (Padding, DecoratedBox vb.) arka planda birleştiren çok amaçlı bir kolaylık widget'ıdır.
• Row (yatay) ve Column (dikey), mainAxisAlignment/crossAxisAlignment ile dizilimi kontrol eder; ana/çapraz eksen, Row/Column'a göre yön değiştirir.
• Stack, çocukları üst üste bindirir; Positioned, tam konumu belirler.
• Padding, sadece boşluk ekler; Align, belirli bir konuma hizalar; Center, aslında Align'ın özel (ortalanmış) bir alt sınıfıdır.

#📝 Ödevler

• [ ] Container ile boyut, renk ve padding'i olan bir kutu oluştur.
• [ ] Row içine 3 farklı widget koy, mainAxisAlignment'ı spaceBetween, spaceAround, spaceEvenly ile sırayla dene, farkı gözlemle.
• [ ] Stack kullanarak bir Container'ın üzerine Positioned ile bir metin bindir.
• [ ] Aynı sonucu üç farklı yöntemle (Center, Align(alignment: Alignment.center), ve mainAxisAlignment/crossAxisAlignment ile) elde et, hangisinin ne zaman daha uygun olacağını yorumla.
• [ ] Konu 7'deki "ProfilKarti" örneğine benzer, kendi tasarladığın bir kart widget'ı yaz (en az Row + Column + bir ikon içersin).

#🎮 Mini Uygulama — Basit Bir Kartvizit Ekranı

Öğrendiğin layout widget'larını birleştirerek, tek ekranlık bir dijital kartvizit tasarla. Gereksinimler:

• Bir Container içinde, Column ile dikey sıralanmış:
  • Üstte bir daire (bir Container ile, borderRadius kullanarak — istersen Icon ile bir profil ikonu koy)
  • İsim ve unvan (Text widget'ları)
  • Alt kısımda, Row ile yatay sıralanmış 3 ikon (telefon, e-posta, konum gibi)
• Padding ile genel kenar boşlukları ekle.
• Center ile tüm kartı ekranın ortasına yerleştir.

Bu projede setState()'e ihtiyacın yok — sadece StatelessWidget ile statik bir arayüz kur. Amaç, bu derste öğrendiğin widget'ları gerçek bir kompozisyonda birleştirme pratiği yapmak.

Sıradaki konu: Bölüm 2 — Konu 8: Constraint Sistemi ("Constraints Go Down, Sizes Go Up, Parent Sets Position")

Bu, Flutter layout'unun en temel mantığıdır — bunu anlamadan, "neden bu widget beklediğim boyutta değil" tarzı sorularla sürekli karşılaşırsın. Flutter ekibinin kendisi bu cümleyi resmi dokümantasyonda kullanır çünkü layout sisteminin özünü üç kısa ifadede özetler.

#Üç Kural

Constraints go down. Sizes go up. Parent sets position. (Kısıtlamalar aşağı iner. Boyutlar yukarı çıkar. Ebeveyn konumu belirler.)

Bunu Bölüm 1 Konu 1'de öğrendiğimiz RenderObject ağacı bağlamında düşünelim — bu üç kural, aslında RenderObject'lerin birbirleriyle nasıl "konuştuğunu" tarif ediyor.

#Kural 1: "Constraints Go Down" — Kısıtlamalar Aşağı İner

Bir widget, ebeveyninden (parent) bir "kısıtlama" (constraint) alır — bu kısıtlama, "minimum ve maksimum genişlik/yükseklik" şeklinde bir aralıktır, kesin bir boyut değil.

Container(
  width: 300,
  height: 200,
  child: Container(
    color: Colors.blue,
    // Bu iç Container'a boyut vermedik!
  ),
)

Dıştaki Container, içteki Container'a "en fazla 300x200 olabilirsin" kısıtlamasını iletir. İçteki Container, kendi boyutunu belirtmediği için, verilen kısıtlamanın maksimumunu kullanır — yani 300x200 olur.

#Kural 2: "Sizes Go Up" — Boyutlar Yukarı Çıkar

Her widget, aldığı kısıtlama içinde kendi boyutuna karar verir ve bu boyutu ebeveynine geri bildirir.

Center( // Center, çocuğuna "istediğin boyutu seçebilirsin, ben seni ortalarım" der
  child: Container(
    width: 100,
    height: 100,
    color: Colors.red,
  ),
)

Container, kendine verilen (gevşek — loose) kısıtlama içinde, kendi istediği 100x100 boyutunu seçiyor ve bunu Center'a "işte benim boyutum bu" diye bildiriyor.

#Kural 3: "Parent Sets Position" — Ebeveyn Konumu Belirler

Bir widget, kendi konumunu (ekranın neresinde olacağını) belirleyemez — çocuğun boyutu belli olduktan sonra, ebeveyn, bu çocuğu nereye yerleştireceğine karar verir.

Center(
  child: Container(width: 100, height: 100, color: Colors.red),
)

Container, kendi boyutunu (100x100) seçti, ama ekranın neresinde duracağına kendisi karar veremez — bunu Center widget'ı belirliyor (ortaya yerleştirerek).

#Somut Bir Örnekle Tüm Süreci İzleyelim

Container( // 1. Dış Container: 300x300 boyut VERİYOR (kısıtlama aşağı iner)
  width: 300,
  height: 300,
  color: Colors.grey,
  child: Center( // 2. Center: kısıtlamayı aynen aktarır ama "gevşetir" (loose yapar)
    child: Container( // 3. İç Container: kendi boyutuna karar VERİR (150x150)
      width: 150,
      height: 150,
      color: Colors.blue,
    ),
  ),
)

Akış:

1. Dış Container, 300x300 kesin kısıtlama ile başlıyor.
2. Bu kısıtlama, Center'a aşağı doğru aktarılıyor.
3. Center, bu kısıtlamayı kendi çocuğuna gevşek bir şekilde iletiyor: "en fazla 300x300 olabilirsin, ama istediğin kadar küçük de olabilirsin."
4. İç Container, kendine verilen bu esneklik içinde, kendi 150x150 boyutunu seçiyor ve bunu yukarı (Center'a) bildiriyor.
5. Center, artık çocuğunun boyutunu (150x150) bildiği için, onu kendi alanının (300x300) ortasına yerleştiriyor.

#Neden Bazen "Beklenmedik" Boyutlar Görürsün? — Yaygın Tuzak

Row(
  children: [
    Container(color: Colors.red, child: Text('Merhaba')),
    Container(color: Colors.blue, child: Text('Dünya')),
  ],
)

Bu genelde beklendiği gibi çalışır — her Container, içeriğinin (Text) boyutuna göre kendi boyutunu belirler. Ama şunu denersen:

Row(
  children: [
    Container(color: Colors.red, width: double.infinity), // ❌ HATA!
  ],
)

Bu hata verir! Neden? Çünkü Row'un ana ekseni (yatay), çocuklarına sınırsız genişlik kısıtlaması verir (Row, "istediğin kadar genişleyebilirsin" der) — ama sen Container'a width: double.infinity (sonsuz genişlik) vermeye çalışıyorsun. "Sonsuz kısıtlama içinde sonsuz boyut seç" paradoksal bir durum yaratır ve Flutter bunu bir hata olarak fırlatır: "BoxConstraints forces an infinite width."

Bu hatayı gördüğünde artık nedenini anlıyorsun — bu, tam olarak "constraints go down, sizes go up" prensibinin ihlal edildiği bir durum. Çözüm, genelde Expanded kullanmaktır (bir sonraki derste tam olarak işleyeceğiz).

#Neden "Gevşek" (Loose) ve "Sıkı" (Tight) Kısıtlama Ayrımı Önemli?

Bölüm 1 Konu 1'de öğrendiğimiz RenderObject katmanı, aslında her widget'a iki tür kısıtlama iletebilir:

• Tight (sıkı) kısıtlama: minimum = maksimum. "Tam olarak bu boyutta olmalısın." (width: 100, height: 100 verdiğinde oluşur)
• Loose (gevşek) kısıtlama: minimum = 0, maksimum = belirli bir değer. "En fazla şu kadar olabilirsin, istediğin kadar küçük olabilirsin."

Center, çocuğuna her zaman gevşek bir kısıtlama iletir — bu yüzden Center içindeki bir widget, "istediği" boyutu seçebilir. Container gibi bazı widget'lar ise, kendine boyut verildiğinde, çocuğuna sıkı bir kısıtlama iletebilir.

#Bu Bilgi Pratikte Ne İşine Yarar?

Bu, sadece teorik bir bilgi değil — Flutter'da "neden bu widget'ım büyümüyor/küçülmüyor" sorusuyla karşılaştığında, her zaman şu soruları sormalısın:

1. Bu widget'a ne tür bir kısıtlama geliyor? (Ebeveyni ne tür bir kısıtlama veriyor?)
2. Bu widget, kendi boyutuna nasıl karar veriyor? (İçeriğine göre mi, yoksa maksimum kısıtlamayı mı alıyor?)
3. Bu boyut, ebeveyne nasıl bildiriliyor ve ebeveyn onu nereye yerleştiriyor?

Bu üç soruyu sırayla sorduğunda, hemen her layout sorununu çözümleyebilir hale gelirsin — Bölüm 2 Konu 9'da öğreneceğimiz Expanded/Flexible gibi araçlar, tam olarak bu üç kuralı senin lehine kullanmanı sağlayan araçlardır.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Constraints go down: bir ebeveyn, çocuğuna minimum/maksimum genişlik-yükseklik aralığı (kısıtlama) iletir.
• Sizes go up: her widget, aldığı kısıtlama içinde kendi boyutuna karar verir ve bunu ebeveynine bildirir.
• Parent sets position: çocuğun boyutu belirlendikten sonra, onu nereye yerleştireceğine ebeveyn karar verir — widget kendi konumunu seçemez.
• "Sonsuz kısıtlama içinde sonsuz boyut" gibi paradoksal durumlar (Row içinde width: double.infinity), Flutter'ın en yaygın layout hatalarından birine yol açar.
• Loose (gevşek) ve tight (sıkı) kısıtlama ayrımı, bir widget'ın ne kadar "özgür" boyut seçebileceğini belirler.

#📝 Ödevler

• [ ] Bir Container içine boyut vermeden başka bir Container koy, dıştakinin boyutunu değiştirerek içtekinin boyutunun nasıl etkilendiğini gözlemle.
• [ ] Center içine bir Container koy, Container'a boyut ver, Center'ın onu nasıl konumlandırdığını gözlemle.
• [ ] Bilerek Row içinde width: double.infinity vererek hatayı tetikle, hata mesajını oku ve bu dersle ilişkilendirerek yorumla.
• [ ] Üç seviyeli bir widget ağacı kur (dış Container → Center → iç Container), her seviyede "kısıtlama nedir, boyut nedir, konum nasıl belirleniyor" sorularını kendi cümlelerinle cevapla.
• [ ] Kendi cümlelerinle, "neden bir widget kendi konumunu seçemiyor, sadece boyutunu seçebiliyor" sorusunu açıkla.

Sıradaki konu: Bölüm 2 — Konu 9: Expanded, Flexible, Spacer, Intrinsic Widget'lar

Bölüm 2'nin son konusundayız. Bir önceki derste öğrendiğimiz "Row içinde sonsuz genişlik hatası" sorununu çözen araçları burada işleyeceğiz.

#Expanded — Kalan Alanı Doldurma

Row(
  children: [
    Container(width: 50, color: Colors.red),
    Expanded(
      child: Container(color: Colors.blue), // kalan TÜM alanı doldurur
    ),
  ],
)

Expanded, Bölüm 2 Konu 8'de öğrendiğimiz constraint sistemini "senin lehine kullanan" bir widget'tır — Row'un, çocuklarına verdiği "sonsuz genişlik" imkanını, Expanded güvenli bir şekilde çocuğuna aktarır (artık "sonsuz boyut seç" paradoksuna düşmeden, çünkü Expanded, kalan kesin alanı hesaplayıp iletir).

Nasıl çalışır — adım adım:

1. Row, toplam genişliğini (300px diyelim) biliyor.
2. İlk çocuk (Container(width: 50)), 50px kullanıyor.
3. Row, kalan 250px'i, Expanded'e kesin (tight) bir kısıtlama olarak veriyor: "tam olarak 250px olmalısın."
4. Expanded'in çocuğu (Container), bu kesin kısıtlamayı alıyor ve 250px genişliğinde çiziliyor.

#flex Parametresi — Oransal Paylaşım

Row(
  children: [
    Expanded(
      flex: 1,
      child: Container(color: Colors.red),
    ),
    Expanded(
      flex: 2,
      child: Container(color: Colors.blue),
    ),
  ],
)

Birden fazla Expanded kullanıldığında, kalan alan, flex değerlerinin oranına göre paylaştırılır — burada flex: 1 ve flex: 2 olduğu için, mavi kutu kırmızının iki katı genişlikte olur (toplam 3 birim, kırmızı 1/3'ü, mavi 2/3'ü alır). Varsayılan flex değeri 1'dir.

#Flexible — Expanded'in Daha Esnek Kuzeni

Row(
  children: [
    Flexible(
      child: Container(width: 100, color: Colors.red),
    ),
    Expanded(
      child: Container(color: Colors.blue),
    ),
  ],
)

Flexible ile Expanded arasındaki fark: Expanded, aslında Flutter'ın kaynak kodunda Flexible'dan türeyen bir sınıftır (Dart Bölüm 7'de öğrendiğimiz extends kalıtımı) — Expanded, Flexible'ın fit: FlexFit.tight (yani "kesinlikle tüm kalan alanı doldur") ile sabitlenmiş bir versiyonudur. Flexible'ın kendisi, varsayılan olarak fit: FlexFit.loose kullanır — bu, çocuğun kendi istediği kadar yer kaplamasına izin verir, ama gerekirse kalan alana kadar büyüyebilir.

// Flexible (loose) — çocuk kendi boyutunu seçebilir, taşmaz
Flexible(child: Text('Kısa metin'))

// Expanded (tight) — çocuk HER ZAMAN kalan tüm alanı doldurur
Expanded(child: Text('Kısa metin')) // Text, ihtiyacından fazla yer kaplar (boş alan bırakır)

Bu, Bölüm 2 Konu 7'de Center'ın aslında Align'ın özel bir hali olduğunu öğrendiğimiz kalıba çok benzer — burada da Expanded, Flexible'ın özel (daha kısıtlayıcı) bir halidir.

#Spacer — Boş Alan Widget'ı

Row(
  children: [
    Text('Sol'),
    Spacer(), // aradaki tüm boşluğu doldurur
    Text('Sağ'),
  ],
)

Spacer, görünmez bir widget'tır — sadece kalan alanı doldurarak, iki widget'ı birbirinden uzaklaştırmaya yarar. Bilmen faydalı bir detay: Spacer, aslında kaynak kodda Expanded'i kullanan bir widget'tır (Expanded(child: SizedBox()) gibi bir kompozisyon) — yani Expanded'i zaten öğrendiğin için, Spacer'ın nasıl çalıştığını da örtük olarak biliyorsun. Bu, Row(children: [Text('Sol'), Spacer(), Text('Sağ')]) yazmanın, MainAxisAlignment.spaceBetween kullanmaya alternatif bir yol olduğunu gösteriyor — ikisi de benzer bir görsel sonuç verir, ama Spacer'a flex de verebilirsin, bu da ona MainAxisAlignment'ın sağlamadığı bir esneklik katar.

Row(
  children: [
    Text('Sol'),
    Spacer(flex: 2), // 2 birim boşluk
    Text('Orta'),
    Spacer(flex: 1), // 1 birim boşluk
    Text('Sağ'),
  ],
)

#Intrinsic Widget'lar — IntrinsicWidth, IntrinsicHeight

Bölüm 2 Konu 8'de öğrendiğimiz "constraints go down, sizes go up" kuralının istisnai bir durumunu ele alan widget'lardır. Normalde bir widget, kendi doğal (intrinsic) boyutunu bilmeden, sadece kendine verilen kısıtlamaya göre boyutlanır. Bazen, bir widget grubunun hepsinin aynı genişlikte olmasını istersin — örneğin bir Column içindeki tüm butonların, en geniş olanına göre eşit genişlikte olmasını:

IntrinsicWidth(
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.stretch,
    children: [
      ElevatedButton(onPressed: () {}, child: Text('Kısa')),
      ElevatedButton(onPressed: () {}, child: Text('Çok Daha Uzun Bir Buton Metni')),
    ],
  ),
)

IntrinsicWidth, önce tüm çocukların "doğal olarak istediği" genişliği hesaplar, en genişini bulur, sonra hepsine bu genişliği zorunlu kılar.

Önemli performans notu: IntrinsicWidth/IntrinsicHeight, normal layout sürecinden daha maliyetlidir — çünkü layout ağacını iki kere (önce "doğal boyutları öğrenmek için", sonra "gerçek boyutlandırma için") gezmesi gerekir. Bölüm 9'da (performans) bu tür maliyetli widget'ları ne zaman kullanmaman gerektiğini derinlemesine işleyeceğiz — şimdilik, gerçekten gerekmedikçe kullanmaktan kaçınmanı öneririm.

#Hepsini Bir Arada — Pratik Bir Örnek

class OranliBar extends StatelessWidget {
  const OranliBar({super.key});

  @override
  Widget build(BuildContext context) {
    return Container(
      height: 30,
      child: Row(
        children: [
          Expanded(
            flex: 3,
            child: Container(color: Colors.green), // %30 (3/10)
          ),
          Expanded(
            flex: 7,
            child: Container(color: Colors.grey[300]!), // %70 (7/10)
          ),
        ],
      ),
    );
  }
}

Bu, gerçek uygulamalarda gördüğün ilerleme çubukları (progress bar) veya oran gösterge çubuklarının temel mantığıdır — flex oranlarıyla, bir alanın yüzdesel dağılımını modelliyorsun.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Expanded, Row/Column içinde kalan alanı doldurur; flex parametresiyle birden fazla Expanded arasında oransal paylaşım yapılabilir.
• Flexible, Expanded'in daha esnek üst sınıfıdır — loose modda (varsayılan), çocuk kendi boyutunu seçebilir; Expanded, bunun tight (zorunlu, tam doldurma) versiyonudur.
• Spacer, görünmez bir boşluk widget'ıdır; arka planda Expanded kullanır, flex ile oransal boşluk oluşturabilir.
• IntrinsicWidth/IntrinsicHeight, bir grup widget'ı "en büyük olana göre" eşitler, ama normal layout'tan daha maliyetlidir.

#📝 Ödevler

• [ ] Row içine 3 farklı Container koy, Expanded ve farklı flex oranlarıyla (1:2:1 gibi) genişlik dağıt.
• [ ] Flexible ile Expanded arasındaki farkı, aynı Text widget'ını ikisiyle de deneyerek (görsel farkı gözlemleyerek) göster.
• [ ] Spacer kullanarak, bir Row içinde iki widget'ı birbirinden uzaklaştır; sonra aynı sonucu MainAxisAlignment.spaceBetween ile elde et, ikisini karşılaştır.
• [ ] IntrinsicWidth kullanarak, farklı uzunluktaki metinlere sahip birkaç butonu eşit genişlikte yap.
• [ ] Konu 9'daki "OranliBar" örneğine benzer, kendi flex oranlarınla bir "yüzde göstergesi" çubuğu tasarla.

#🎮 Mini Uygulama — Basit Bir "Bütçe Dağılımı" Ekranı

Bölüm 2'de öğrendiğin tüm layout araçlarını (Container, Row, Column, Stack, Padding, Align, Center, Expanded, Flexible, Spacer) birleştiren bir ekran tasarla:

Gereksinimler:

• Üstte bir başlık (Text, Padding ile boşluklu).
• Ortada, Expanded/flex kullanan bir "bütçe çubuğu" (en az 3 farklı renkli, farklı oranlı bölüm — örneğin "Kira: %40, Yemek: %30, Eğlence: %30").
• Çubuğun altında, her kategori için bir renk göstergesi ve isim (Row içinde küçük renkli kutular + Text, Spacer ile aralarında boşluk).
• Tüm ekran Center ve Padding ile düzgün ortalanmış ve boşluklu olsun.

Bu projede de StatelessWidget yeterli — setState()'e gerek yok. Amaç, Bölüm 2'nin tamamını kapsayan bir layout pratiği yapmak.

#🏁 Bölüm 2 Tamamlandı!

Widget'larla düşünmeyi, StatelessWidget/StatefulWidget ayrımını, temel layout widget'larını, constraint sistemini ve esnek boyutlandırma araçlarını (Expanded/Flexible/Spacer) öğrendin. Artık gerçek, düzenli arayüzler kurabiliyorsun.

Sıradaki durak Bölüm 3 — İlk Gerçek Ekranlar: MaterialApp/Scaffold/AppBar ile gerçek bir uygulama iskeleti kuracak, listeler (ListView) ve navigasyon (ekranlar arası geçiş) ile ilk çok ekranlı uygulamanı yazacaksın.

Bölüm 3'e hoş geldin. Şimdiye kadar tek widget'lık örnekler yazdık — bu derste, gerçek bir uygulamanın iskeletini kuracağız.

#MaterialApp — Uygulamanın Kök Widget'ı

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'İlk Uygulamam',
      theme: ThemeData(colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue)),
      home: const AnaEkran(),
    );
  }
}

Not: theme: parametresine eskiden (Material 2 döneminde) doğrudan ThemeData(primarySwatch: Colors.blue) gibi tek bir renk veriliyordu. Bu hâlâ çalışır ama artık eski (legacy) bir kalıp — güncel Flutter (Material 3 varsayılan olduğu için) ColorScheme.fromSeed(seedColor: ...) kullanmanı bekler; tek bir "tohum" renkten tutarlı, tam bir renk paleti üretir. Tema sistemini bütün detaylarıyla Bölüm 4 Konu 16'da işleyeceğiz — burada sadece doğru/güncel sözdizimini görmen yeterli.

Bölüm 1 Konu 3'te bu kodu görmüştük ama detaylandırmamıştık — şimdi tam olarak işleyelim. MaterialApp, Google'ın Material Design tasarım diline uygun bir uygulama iskeleti kurar — Bölüm 1'de öğrendiğimiz Widget ağacının en tepesinde yer alır ve şu önemli işlevleri sağlar:

• Tema yönetimi (theme:) — Bölüm 4'te tam olarak işleyeceğiz.
• Navigasyon altyapısı (Navigator — Bölüm 3 Konu 14'te göreceğiz).
• Yerelleştirme (localization) desteği.
• home: — uygulamanın ilk açılan ekranını belirtir.

#CupertinoApp — iOS Tarzı Alternatif

import 'package:flutter/cupertino.dart';

CupertinoApp(
  home: CupertinoPageScaffold(
    child: Center(child: Text('iOS stili')),
  ),
)

CupertinoApp, Apple'ın iOS tasarım dili ("Cupertino", Apple'ın merkezinin bulunduğu şehir) kullanılarak tasarlanmış widget'lar sunar. Pratikte: Çoğu Flutter uygulaması MaterialApp kullanır — Material Design, hem Android hem iOS'ta iyi görünen, evrensel bir tasarım dilidir. CupertinoApp'i genelde, özellikle iOS'a özgü bir görünüm istediğinde veya belirli Cupertino widget'larını (örneğin CupertinoSwitch) kullanmak istediğinde tercih edersin. İkisini karıştırmak da mümkündür — bir MaterialApp içinde bazı Cupertino widget'ları kullanabilirsin.

#Scaffold — Sayfa İskeleti

Scaffold(
  appBar: AppBar(
    title: Text('Ana Sayfa'),
  ),
  body: Center(
    child: Text('Merhaba!'),
  ),
  floatingActionButton: FloatingActionButton(
    onPressed: () {},
    child: Icon(Icons.add),
  ),
)

Scaffold, tek bir ekranın temel yapısını sağlayan bir widget'tır — Material Design'ın "sayfa şablonu" gibi düşünebilirsin. Bir uygulamada genelde her ekran (Bölüm 3 Konu 14'te göreceğimiz "sayfa" kavramı), kendi Scaffold'unu içerir.

Scaffold'un sunduğu temel "yuvalar" (slots):

• appBar: üstteki başlık çubuğu.
• body: ana içerik.
• floatingActionButton: sağ altta yüzen aksiyon butonu.
• bottomNavigationBar: alt navigasyon çubuğu (Bölüm 3 Konu 11'de listeler ile birlikte göreceğiz).
• drawer: kenardan açılan menü.

Scaffold, aslında Bölüm 2 Konu 7'de öğrendiğimiz Container'a benzer bir "kompozisyon widget'ı" — arka planda, verdiğin bu parçaları (appBar, body vb.) doğru layout ile birleştiren bir widget'tır (Dart Bölüm 6'da öğrendiğimiz "named parametreler" mantığıyla, her "yuvayı" ayrı bir named parametre olarak alıyor).

#AppBar — Üst Başlık Çubuğu

AppBar(
  title: Text('Uygulamam'),
  backgroundColor: Colors.blue,
  actions: [
    IconButton(
      icon: Icon(Icons.search),
      onPressed: () {},
    ),
    IconButton(
      icon: Icon(Icons.more_vert),
      onPressed: () {},
    ),
  ],
)

actions, Bölüm 2'de öğrendiğimiz List<Widget> alan bir parametredir (Dart Bölüm 4'ü hatırla) — AppBar'ın sağ tarafında görünecek ikon butonlarını sıralar. IconButton'daki onPressed, Dart Bölüm 5'te öğrendiğimiz anonim fonksiyon (callback) kavramının doğrudan bir uygulaması — "bu butona tıklandığında çalışacak kod."

#Hepsini Bir Arada — İlk Gerçek Ekranımız

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'İlk Uygulamam',
      theme: ThemeData(primarySwatch: Colors.blue),
      home: const AnaEkran(),
    );
  }
}

class AnaEkran extends StatelessWidget {
  const AnaEkran({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Ana Sayfa'),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Icon(Icons.flutter_dash, size: 80, color: Colors.blue),
            SizedBox(height: 16),
            Text('Flutter Öğreniyorum!', style: TextStyle(fontSize: 24)),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () {
          print('Butona tıklandı');
        },
        child: Icon(Icons.favorite),
      ),
    );
  }
}

Dikkat et: AnaEkran, ayrı bir class olarak tanımlandı (Dart Bölüm 6'yı hatırla — tek sorumluluk prensibi, burada "uygulama iskeleti" ile "ana ekranın içeriği" ayrı class'lara bölünüyor). MyApp, sadece uygulama düzeyinde ayarları (tema, başlık) yönetirken, AnaEkran, gerçek ekran içeriğinden sorumlu.

#SizedBox — Küçük Ama Sık Kullanılan Bir Widget

SizedBox(height: 16) // sadece dikey boşluk
SizedBox(width: 8)   // sadece yatay boşluk

SizedBox, Bölüm 2 Konu 7'de öğrendiğimiz Padding'e benzer bir "tek iş yapan" widget'tır — sadece belirli bir boyutta boş alan oluşturur (bir Column/Row içinde iki widget arasına boşluk koymak için çok yaygın kullanılır). Padding'den farkı, Padding'in bir çocuğun etrafına boşluk eklemesi, SizedBox'ın ise kendi başına bir boşluk widget'ı olarak kullanılabilmesidir (child olmadan da).

#🎯 Bu Dersten Çıkarılması Gerekenler

• MaterialApp, uygulamanın kök widget'ıdır; tema, navigasyon altyapısı ve ilk ekranı (home) yönetir.
• CupertinoApp, iOS tasarım diline uygun alternatif bir kök widget'tır.
• Scaffold, tek bir ekranın temel yapısını (appBar, body, floatingActionButton gibi "yuvalarla") sağlar.
• AppBar, üst başlık çubuğudur; actions ile sağ tarafa ikon butonları eklenebilir.
• SizedBox, belirli boyutta boş alan oluşturmak için kullanılan basit bir widget'tır.

#📝 Ödevler

• [ ] AppBar, body ve FloatingActionButton içeren bir Scaffold iskeleti oluştur.
• [ ] AppBar'a en az 2 actions ikonu ekle, her birine bir onPressed (şimdilik sadece print yazdıran) fonksiyonu bağla.
• [ ] MyApp ve ayrı bir ekran class'ı (örn. AnaEkran) yaparak, uygulama düzeyi ayarlar ile ekran içeriğini birbirinden ayır.
• [ ] SizedBox kullanarak bir Column içindeki widget'lar arasına dikey boşluklar ekle.
• [ ] MaterialApp'i CupertinoApp ile değiştirip (basit bir örnekte), görsel farkı gözlemle.

Sıradaki konu: Bölüm 3 — Konu 11: ListView, GridView, SingleChildScrollView (+ Builder Pattern)

#Neden Kaydırılabilir (Scrollable) Widget'lara İhtiyaç Var?

Bölüm 2'de öğrendiğimiz Column, çocuklarını dikey sıralar — ama eğer içerik ekran boyutunu aşarsa, Column kaydırma (scroll) yapmaz, sadece taşar ve bir hata/uyarı gösterir (sarı-siyah çizgili bir "overflow" göstergesi). Kaydırılabilir widget'lar, bu sorunu çözer.

#SingleChildScrollView — Basit Kaydırma

SingleChildScrollView(
  child: Column(
    children: [
      Container(height: 200, color: Colors.red),
      Container(height: 200, color: Colors.blue),
      Container(height: 200, color: Colors.green),
    ],
  ),
)

SingleChildScrollView, tek bir çocuğu (genelde bir Column) alır ve içerik ekrandan taşarsa, kullanıcının kaydırabilmesini sağlar. Bölüm 2 Konu 5'te öğrendiğimiz child parametresini hatırlarsan — burada da tek bir çocuk alıyor, tıpkı Center/Padding gibi.

Ne zaman kullanılır? İçeriğin sabit ve az sayıda olduğu, ama ekrana her zaman sığmayabileceği durumlarda (örneğin bir form ekranı).

#ListView — Kaydırılabilir Liste

ListView(
  children: [
    ListTile(title: Text('Öğe 1')),
    ListTile(title: Text('Öğe 2')),
    ListTile(title: Text('Öğe 3')),
  ],
)

ListView, Column + SingleChildScrollView'in birleşimi gibi düşünülebilir — hem dikey sıralar hem otomatik olarak kaydırılabilir yapar. ListTile, liste öğeleri için hazır, standart bir düzen sunan bir widget'tır (başlık, alt başlık, ikon gibi yuvaları vardır).

#ListView.builder — Büyük Listeler İçin Kritik Bir Kalıp

ListView.builder(
  itemCount: 100,
  itemBuilder: (BuildContext context, int index) {
    return ListTile(
      title: Text('Öğe ${index + 1}'),
    );
  },
)

Yukarıdaki basit ListView, tüm çocukları (children: [...]) anında oluşturur — 100 öğeli bir liste için, 100 widget'ı hemen, ekranda görünmese bile oluşturmuş olursun. Bu, Dart Bölüm 13 Konu 62'de öğrendiğimiz bellek verimliliği açısından israftır.

ListView.builder, bunun yerine "lazy" (tembel) çalışır — Dart Bölüm 11 Konu 51'de öğrendiğimiz lazy evaluation kavramını hatırlarsan, burada aynı felsefe uygulanıyor: itemBuilder fonksiyonu, sadece ekranda görünmesi gereken öğeler için çağrılır. Kullanıcı aşağı kaydırdıkça, yeni öğeler için itemBuilder o an çağrılır; ekrandan çıkan öğeler ise bellekten temizlenir (Dart Bölüm 13'te öğrendiğimiz garbage collection'a aday olur).

itemBuilder parametresi — Dart bilginle çözümleme:

itemBuilder: (BuildContext context, int index) {
  return ListTile(title: Text('Öğe ${index + 1}'));
}

Bu, Dart Bölüm 5'te öğrendiğimiz anonim fonksiyondur — iki parametre alıyor (context ve index), bir Widget döndürüyor. index, Dart Bölüm 4'te öğrendiğimiz liste indekslerine benzer bir mantıkla, kaçıncı öğenin oluşturulduğunu belirtir (0'dan başlar).

#ListView.separated — Öğeler Arasına Ayırıcı Ekleme

ListView.separated(
  itemCount: 20,
  itemBuilder: (context, index) => ListTile(title: Text('Öğe $index')),
  separatorBuilder: (context, index) => Divider(),
)

separatorBuilder, her öğe arasına (öncesine değil, sonrasına da değil, tam arasına) bir widget (genelde Divider — ince bir çizgi) ekler. Bu, itemBuilder'ın aynı lazy mantığıyla çalışır.

#GridView — Izgara Düzeni

GridView.builder(
  gridDelegate: SliverGridDelegateWithFixedCrossAxisCount(
    crossAxisCount: 2, // 2 sütun
    crossAxisSpacing: 8,
    mainAxisSpacing: 8,
  ),
  itemCount: 10,
  itemBuilder: (context, index) {
    return Container(
      color: Colors.blue[100 * ((index % 8) + 1)],
      child: Center(child: Text('Öğe $index')),
    );
  },
)

GridView, ListView'e çok benzer bir mantıkla çalışır (aynı builder kalıbı) ama öğeleri ızgara (grid) düzeninde, birden fazla sütunda gösterir. SliverGridDelegateWithFixedCrossAxisCount, "sabit sayıda sütun" kullanmanı sağlar (crossAxisCount: 2 — 2 sütunlu bir ızgara).

#"Builder Pattern" — Neden Bu Kadar Yaygın?

ListView.builder, GridView.builder, ve ilerleyen derslerde göreceğin birçok widget, aynı deseni (pattern) paylaşır: "kaç öğe olduğunu söyle, her öğenin nasıl görüneceğini tarif eden bir fonksiyon ver, ben gerektiğinde çağırırım." Bu, Dart Bölüm 5'te öğrendiğimiz higher-order function kavramının (fonksiyonu parametre olarak alan fonksiyon) Flutter'daki en yaygın uygulamasıdır.

Neden List<Widget> yerine bu desen tercih ediliyor?

// KÖTÜ pratik (büyük listeler için) — hepsini önceden oluşturur
ListView(children: List.generate(1000, (i) => ListTile(title: Text('$i'))))

// İYİ pratik — sadece görünenler oluşturulur
ListView.builder(itemCount: 1000, itemBuilder: (context, i) => ListTile(title: Text('$i')))

Dart Bölüm 4 Konu 20'de List.generate'i öğrenmiştik — burada onu kullanmak teknik olarak çalışır, ama 1000 widget'ı anında oluşturur. ListView.builder, aynı sonucu çok daha verimli şekilde, lazy olarak sağlar. Bu, Bölüm 9'da (performans) tam olarak işleyeceğimiz bir konunun erken bir önizlemesi.

#Gerçek Bir Örnek — Model Listesi ile

class Urun {
  final String ad;
  final double fiyat;
  Urun(this.ad, this.fiyat);
}

class UrunListesi extends StatelessWidget {
  final List<Urun> urunler;
  const UrunListesi({super.key, required this.urunler});

  @override
  Widget build(BuildContext context) {
    return ListView.builder(
      itemCount: urunler.length, // Dart Bölüm 4'te öğrendiğimiz .length
      itemBuilder: (context, index) {
        final urun = urunler[index]; // Dart'ta öğrendiğimiz indeksli erişim
        return ListTile(
          title: Text(urun.ad),
          trailing: Text('${urun.fiyat} TL'),
        );
      },
    );
  }
}

Bu, Dart Bölüm 6'da öğrendiğimiz class'lar ile Flutter'ın builder deseninin birleşimini gösteriyor — gerçek bir uygulamada, sabit sayıda öğe yerine, veri modelinden gelen (bir API'den, bir veritabanından) listeleri bu şekilde göstereceksin.

#🎯 Bu Dersten Çıkarılması Gerekenler

• SingleChildScrollView, tek bir çocuğu (genelde Column) kaydırılabilir yapar; küçük, sabit içerikler için uygundur.
• ListView, dikey kaydırılabilir bir liste oluşturur; ListView.builder, büyük listelerde lazy (sadece görünenleri oluşturarak) çalışır — Dart'taki lazy evaluation'a benzer bir performans optimizasyonu.
• itemBuilder, bir anonim fonksiyondur (context, index alır, widget döndürür) — "builder pattern"in temelidir.
• GridView.builder, aynı deseni ızgara düzeninde uygular.
• ListView.separated, öğeler arasına ayırıcı widget'lar eklemeyi sağlar.

#📝 Ödevler

• [ ] SingleChildScrollView içinde, ekranı aşan yükseklikte birkaç Container oluştur, kaydırmayı test et.
• [ ] ListView.builder ile 50 elemanlı bir liste oluştur, her satırı ListTile ile göster.
• [ ] ListView.separated kullanarak, öğeler arasına Divider ekle.
• [ ] GridView.builder ile 2 sütunlu, en az 10 öğeli bir ızgara oluştur.
• [ ] Kendi tanımladığın bir class'tan (örn. Urun) oluşan bir listeyi, ListView.builder ile gösteren bir widget yaz (Konu 11'deki UrunListesi örneğine benzer).

Sıradaki konu: Bölüm 3 — Konu 12: Text, TextStyle, Icon, Image, Asset Yönetimi

#Text — Temel Metin Widget'ı

Text(
  'Merhaba Flutter',
  style: TextStyle(
    fontSize: 24,
    fontWeight: FontWeight.bold,
    color: Colors.blue,
  ),
)

Text'i zaten önceki derslerde kullanmıştık — şimdi style parametresini derinlemesine görelim.

#TextStyle — Metni Biçimlendirme

TextStyle(
  fontSize: 18,
  fontWeight: FontWeight.w600, // 100-900 arası, w400 normal, w700 bold'a yakın
  fontStyle: FontStyle.italic,
  color: Colors.black87,
  letterSpacing: 1.2,
  height: 1.5, // satır yüksekliği (line-height) çarpanı
  decoration: TextDecoration.underline,
)

FontWeight, Dart Bölüm 7'de öğrendiğimiz enum'a çok benzer bir yapıdır (aslında FontWeight, sabit FontWeight.w100...w900 değerleri barındıran özel bir class'tır — enum'un biraz daha gelişmiş bir kuzeni). TextStyle'ın kendisi, Bölüm 2 Konu 5'te öğrendiğimiz immutable (değişmez) widget mantığına uygun tasarlanmıştır — bir TextStyle nesnesi oluşturduktan sonra değiştirilemez, yeni bir stil istiyorsan yeni bir TextStyle oluşturman gerekir.

#copyWith() — Var Olan Bir Stili "Değiştirerek Kopyalama"

TextStyle temelStil = TextStyle(fontSize: 16, color: Colors.black);

TextStyle kalinStil = temelStil.copyWith(fontWeight: FontWeight.bold);
// kalinStil: fontSize 16 (korundu), color siyah (korundu), fontWeight bold (değişti)

Bölüm 1 Konu 4'te (hot reload derste) .copyWith()'i kısaca kullanmıştık — şimdi bunun neden var olduğunu tam olarak anlıyoruz. TextStyle immutable olduğu için (final alanlar), var olan bir stili "temel alıp, sadece bir-iki özelliğini değiştirmek" istediğinde, tüm özellikleri tekrar yazmak zorunda kalmamak için copyWith() kullanılır — bu, sadece belirttiğin alanları değiştirir, belirtmediklerin aynı kalır.

Bilmen faydalı bir detay: copyWith(), Flutter'ın birçok immutable class'ında (TextStyle, EdgeInsets, ve ilerleyen bölümlerde göreceğin state yönetimi sınıflarında) tekrar eden bir kalıptır — bu, Dart Bölüm 6'da öğrendiğimiz method chaining/kompozisyon felsefesinin, "değişmez nesnelerle rahat çalışma" ihtiyacına verilen bir cevaptır.

#Icon — Simgeler

Icon(
  Icons.favorite,
  color: Colors.red,
  size: 32,
)

Icons, Flutter'ın Material Design ikon setine erişim sağlayan bir class'tır (Bölüm 1 Konu 3'te pubspec.yaml'da gördüğümüz uses-material-design: true ayarı, bu ikonların kullanılabilmesini sağlıyordu). Icons.favorite, Icons.search, Icons.home gibi binlerce hazır ikon mevcuttur.

#Image — Resim Gösterme

Flutter'da resim göstermenin birkaç farklı kaynağı vardır:

Image.network('https://ornek.com/resim.png') // internetten
Image.asset('assets/images/logo.png')         // proje içinden (asset)
Image.file(File('/yol/resim.png'))             // cihaz dosya sisteminden
Image.memory(Uint8List(...))                   // bellekte tutulan byte verisinden

Image.network, Bölüm 10'da (Dart) öğrendiğimiz Future/asenkron mantığı örtük olarak kullanır — resim internetten indirilene kadar, varsayılan olarak boş görünür (bunu Bölüm 5'te, loadingBuilder ile nasıl özelleştireceğini göreceğiz).

#Asset Yönetimi — Projeye Resim Ekleme

Dart Bölüm 12 Konu 53'te pubspec.yaml'ı derinlemesine işlemiştik — şimdi assets bölümünü ekleyelim.

1. Adım — Klasör oluştur:

proje_kökü/
  assets/
    images/
      logo.png

2. Adım — pubspec.yaml'da tanımla:

flutter:
  uses-material-design: true
  assets:
    - assets/images/logo.png
    # veya tüm klasörü dahil etmek için:
    - assets/images/

3. Adım — Kodda kullan:

Image.asset('assets/images/logo.png')

Kritik nokta: pubspec.yaml'a asset ekledikten sonra, hot reload yeterli değildir — Dart Bölüm 12'de öğrendiğimiz pubspec.yaml değişikliklerinde olduğu gibi, pubspec.yaml her değiştiğinde hot restart (Bölüm 1 Konu 4'ü hatırla) veya flutter pub get + yeniden çalıştırma gerekir. Bunun nedeni, asset listesinin, uygulamanın derlenme sürecinin bir parçası olarak "paketlenmesi" gerekmesidir — bu, JIT ile anlık güncellenebilecek bir kod değişikliği değil, yapılandırma değişikliğidir.

#Farklı Ekran Yoğunlukları İçin Asset'ler (Retina/HiDPI Desteği)

assets/
  images/
    logo.png       # 1x (temel çözünürlük)
    2.0x/
      logo.png     # 2x çözünürlük (yüksek DPI ekranlar için)
    3.0x/
      logo.png     # 3x çözünürlük

Flutter, cihazın ekran yoğunluğuna göre otomatik olarak doğru çözünürlükteki resmi seçer — sen kodda hep Image.asset('assets/images/logo.png') yazarsın, Flutter arka planda cihaza uygun olanı bulur. Bu, mobil geliştirmede yaygın bir kalıptır (web'deki srcset mantığına benzer).

#AssetImage vs Image.asset — İnce Bir Fark

Image.asset('assets/images/logo.png') // widget - doğrudan ekranda görünür

// AssetImage - bir "resim kaynağı" tanımı, kendisi widget DEĞİL
CircleAvatar(
  backgroundImage: AssetImage('assets/images/logo.png'),
)

Image.asset(...), aslında arka planda Image(image: AssetImage(...)) şeklinde çalışır — yani Image.asset, kolaylık sağlayan bir kısayol constructor'dır (Dart Bölüm 6 Konu 27'de öğrendiğimiz named constructor kavramının, Flutter'ın kendi kütüphanesindeki bir örneği!). AssetImage, bazı widget'ların (örneğin CircleAvatar, DecorationImage) Image widget'ı değil, resim kaynağı beklediği durumlarda kullanılır.

#Hepsini Bir Arada — Profil Kartı Örneği

class ProfilKarti extends StatelessWidget {
  const ProfilKarti({super.key});

  @override
  Widget build(BuildContext context) {
    return Row(
      children: [
        CircleAvatar(
          radius: 30,
          backgroundImage: AssetImage('assets/images/profil.png'),
        ),
        SizedBox(width: 12),
        Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: [
            Text(
              'Ahmet Yılmaz',
              style: TextStyle(fontSize: 18, fontWeight: FontWeight.bold),
            ),
            Row(
              children: [
                Icon(Icons.star, color: Colors.amber, size: 16),
                Text(' 4.8'),
              ],
            ),
          ],
        ),
      ],
    );
  }
}

#🎯 Bu Dersten Çıkarılması Gerekenler

• TextStyle, immutable bir stil tanımıdır; .copyWith(), var olan bir stili temel alıp belirli alanları değiştirerek yeni bir stil oluşturur.
• Icon, Icons class'ı üzerinden Material Design ikonlarına erişim sağlar.
• Image.network/asset/file/memory, farklı kaynaklardan resim göstermenin yollarıdır.
• Asset'ler pubspec.yaml'da tanımlanmalı ve değişikliklerden sonra hot restart (veya yeniden çalıştırma) gerekir.
• Image.asset, aslında Image(image: AssetImage(...))'in kısayoludur — Flutter'ın kendi kütüphanesinde named constructor kullanımına bir örnek.

#📝 Ödevler

• [ ] Farklı TextStyle özellikleriyle (fontSize, fontWeight, color, letterSpacing) bir metin oluştur.
• [ ] copyWith() kullanarak, temel bir stili temel alıp sadece rengini değiştiren yeni bir stil oluştur.
• [ ] Projene bir resim ekle (assets klasörüne), pubspec.yaml'da tanımla, Image.asset ile göster.
• [ ] Image.network ile internetten bir resim göster.
• [ ] Konu 12'deki "ProfilKarti" örneğine benzer, kendi tasarladığın bir profil widget'ı yaz (CircleAvatar + isim + ikon içersin).

Sıradaki konu: Bölüm 3 — Konu 13: Custom Widget Yazma Prensipleri (Composition Over Inheritance)

Şimdiye kadar birkaç kendi widget'ımızı yazdık (AnaEkran, ProfilKarti gibi) ama bunun arkasındaki prensipleri sistematik olarak işlemedik. Bu ders, iyi bir Flutter geliştiricisinin nasıl düşündüğünü öğretiyor.

#"Composition Over Inheritance" Ne Demek?

Bu, yazılım mühendisliğinde genel bir prensiptir: "kalıtım yerine kompozisyonu tercih et." Dart Bölüm 7'de hem extends (kalıtım) hem de widget'ları iç içe geçirmeyi (kompozisyon) öğrendik — Flutter, neredeyse her zaman kompozisyonu tercih eder.

Kalıtım ile yaklaşım (Flutter'da NADİREN kullanılır):

// ❌ Genelde ÖNERİLMEZ — mevcut bir widget'tan extends etmeye çalışmak
class BuyukKirmiziMetin extends Text {
  BuyukKirmiziMetin(String data) : super(data, style: TextStyle(fontSize: 24, color: Colors.red));
}

Kompozisyon ile yaklaşım (Flutter'ın standart yolu):

// ✅ Doğru yaklaşım — yeni bir widget yaz, içinde Text'i KULLAN
class BuyukKirmiziMetin extends StatelessWidget {
  final String data;
  const BuyukKirmiziMetin(this.data, {super.key});

  @override
  Widget build(BuildContext context) {
    return Text(
      data,
      style: TextStyle(fontSize: 24, color: Colors.red),
    );
  }
}

Neden Flutter kompozisyonu tercih ediyor? Bölüm 1 Konu 1'de öğrendiğimiz Widget/Element/RenderObject üçlü mimarisini hatırlarsan — Flutter'ın çoğu widget'ı, karmaşık iç davranışlara sahiptir. Bunlardan extends etmeye çalışmak, o widget'ın iç detaylarına bağımlı olmak demektir (Dart Bölüm 7'de "kırılgan taban sınıf" (fragile base class) sorunundan bahsetmiştik dolaylı olarak) — Flutter ekibi, widget'ların iç yapısını değiştirebilme özgürlüğünü korumak için, sen widget'ları extend etmek yerine, onları build() içinde kullanarak yeni widget'lar oluşturasın diye tasarlamıştır.

#Ne Zaman Yeni Bir Widget Yazmalısın?

Kural: Aynı widget ağacı parçasını iki veya daha fazla yerde kopyalıyorsan, bunu bir widget'a çıkar.

// ❌ Kod tekrarı — aynı yapı iki yerde
Widget build(BuildContext context) {
  return Column(
    children: [
      Container(
        padding: EdgeInsets.all(16),
        decoration: BoxDecoration(border: Border.all(color: Colors.grey)),
        child: Text('Kart 1'),
      ),
      Container(
        padding: EdgeInsets.all(16),
        decoration: BoxDecoration(border: Border.all(color: Colors.grey)),
        child: Text('Kart 2'),
      ),
    ],
  );
}

// ✅ Doğrusu — tekrarlanan yapıyı bir widget'a çıkar
class KartWidget extends StatelessWidget {
  final String metin;
  const KartWidget({super.key, required this.metin});

  @override
  Widget build(BuildContext context) {
    return Container(
      padding: EdgeInsets.all(16),
      decoration: BoxDecoration(border: Border.all(color: Colors.grey)),
      child: Text(metin),
    );
  }
}

// Kullanımı:
Column(
  children: [
    KartWidget(metin: 'Kart 1'),
    KartWidget(metin: 'Kart 2'),
  ],
)

Bu, Dart Bölüm 5'te öğrendiğimiz "kod tekrarını fonksiyonlarla önleme" prensibinin, Flutter'daki widget'lara uygulanmış hali — KartWidget, aslında bir Dart class'ı olduğu için, bu tam olarak Dart Bölüm 6'da öğrendiğimiz "yeniden kullanılabilir yapı taşları" felsefesidir.

#Widget Parçalama — "Görsel Karmaşıklığı Yönetme"

// ❌ Her şey tek bir DEVASA build() metodunda
class AnaEkran extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Ana Sayfa')),
      body: Column(
        children: [
          // 50 satır profil kartı kodu...
          // 40 satır istatistik grafiği kodu...
          // 60 satır liste kodu...
        ],
      ),
    );
  }
}

// ✅ Küçük widget'lara bölünmüş
class AnaEkran extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Ana Sayfa')),
      body: Column(
        children: [
          ProfilKarti(),
          IstatistikGrafigi(),
          UrunListesi(),
        ],
      ),
    );
  }
}

Bu ayrım, sadece kod tekrarını önlemekle kalmaz — Bölüm 2 Konu 6'da öğrendiğimiz setState()/rebuild mekanizmasıyla da doğrudan ilişkilidir: eğer ProfilKarti içinde bir setState() çağrılırsa, sadece ProfilKarti'nin kendi build()'i tekrar çalışır — IstatistikGrafigi ve UrunListesi etkilenmez. Eğer her şey tek bir dev widget içinde olsaydı, herhangi bir küçük değişiklik, tüm ekranın yeniden oluşturulmasını (rebuild) tetiklerdi — bu, Dart Bölüm 13'te öğrendiğimiz performans bilinçli tasarım felsefesine aykırı olurdu.

#Fonksiyon mu, Widget Class'ı mı? — Yaygın Bir Tuzak

// ❌ ÖNERİLMEZ — bir metod widget "gibi" görünse de, gerçek bir widget DEĞİLDİR
Widget kartOlustur(String metin) {
  return Container(
    padding: EdgeInsets.all(16),
    child: Text(metin),
  );
}

// ✅ DOĞRUSU — gerçek bir widget class'ı
class KartWidget extends StatelessWidget {
  final String metin;
  const KartWidget({super.key, required this.metin});

  @override
  Widget build(BuildContext context) {
    return Container(
      padding: EdgeInsets.all(16),
      child: Text(metin),
    );
  }
}

Bu ayrım, başlangıçta görsel olarak çok benzer sonuçlar üretir, ama Bölüm 1 Konu 1'de öğrendiğimiz Element ağacı açısından kritik bir fark vardır: bir fonksiyon (kartOlustur), her çağrıldığında sadece bir Dart fonksiyon çağrısıdır — Flutter'ın Element ağacında kendi kimliğine sahip bir "node" oluşturmaz. Gerçek bir widget class'ı (KartWidget) ise, Element ağacında kendi kimliğine sahip bir varlıktır — bu, Flutter'ın daha akıllı rebuild optimizasyonları yapabilmesini sağlar (Bölüm 9'da performans konusunda bunu tam olarak işleyeceğiz). Ayrıca, gerçek bir widget class'ı, Flutter DevTools'ta (Bölüm 1 Konu 2'yi hatırla) kendi widget'ı olarak görünür ve incelenebilir — bir fonksiyon bu görünürlüğü sağlamaz.

Pratik kural: Widget döndüren yeniden kullanılabilir bir parça yazacaksan, her zaman bir class (StatelessWidget/StatefulWidget) kullan, fonksiyon değil.

#Parametrelerle Esnek Widget'lar

class Rozet extends StatelessWidget {
  final String metin;
  final Color renk;
  final VoidCallback? onTap; // Dart Bölüm 5'te öğrendiğimiz fonksiyon TİPİ!

  const Rozet({
    super.key,
    required this.metin,
    this.renk = Colors.blue, // Dart Bölüm 5'te öğrendiğimiz varsayılan değer
    this.onTap,
  });

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: onTap,
      child: Container(
        padding: EdgeInsets.symmetric(horizontal: 12, vertical: 6),
        decoration: BoxDecoration(
          color: renk,
          borderRadius: BorderRadius.circular(16),
        ),
        child: Text(metin, style: TextStyle(color: Colors.white)),
      ),
    );
  }
}

VoidCallback? — Bu, Dart Bölüm 5 Konu 24'te öğrendiğimiz fonksiyon tipini doğrudan kullanıyor: VoidCallback, aslında Flutter'ın (Dart'ın) tanımladığı bir typedef'tir — void Function() için bir kısayoldur. ? ile nullable yapılmış (Dart Bölüm 2'yi hatırla) — yani onTap verilmeyebilir, bu durumda tıklama hiçbir şey yapmaz.

Bu widget, artık her yerde farklı renk/metin/davranışla yeniden kullanılabilir:

Rozet(metin: 'Yeni', renk: Colors.green, onTap: () => print('Tıklandı'))
Rozet(metin: 'İndirimli') // renk varsayılan mavi, onTap yok

#🎯 Bu Dersten Çıkarılması Gerekenler

• Flutter, "composition over inheritance" prensibini benimser — var olan widget'lardan extends etmek yerine, onları build() içinde kullanarak yeni widget'lar oluşturursun.
• Tekrarlanan widget ağacı parçalarını, ayrı bir widget class'ına çıkarmak, hem kod tekrarını önler hem de rebuild verimliliğini artırır.
• Widget döndüren yardımcı bir parça yazarken, fonksiyon değil, gerçek bir widget class'ı kullanmalısın — Element ağacı kimliği ve rebuild optimizasyonu açısından fark yaratır.
• Parametreli, esnek widget'lar (varsayılan değerler, nullable callback'ler ile), Dart Bölüm 5'te öğrendiğin fonksiyon parametreleri bilgisini doğrudan kullanır.

#📝 Ödevler

• [ ] Kod tekrarı içeren bir widget ağacını (aynı yapıyı iki kere yazarak), sonra bunu ayrı bir widget class'ına çıkararak iki versiyonunu yaz.
• [ ] Bir widget döndüren fonksiyon yaz, sonra bunu gerçek bir StatelessWidget class'ına dönüştür — aradaki farkı kendi cümlelerinle açıkla.
• [ ] En az 3 parametreli (biri varsayılan değerli, biri nullable callback) kendi custom widget'ını yaz, farklı konfigürasyonlarla en az 2 kere kullan.
• [ ] Bir ekranı, "tek dev widget" yerine en az 3 ayrı widget class'ına bölerek yeniden düzenle.
• [ ] Kendi cümlelerinle, "Flutter'da neden var olan widget'lardan extends etmek yaygın değil, ama kendi StatelessWidget'larımızı yazmak yaygın" sorusunu açıkla.

#🎮 Mini Uygulama — Yeniden Kullanılabilir Bileşen Kütüphanesi

Bölüm 3'te öğrendiklerini birleştiren bir mini proje: kendi küçük widget kütüphaneni oluştur.

Gereksinimler:

• En az 3 farklı, yeniden kullanılabilir custom widget yaz (örneğin: Rozet, IstatistikKutusu, KullaniciSatiri).
• Her widget, en az 2 parametre alsın (biri varsayılan değerli veya nullable olsun).
• Bu widget'ları, ListView.builder (Bölüm 3 Konu 11'i hatırla) ile oluşturulan bir listede, farklı verilerle en az 5 kere kullan.
• Tüm ekran, Scaffold + AppBar ile sarmalanmış olsun (Bölüm 3 Konu 10'u hatırla).

Bu proje, artık senin kendi widget'larını tasarlama becerini gerçek bir bağlamda test ediyor — Bölüm 2 ve Bölüm 3'ün tamamını (layout, ekran iskeleti, listeler, custom widget'lar) bir araya getiriyor.

Sıradaki konu: Bölüm 3 — Konu 14: Navigator 1.0 — Push/Pop, Named Routes

Bölüm 3'ün son konusundayız. Şimdiye kadar tek ekranlı uygulamalar yazdık — bu derste, ekranlar arası geçişi öğreneceğiz.

#Navigator — Bir Yığın (Stack) Olarak Ekranlar

Flutter'da ekranlar arası gezinme, Dart Bölüm 9'da (aslında Bölüm 13'te FFI ile ilişkili olarak Pointer'ı, ama asıl burada ilişkili olan) öğrendiğimiz bir veri yapısına dayanır: yığın (stack). Bunu daha net Dart Bölüm 9 Konu 43'te Kutu<T extends Comparable> gibi generic örneklerde görmüştük ama "stack" kavramının kendisini işlememiştik — kısaca: stack, "son giren ilk çıkar" (LIFO — Last In First Out) mantığıyla çalışan bir veri yapısıdır.

Navigator, tam olarak bunu kullanır: her yeni ekrana geçtiğinde, o ekran yığının üstüne "itilir" (push); geri döndüğünde, en üstteki ekran yığından "çıkarılır" (pop).

Yığın (üstten alta):
  [Detay Ekranı]   <- şu an görünen (en üstte)
  [Ana Ekran]

#Navigator.push() — Yeni Bir Ekrana Geçme

ElevatedButton(
  onPressed: () {
    Navigator.push(
      context,
      MaterialPageRoute(builder: (context) => DetayEkrani()),
    );
  },
  child: Text('Detaya Git'),
)

Parça parça inceleyelim:

• context — Bölüm 2 Konu 5'te gördüğümüz BuildContext, burada Navigator'a "bu widget'ın ağaçtaki neresinde olduğunu ve hangi Navigator'a ait olduğunu" söylüyor.
• MaterialPageRoute — yeni ekranın nasıl gösterileceğini tanımlar (Material Design'a uygun geçiş animasyonuyla).
• builder: (context) => DetayEkrani() — Bölüm 3 Konu 11'de öğrendiğimiz builder pattern'in bir başka örneği! Bir anonim fonksiyon (Dart Bölüm 5), yeni ekranın widget'ını oluşturuyor.

#Navigator.pop() — Bir Önceki Ekrana Dönme

ElevatedButton(
  onPressed: () {
    Navigator.pop(context);
  },
  child: Text('Geri Dön'),
)

pop(), yığından en üstteki ekranı çıkarır — kullanıcı, bir önceki ekrana geri döner. Not: AppBar, varsayılan olarak bir "geri" oku otomatik olarak gösterir (eğer Navigator yığınında birden fazla ekran varsa) — bu ok, arka planda zaten Navigator.pop(context) çağırır, sen elle eklemene gerek kalmaz.

#Ekranlar Arası Veri Gönderme

1. Giden ekrana veri gönderme (constructor parametreleri ile):

class DetayEkrani extends StatelessWidget {
  final String urunAdi;
  const DetayEkrani({super.key, required this.urunAdi});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text(urunAdi)),
      body: Center(child: Text('$urunAdi detayları')),
    );
  }
}

Navigator.push(
  context,
  MaterialPageRoute(builder: (context) => DetayEkrani(urunAdi: 'Kalem')),
);

Bu, Dart Bölüm 6'da öğrendiğimiz constructor parametreleri kavramının doğrudan bir uygulaması — yeni ekranı oluştururken, tıpkı herhangi bir class'ı oluştururken parametre verir gibi veri geçiriyorsun.

2. Geri dönerken veri alma:

// Detay ekranında, geri dönerken bir değer gönderiyoruz
Navigator.pop(context, 'Seçilen Ürün: Kalem');

// Ana ekranda, push()'un SONUCUNU bekliyoruz
void _detayaGit() async {
  final sonuc = await Navigator.push(
    context,
    MaterialPageRoute(builder: (context) => DetayEkrani(urunAdi: 'Kalem')),
  );
  print('Geri dönen değer: $sonuc');
}

Bu, Dart Bölüm 10'da öğrendiğimiz Future/async/await'in doğrudan bir uygulaması! Navigator.push(), aslında bir Future döndürür — bu future, kullanıcı geri dönene kadar tamamlanmaz (Dart Bölüm 10 Konu 45'te öğrendiğimiz "gelecekte bir değer" kavramını hatırla). Kullanıcı Navigator.pop(context, deger) çağırdığında, bu Future o değerle tamamlanır ve await satırı devam eder. Bu, Dart'ı derinlemesine öğrenmenin Flutter'da doğrudan işine yaradığı somut bir andır.

#Named Routes — Yol Tabanlı Navigasyon

Yukarıdaki yaklaşım (MaterialPageRoute ile doğrudan widget oluşturma), "anonymous routes" olarak bilinir. Alternatif olarak, her ekrana bir isim vererek, MaterialApp düzeyinde merkezi bir "yol haritası" tanımlayabilirsin:

MaterialApp(
  initialRoute: '/',
  routes: {
    '/': (context) => AnaEkran(),
    '/detay': (context) => DetayEkrani(),
    '/ayarlar': (context) => AyarlarEkrani(),
  },
)

Bu, Dart Bölüm 4'te öğrendiğimiz Map<String, WidgetBuilder> yapısıdır — anahtar, yol adı ('/detay'); değer, o yolu oluşturan bir builder fonksiyonu.

Named route'a geçiş:

Navigator.pushNamed(context, '/detay');

Named route ile veri gönderme (arguments ile):

Navigator.pushNamed(context, '/detay', arguments: 'Kalem');

class DetayEkrani extends StatelessWidget {
  const DetayEkrani({super.key});

  @override
  Widget build(BuildContext context) {
    final urunAdi = ModalRoute.of(context)!.settings.arguments as String;
    return Scaffold(
      appBar: AppBar(title: Text(urunAdi)),
      body: Center(child: Text('$urunAdi detayları')),
    );
  }
}

Dikkat et: arguments, Object? tipinde gelir — bu yüzden as String ile cast etmen gerekiyor (Dart Bölüm 2 Konu 8'de öğrendiğimiz Object ile açık tip dönüşümü kavramını hatırla). Bu, named routes'un doğrudan constructor parametresi yaklaşımına göre daha az tip güvenli olduğu bir noktadır — bu yüzden, Bölüm 3 Konu 14'te (Flutter müfredatının ileri kısmında, Bölüm 7'de) öğreneceğimiz go_router gibi paketler, bu tip güvenliği sorununu çözen daha modern bir yaklaşım sunar.

#Anonymous vs Named Routes — Ne Zaman Hangisi?

Pratik tavsiye: Küçük/orta projelerde, anonymous routes (tip güvenliği için) genelde tercih edilir. Named routes, uygulaman büyüdükçe ve URL benzeri bir yapıya (özellikle web için) ihtiyaç duyduğunda daha değerli hale gelir. Bölüm 7'de (Flutter müfredatı), go_router ile bu iki yaklaşımın en iyi yönlerini birleştiren modern bir çözümü göreceğiz.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Navigator, ekranları bir stack (yığın) olarak yönetir — push ile üste eklenir, pop ile çıkarılır.
• Navigator.push(), bir Future döndürür — Navigator.pop(context, deger) ile bu future'ı bir değerle tamamlayabilirsin (Dart'taki Future/await bilginin doğrudan uygulaması).
• Ekranlara veri, constructor parametreleriyle (anonymous routes, tip güvenli) veya arguments ile (named routes, cast gerektirir) gönderilebilir.
• MaterialApp'in routes: haritası, Map<String, WidgetBuilder> kullanır — merkezi bir "yol haritası" tanımlamanı sağlar.

#📝 Ödevler

• [ ] İki ekranlı bir uygulama yap: ana ekrandan "Detay" ekranına Navigator.push ile geç.
• [ ] Detay ekranına, constructor parametresiyle bir veri (örn. bir isim) gönder, ekranda göster.
• [ ] Detay ekranında geri dönerken, Navigator.pop(context, deger) ile bir veri döndür, ana ekranda await ile bu veriyi al ve yazdır.
• [ ] Aynı iki ekranlı yapıyı, routes: haritası ve Navigator.pushNamed kullanarak yeniden yaz.
• [ ] Named route ile bir arguments gönder, ModalRoute.of(context)!.settings.arguments ile al ve as ile cast et.

#🏁 Bölüm 3 Tamamlandı!

Gerçek bir uygulama iskeleti kurmayı (MaterialApp/Scaffold/AppBar), listeleri (ListView.builder), kendi custom widget'larını tasarlamayı ve ekranlar arası navigasyonu öğrendin. Artık çok ekranlı, gezinebilir bir uygulama yazabiliyorsun.

Sıradaki durak Bölüm 4 — Kullanıcı Girdisi & Tema: form alanları, validasyon, tema sistemi ve responsive tasarım ile devam edeceğiz.

Bölüm 4'e hoş geldin. Bu derste, kullanıcıdan veri almayı (form doldurma) öğreneceğiz — bu, Bölüm 2'de öğrendiğimiz StatefulWidget/setState() bilgisinin gerçek bir kullanım alanı.

#TextField — En Temel Metin Girişi

TextField(
  decoration: InputDecoration(
    labelText: 'İsim',
    border: OutlineInputBorder(),
  ),
)

TextField, kullanıcının serbest metin girebildiği bir widget'tır. Ama dikkat et — bu widget, girdiğin metni kendi başına saklamaz, sadece gösterir. Girilen metne erişmek için bir controller gerekir.

#TextEditingController — Girdiye Programatik Erişim

class GirisFormu extends StatefulWidget {
  const GirisFormu({super.key});

  @override
  State<GirisFormu> createState() => _GirisFormuState();
}

class _GirisFormuState extends State<GirisFormu> {
  final TextEditingController _isimController = TextEditingController();

  @override
  void dispose() {
    _isimController.dispose(); // Bölüm 4 Konu 17'de dispose'u tam işleyeceğiz
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        TextField(controller: _isimController),
        ElevatedButton(
          onPressed: () {
            print('Girilen isim: ${_isimController.text}');
          },
          child: Text('Yazdır'),
        ),
      ],
    );
  }
}

_isimController.text, Dart Bölüm 2'de öğrendiğimiz String tipinde, kullanıcının o an girdiği metni verir. TextEditingController, Dart Bölüm 11 Konu 52'de öğrendiğimiz cascade notasyonuna benzer bir kalıpla da kullanılabilir (TextEditingController()..text = 'Başlangıç değeri').

dispose() neden çağrılıyor? Bölüm 4 Konu 17'de bunu tam işleyeceğiz, ama şimdiden bilmen faydalı: TextEditingController, Dart Bölüm 13 Konu 62'de öğrendiğimiz garbage collection'ın otomatik olarak temizleyemediği bazı kaynakları (native platform kaynakları) tutar — bu yüzden elle serbest bırakılması gerekir, tıpkı Dart Bölüm 13 Konu 64'te (FFI) öğrendiğimiz "elle bellek yönetimi" istisnasına benzer bir durum.

#Form ve TextFormField — Yapılandırılmış Form Yönetimi

Tek tek TextField'ları yönetmek yerine, Flutter, birden fazla alanı gruplandırıp birlikte doğrulamanı sağlayan Form widget'ını sunar:

class KayitFormu extends StatefulWidget {
  const KayitFormu({super.key});

  @override
  State<KayitFormu> createState() => _KayitFormuState();
}

class _KayitFormuState extends State<KayitFormu> {
  final _formKey = GlobalKey<FormState>();

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        children: [
          TextFormField(
            decoration: InputDecoration(labelText: 'E-posta'),
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'E-posta boş olamaz';
              }
              if (!value.contains('@')) {
                return 'Geçerli bir e-posta girin';
              }
              return null; // null = geçerli, hata yok
            },
          ),
          ElevatedButton(
            onPressed: () {
              if (_formKey.currentState!.validate()) {
                print('Form geçerli!');
              }
            },
            child: Text('Gönder'),
          ),
        ],
      ),
    );
  }
}

#GlobalKey<FormState> — Ne İşe Yarıyor?

Bu, ilk bakışta kafa karıştırıcı görünebilir — parça parça açalım.

GlobalKey, bir widget'a "dışarıdan, doğrudan erişim" sağlayan özel bir anahtardır. Normalde, Flutter'da bir widget'ın State'ine (Bölüm 2 Konu 6'da öğrendiğimiz State sınıfını hatırla), sadece o widget'ın kendisi (kendi setState()'i aracılığıyla) erişebilir. GlobalKey, bu kuralın bilinçli bir istisnasıdır — widget ağacının dışından, o widget'ın State'ine doğrudan referans almanı sağlar.

final _formKey = GlobalKey<FormState>(); // GENERİC! Dart Bölüm 9'u hatırla

GlobalKey<FormState> — Dart Bölüm 9'da öğrendiğimiz generic sınıflar burada karşımıza çıkıyor! GlobalKey<T>, "T tipinde bir State'e erişim sağlayan anahtar" demek — burada T, FormState (Form widget'ının kendi State sınıfı).

Form(
  key: _formKey, // bu anahtarı Form widget'ına "veriyoruz"
  child: ...,
)

_formKey.currentState!.validate()

currentState, _formKey'in bağlı olduğu widget'ın o anki State nesnesini döndürür — bu, FormState? tipindedir (nullable, çünkü widget henüz oluşturulmamış olabilir). ! (Dart Bölüm 2'de öğrendiğimiz null assertion operatörü) ile "bu kesinlikle null değil" diyoruz — çünkü Form widget'ı zaten build() içinde oluşturulduğu için, bu noktada State'in var olduğundan eminiz.

.validate(), Form içindeki tüm TextFormField'ların validator fonksiyonlarını sırayla çalıştırır ve hepsi null döndürürse (yani hata yoksa) true döner.

#validator Fonksiyonu — Dart Bilginle Çözümleme

validator: (value) {
  if (value == null || value.isEmpty) {
    return 'E-posta boş olamaz';
  }
  return null;
}

Bu, Dart Bölüm 5'te öğrendiğimiz anonim fonksiyondur — String? parametre alır (kullanıcının girdiği metin, henüz hiçbir şey girilmemişse null olabilir), String? döndürür:

• null döndürürse → "hata yok, geçerli."
• Bir String döndürürse → bu string, hata mesajı olarak kullanıcıya gösterilir.

Bu, Dart Bölüm 2'de öğrendiğimiz null safety'nin, "var/yok" (hata var/yok) durumunu ifade etmek için yaratıcı bir kullanımı.

#Birden Fazla Alan ile Tam Bir Form

class KayitFormu extends StatefulWidget {
  const KayitFormu({super.key});

  @override
  State<KayitFormu> createState() => _KayitFormuState();
}

class _KayitFormuState extends State<KayitFormu> {
  final _formKey = GlobalKey<FormState>();
  final _emailController = TextEditingController();
  final _sifreController = TextEditingController();

  @override
  void dispose() {
    _emailController.dispose();
    _sifreController.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        children: [
          TextFormField(
            controller: _emailController,
            decoration: InputDecoration(labelText: 'E-posta'),
            validator: (value) {
              if (value == null || !value.contains('@')) {
                return 'Geçerli bir e-posta girin';
              }
              return null;
            },
          ),
          TextFormField(
            controller: _sifreController,
            obscureText: true, // şifre gizleme
            decoration: InputDecoration(labelText: 'Şifre'),
            validator: (value) {
              if (value == null || value.length < 6) {
                return 'Şifre en az 6 karakter olmalı';
              }
              return null;
            },
          ),
          ElevatedButton(
            onPressed: () {
              if (_formKey.currentState!.validate()) {
                print('E-posta: ${_emailController.text}');
                print('Şifre: ${_sifreController.text}');
              }
            },
            child: Text('Kayıt Ol'),
          ),
        ],
      ),
    );
  }
}

#🎯 Bu Dersten Çıkarılması Gerekenler

• TextField, serbest metin girişi sağlar ama girdiyi kendi başına saklamaz; TextEditingController, girdiye programatik erişim sağlar.
• Form + TextFormField, birden fazla alanı gruplandırıp birlikte doğrulamayı (validate) sağlar.
• GlobalKey<FormState>, widget ağacının dışından bir widget'ın State'ine doğrudan erişim sağlayan özel bir anahtardır (Dart'taki generics'in gerçek bir kullanımı).
• validator fonksiyonu, null (geçerli) veya bir String (hata mesajı) döndürür — Dart'ın null safety'sinin yaratıcı bir kullanımı.
• Controller'lar, Dart'ın garbage collector'ının otomatik temizleyemediği kaynaklar tuttuğu için dispose() ile elle serbest bırakılmalıdır.

#📝 Ödevler

• [ ] TextEditingController ile bir TextField'ın girdisini bir butona basınca print ile yazdır.
• [ ] E-posta ve şifre alanlı, Form + GlobalKey<FormState> kullanan bir giriş formu yaz, her iki alan için de validator ekle.
• [ ] Boş bir alan veya geçersiz bir e-posta ile "Gönder"e basmayı dene, hata mesajlarının nasıl göründüğünü gözlemle.
• [ ] obscureText: true kullanarak bir şifre alanı oluştur, görsel farkı gözlemle.
• [ ] Form geçerli olduğunda, tüm controller'lardaki değerleri print ile ekrana yazdıran bir "kayıt ol" akışı tamamla.

Sıradaki konu: Bölüm 4 — Konu 16: Theme Sistemi (ThemeData, ColorScheme)

#Neden Tema Sistemi Var?

Şimdiye kadar, her widget'a renk/font/stil tek tek verdik (TextStyle(color: Colors.blue) gibi). Bu, küçük örnekler için sorun değil, ama gerçek bir uygulamada tutarlılığı korumak çok zorlaşır — 50 farklı ekranda "ana renk"i değiştirmek istediğinde, hepsini tek tek bulup değiştirmen gerekir. Tema sistemi, bunu merkezi bir yerden yönetmeni sağlar.

#ThemeData — Uygulama Genelinde Stil Tanımlama

Bölüm 3 Konu 10'da MaterialApp'in theme: parametresini kısaca görmüştük — şimdi derinlemesine işleyelim:

MaterialApp(
  theme: ThemeData(
    primaryColor: Colors.indigo,
    scaffoldBackgroundColor: Colors.grey[100],
    textTheme: TextTheme(
      headlineMedium: TextStyle(fontSize: 24, fontWeight: FontWeight.bold),
      bodyMedium: TextStyle(fontSize: 16),
    ),
    elevatedButtonTheme: ElevatedButtonThemeData(
      style: ElevatedButton.styleFrom(
        backgroundColor: Colors.indigo,
        foregroundColor: Colors.white,
      ),
    ),
  ),
  home: AnaEkran(),
)

ThemeData, Dart Bölüm 6'da öğrendiğimiz class'lar ve named parametreler kullanılarak tasarlanmış, devasa bir yapılandırma nesnesidir — düzinelerce widget türü için (butonlar, metin alanları, kartlar, vb.) varsayılan stiller tanımlamanı sağlar.

#Theme.of(context) — Temaya Erişim

Bölüm 1 Konu 4'te (hot reload deneyinde) Theme.of(context).textTheme.headlineMedium kullanmıştık — şimdi bunun nasıl çalıştığını anlayalım:

Text(
  'Başlık',
  style: Theme.of(context).textTheme.headlineMedium,
)

Theme.of(context) ne yapıyor? Bu, Bölüm 2 Konu 5'te "context'i şimdilik bir bilgi taşıyıcı olarak düşün" dediğimiz noktanın gerçek gücünü gösteriyor. BuildContext, widget'ın ağaçtaki konumunu bildiği için, Theme.of(context), "bu widget'ın en yakın üst ebeveyninde tanımlı olan ThemeData'yı bul" işlemini yapar. Bu, Dart Bölüm 7'de öğrendiğimiz kalıtım zincirini andıran, ama widget ağacı üzerinde çalışan bir mekanizma — "en yakın atadaki ayarı devral" mantığı.

Neden bu şekilde tasarlandı, neden global bir değişken kullanılmadı? Bölüm 8'de (Flutter müfredatı, InheritedWidget konusunda) bunun tam mekanizmasını göreceğiz — ama şimdiden bil ki, Theme.of(context)'in kendisi de bir InheritedWidget kullanır. Bu, "widget ağacı boyunca veri paylaşmanın" Flutter'daki temel yöntemidir.

#ColorScheme — Modern Renk Yönetimi

Material Design 3 ile birlikte, tek tek renkler (primaryColor gibi) yerine, bütünsel bir renk sistemi olan ColorScheme öne çıktı:

ThemeData(
  colorScheme: ColorScheme.fromSeed(
    seedColor: Colors.deepPurple,
  ),
)

ColorScheme.fromSeed() — bu, tek bir "tohum" (seed) renkten, Material Design'ın renk teorisi kurallarına göre, uyumlu bir renk paleti (birincil, ikincil, arka plan, hata rengi gibi düzinelerce renk) otomatik olarak üretir. Bu, elle her rengi tek tek tanımlamak yerine, tek bir karar (ana renk) ile tutarlı bir tasarım sistemi elde etmeni sağlar.

Container(
  color: Theme.of(context).colorScheme.primary,
  child: Text(
    'Merhaba',
    style: TextStyle(color: Theme.of(context).colorScheme.onPrimary),
  ),
)

primary ve onPrimary ayrımı önemli: primary, ana rengi; onPrimary, o rengin üzerine yazılacak metnin rengini belirtir (genelde kontrast için beyaz/siyah). Bu isimlendirme kalıbı (on öneki), ColorScheme'in her rengi için geçerlidir (secondary/onSecondary, error/onError gibi) — Dart Bölüm 1'de öğrendiğimiz tutarlı isimlendirme prensibinin, Flutter'ın kendi API tasarımında uygulanmış hali.

#Karanlık Mod (Dark Mode) Desteği

MaterialApp(
  theme: ThemeData(
    colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue, brightness: Brightness.light),
  ),
  darkTheme: ThemeData(
    colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue, brightness: Brightness.dark),
  ),
  themeMode: ThemeMode.system, // sistem ayarına göre otomatik seç
  home: AnaEkran(),
)

themeMode: ThemeMode.system, Dart Bölüm 7'de öğrendiğimiz enum'a benzer bir yapı kullanır (ThemeMode, system/light/dark değerlerine sahip bir enum) — cihazın sistem ayarına (kullanıcının telefonunda karanlık mod açık mı) göre, Flutter otomatik olarak theme veya darkTheme'i seçer.

#Elle Tema Değiştirme — StatefulWidget ile

class MyApp extends StatefulWidget {
  const MyApp({super.key});

  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  ThemeMode _temaModu = ThemeMode.system;

  void _temaDegistir(bool karanlikMi) {
    setState(() {
      _temaModu = karanlikMi ? ThemeMode.dark : ThemeMode.light;
    });
  }

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue)),
      darkTheme: ThemeData(colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue, brightness: Brightness.dark)),
      themeMode: _temaModu,
      home: AnaEkran(onTemaDegistir: _temaDegistir),
    );
  }
}

Bu, Bölüm 2 Konu 6'da öğrendiğimiz setState() mekanizmasını, tema bağlamında kullanıyor — _temaModu değiştiğinde, setState() tetikleniyor ve MaterialApp (ve altındaki tüm widget ağacı) yeni temaya göre yeniden çiziliyor.

#Widget Seviyesinde Tema Geçersiz Kılma (Override)

Theme(
  data: Theme.of(context).copyWith(
    colorScheme: Theme.of(context).colorScheme.copyWith(primary: Colors.red),
  ),
  child: ElevatedButton(
    onPressed: () {},
    child: Text('Özel Renkli Buton'),
  ),
)

Bölüm 3 Konu 12'de öğrendiğimiz copyWith() kalıbı burada tekrar karşımıza çıkıyor — var olan temayı temel alıp, sadece belirli bir kısmını değiştirerek, sadece bir widget alt ağacı için geçerli olan yerel bir tema oluşturabilirsin.

#🎯 Bu Dersten Çıkarılması Gerekenler

• ThemeData, uygulamanın genelinde tutarlı stil (renk, font, buton görünümü) tanımlamanı sağlayan merkezi bir yapılandırma nesnesidir.
• Theme.of(context), widget ağacında "en yakın" tanımlı temayı bulur — bu, InheritedWidget mekanizmasına dayanır (Bölüm 8'de tam işleyeceğiz).
• ColorScheme.fromSeed(), tek bir ana renkten, Material Design kurallarına uygun bütünsel bir renk paleti üretir; primary/onPrimary gibi çiftler, renk ve o rengin üzerine yazı rengini eşleştirir.
• darkTheme + themeMode, karanlık mod desteğini sağlar; ThemeMode.system, cihaz ayarına göre otomatik seçim yapar.
• Theme widget'ı ile, bir widget alt ağacı için yerel olarak temayı geçersiz kılabilirsin.

#📝 Ödevler

• [ ] ThemeData ile uygulamana özel bir ana renk, buton stili ve metin teması tanımla, tüm uygulamada tutarlı şekilde kullan.
• [ ] ColorScheme.fromSeed() ile tek bir renkten tam bir renk paleti oluştur, primary/onPrimary ile bir widget stilini uygula.
• [ ] Karanlık mod / aydınlık mod arasında geçiş yapabilen bir switch ekle (themeMode ile).
• [ ] Theme widget'ı ve copyWith() kullanarak, sadece belirli bir widget için yerel bir tema geçersiz kılması yap.
• [ ] Kendi cümlelerinle, "Theme.of(context) nasıl doğru temayı buluyor" sorusunu, widget ağacı ve context kavramlarıyla ilişkilendirerek açıkla (tahmin edebildiğin kadarıyla — Bölüm 8'de tam mekanizmayı göreceğiz).

Sıradaki konu: Bölüm 4 — Konu 17: Responsive & Adaptive Tasarım (MediaQuery, LayoutBuilder, OrientationBuilder, Breakpoint Stratejileri)

Bölüm 4'ün son konusundayız. Flutter uygulamaları, telefon, tablet, masaüstü, web gibi çok farklı ekran boyutlarında çalışabilir — bu derste, arayüzünü bu farklılıklara uyarlamayı öğreneceğiz.

#MediaQuery — Cihaz/Ekran Hakkında Bilgi Alma

Widget build(BuildContext context) {
  final ekranBoyutu = MediaQuery.of(context).size;
  final genislik = ekranBoyutu.width;
  final yukseklik = ekranBoyutu.height;

  return Text('Ekran: ${genislik.toInt()} x ${yukseklik.toInt()}');
}

MediaQuery.of(context), Bölüm 4 Konu 16'da öğrendiğimiz Theme.of(context) ile aynı mekanizmayı kullanır — widget ağacında en yakın MediaQueryData'yı bulur (bu da bir InheritedWidget'a dayanır, Bölüm 8'de tam göreceğiz). MediaQuery, ekran boyutu dışında da birçok bilgi sağlar:

MediaQuery.of(context).size.width          // ekran genişliği
MediaQuery.of(context).orientation         // yatay/dikey (Orientation.portrait/landscape)
MediaQuery.of(context).padding.top         // üstteki "çentik"/durum çubuğu boşluğu
MediaQuery.textScalerOf(context)           // kullanıcının sistem yazı boyutu ayarı

Not: Eskiden (Flutter 3.12 öncesi) bu son satır için MediaQuery.of(context).textScaleFactor (bir double) kullanılırdı. Bu artık deprecated — çünkü tek bir çarpanla ölçeklendirme, erişilebilirlik açısından her yazı boyutu için doğru sonuç vermiyordu. Güncel API TextScaler nesnesi döndürür ve bir font boyutunu ölçeklendirmek için MediaQuery.textScalerOf(context).scale(16) gibi kullanılır (16, ölçeklenecek orijinal font boyutu).

#Basit Bir Breakpoint Stratejisi

Breakpoint, "bu genişlikten sonra düzeni değiştir" kararının alındığı eşik değerdir. Web geliştirmede yaygın olan bu kavram, Flutter'da da uygulanabilir:

class ResponsiveEkran extends StatelessWidget {
  const ResponsiveEkran({super.key});

  @override
  Widget build(BuildContext context) {
    final genislik = MediaQuery.of(context).size.width;

    if (genislik < 600) {
      return TekSutunGorunum(); // telefon
    } else if (genislik < 1024) {
      return IkiSutunGorunum(); // tablet
    } else {
      return UcSutunGorunum(); // masaüstü/geniş ekran
    }
  }
}

Bu, Dart Bölüm 3'te öğrendiğimiz if/else if yapısının (ya da bir switch expression'ın — Dart Bölüm 3 Konu 12'yi hatırla) doğrudan bir uygulaması — ekran genişliğine göre farklı widget ağaçları döndürüyoruz.

#LayoutBuilder — Ebeveynin Boyutuna Göre Karar Verme

MediaQuery, tüm ekranın boyutunu verir. Ama bazen, sadece belirli bir widget'ın kendisine ayrılan alanın boyutuna göre karar vermen gerekir (örneğin bir widget, ekranın yarısını kaplıyorsa, "ekran genişliği" değil, "kendisine ayrılan alan" önemlidir):

LayoutBuilder(
  builder: (BuildContext context, BoxConstraints constraints) {
    if (constraints.maxWidth < 300) {
      return Icon(Icons.star); // dar alan — sadece ikon
    } else {
      return Row(
        children: [Icon(Icons.star), Text('Favorilerim')],
      );
    }
  },
)

BoxConstraints constraints — Bölüm 2 Konu 8'de öğrendiğimiz constraint sistemini hatırlıyor musun? "Constraints go down" demiştik — işte LayoutBuilder, bu kısıtlamayı doğrudan sana verir! constraints.maxWidth, "bu widget'a ebeveyninden gelen maksimum genişlik kısıtlaması nedir" sorusunun cevabıdır. Bu, Bölüm 3 Konu 11'de öğrendiğimiz builder pattern'in (context ve bir parametre alan anonim fonksiyon) bir başka uygulaması — burada index yerine constraints alıyoruz.

MediaQuery ile LayoutBuilder arasındaki fark:

#OrientationBuilder — Yön Değişikliklerine Tepki Verme

OrientationBuilder(
  builder: (context, orientation) {
    return GridView.count(
      crossAxisCount: orientation == Orientation.portrait ? 2 : 4,
      children: List.generate(8, (i) => Container(color: Colors.blue[100 * (i % 8 + 1)])),
    );
  },
)

OrientationBuilder, cihaz dikey (portrait) mi yatay (landscape) mi tutulduğuna göre farklı bir yapı kurmanı sağlar — burada, dikey modda 2 sütun, yatay modda 4 sütunlu bir GridView (Bölüm 3 Konu 11'i hatırla) oluşturuyoruz.

#Responsive vs Adaptive — Terminoloji Farkı

Bu iki terim sık karıştırılır:

• Responsive (duyarlı) tasarım: Aynı widget ağacı, akıcı (fluid) bir şekilde farklı boyutlara uyum sağlar (Expanded/Flexible ile oranlar otomatik ayarlanır — Bölüm 2 Konu 9'u hatırla).
• Adaptive (uyarlanabilir) tasarım: Farklı ekran boyutları için tamamen farklı widget ağaçları/düzenler kullanılır (yukarıdaki ResponsiveEkran örneğindeki gibi — telefon için ayrı, tablet için ayrı bir widget).

Gerçek uygulamalarda, genelde ikisi birlikte kullanılır: büyük yapısal kararlar (kaç sütun, hangi navigasyon deseni) adaptive; her boyut içindeki ince ayarlar (Expanded oranları) responsive olur.

#Pratik Bir Örnek — İkisini Birleştirmek

class UrunEkrani extends StatelessWidget {
  const UrunEkrani({super.key});

  @override
  Widget build(BuildContext context) {
    final genislik = MediaQuery.of(context).size.width;
    final genisEkranMi = genislik >= 600; // ADAPTIVE karar

    return Scaffold(
      body: Row(
        children: [
          Expanded(
            flex: genisEkranMi ? 2 : 1, // RESPONSIVE oran
            child: UrunListesi(),
          ),
          if (genisEkranMi) // sadece geniş ekranda göster — ADAPTIVE
            Expanded(
              flex: 3,
              child: UrunDetayPaneli(),
            ),
        ],
      ),
    );
  }
}

Burada, Dart Bölüm 4 Konu 20'de öğrendiğimiz collection if kalıbı (if (genisEkranMi) Expanded(...)) — dar ekranda UrunDetayPaneli hiç oluşturulmuyor (telefon kullanıcısı, muhtemelen bir sonraki ekranda detayı görür), geniş ekranda ise yan yana iki panel gösteriliyor. Bu, tablet/masaüstü uygulamalarında (özellikle "master-detail" — liste + detay yan yana deseni) çok yaygın bir kalıptır.

#MediaQuery Performans Notu — Kısa Bir Önizleme

Bölüm 9'da (performans) derinlemesine işleyeceğiz, ama şimdiden bilmen faydalı: MediaQuery.of(context) çağırdığında, o widget, ekran boyutu her değiştiğinde (örneğin cihaz döndürüldüğünde) otomatik olarak yeniden oluşturulur (rebuild) — çünkü InheritedWidget mekanizması, "bu veriye bağımlı olan her widget'ı, veri değiştiğinde güncelle" prensibiyle çalışır (Bölüm 8'de tam işleyeceğiz). Bu, genelde istediğin davranıştır (ekran boyutu değiştiğinde arayüzün güncellenmesini istersin), ama gereksiz yere geniş kapsamda MediaQuery kullanmak, performans açısından dikkat gerektirebilir.

#🎯 Bu Dersten Çıkarılması Gerekenler

• MediaQuery.of(context), tüm ekranın boyutu, yönü ve diğer cihaz bilgilerine erişim sağlar.
• LayoutBuilder, widget'a ebeveyninden gelen kısıtlamayı (BoxConstraints) doğrudan verir — Bölüm 2'de öğrendiğimiz constraint sisteminin canlı bir uygulaması.
• OrientationBuilder, cihazın dikey/yatay durumuna göre farklı düzen kurmayı sağlar.
• Responsive tasarım (akıcı oranlar) ile adaptive tasarım (tamamen farklı yapılar), genelde birlikte kullanılır.
• Breakpoint stratejisi, genişliğe göre if/else if ile farklı widget ağaçları seçmenin temel yoludur.

#📝 Ödevler

• [ ] MediaQuery ile ekran genişliğini al, 600px altında/üstünde farklı bir mesaj gösteren basit bir widget yaz.
• [ ] LayoutBuilder kullanarak, ekran genişliği 600px altındaysa tek sütun, üstündeyse iki sütun gösteren bir grid yapısı kur.
• [ ] OrientationBuilder ile, dikey/yatay moda göre farklı sayıda sütunlu bir GridView oluştur (bir emulator'de döndürerek test et).
• [ ] Konu 17'deki "UrunEkrani" örneğine benzer, dar ekranda tek panel, geniş ekranda iki panel gösteren (collection if kullanarak) bir master-detail düzeni yap.
• [ ] Kendi cümlelerinle, "responsive" ile "adaptive" tasarım arasındaki farkı, kendi örneklerinle açıkla.

#🎮 Mini Uygulama — Uyarlanabilir Ürün Kataloğu

Bölüm 4'te öğrendiğin form, tema ve responsive tasarım konularını birleştiren bir mini proje:

Gereksinimler:

• ThemeData ile özel bir tema tanımla (renk, buton stili).
• MediaQuery/LayoutBuilder ile, dar ekranda 2 sütunlu, geniş ekranda 4 sütunlu bir ürün ızgarası (GridView.builder, Bölüm 3 Konu 11'i hatırla) göster.
• Her ürün kartına tıklanınca (Bölüm 3 Konu 14'ü hatırla — Navigator.push), bir "ürün detay" ekranına geç.
• Detay ekranında, Form + TextFormField ile basit bir "yorum yaz" formu ekle (validasyonlu — boş yorum gönderilemesin).
• AppBar'da bir karanlık mod switch'i ekle (Bölüm 4 Konu 16'yı hatırla).

Bu proje, Bölüm 2, 3 ve 4'ün tamamını kapsayan, gerçekçi bir uygulama parçasıdır.

#🏁 Bölüm 4 Tamamlandı!

Form yönetimini, validasyonu, tema sistemini ve responsive/adaptive tasarımı öğrendin. Artık kullanıcıdan veri alabilen, tutarlı stillere sahip ve farklı ekran boyutlarına uyum sağlayan uygulamalar yazabiliyorsun.

Sıradaki durak Bölüm 5 — Asenkron Dünya & Veri: FutureBuilder, StreamBuilder, HTTP istekleri ve JSON serialization ile, uygulamanı gerçek bir API'ye bağlayacaksın — Dart Bölüm 10'da öğrendiğin Future/Stream bilgisinin Flutter'daki tam karşılığını göreceksin.

Bölüm 5'e hoş geldin — burada Dart Bölüm 10'da öğrendiğin Future/async/await bilgisi doğrudan işine yarayacak. Yeni bir kavram öğrenmiyorsun, var olan bilgini Flutter'ın UI dünyasına uyguluyorsun.

#Sorun: Asenkron Veri, Senkron UI

Dart Bölüm 10'da, bir Future'ın sonucunun gelmesini beklerken, programın donmadığını öğrenmiştik. Ama Flutter'da bir problem var: build() metodu (Bölüm 2 Konu 5'i hatırla), senkron çalışmak zorundadır — build() içinde await kullanamazsın.

@override
Widget build(BuildContext context) {
  final veri = await birApiCagrisi(); // ❌ HATA! build() async olamaz
  return Text(veri);
}

Neden olmaz? build(), Flutter'ın belirli bir anda, senkron olarak çağırdığı bir metoddur — Bölüm 1 Konu 1'de öğrendiğimiz RenderObject ağacının, her frame'de tutarlı bir şekilde güncellenmesi gerekir. Eğer build() "bekleyebilseydi", Flutter'ın ne zaman ekranı çizeceğini bilmesi imkansız hale gelirdi.

#FutureBuilder — Çözüm

FutureBuilder<String>(
  future: birApiCagrisi(),
  builder: (BuildContext context, AsyncSnapshot<String> snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return CircularProgressIndicator(); // yükleniyor
    } else if (snapshot.hasError) {
      return Text('Hata: ${snapshot.error}');
    } else {
      return Text('Veri: ${snapshot.data}');
    }
  },
)

FutureBuilder, Bölüm 3 Konu 11'de öğrendiğimiz builder pattern'in bir başka uygulamasıdır — ama bu sefer, builder fonksiyonu birden fazla kez çağrılır: bir kere Future beklerken, bir kere daha Future tamamlandığında (Flutter, arka planda bunu senin için setState() benzeri bir mekanizmayla yönetir).

#AsyncSnapshot — Future'ın "O Anki Durumunun" Fotoğrafı

Dart Bölüm 10'da bir Future'ın üç olası durumu olduğunu öğrenmiştik (henüz tamamlanmadı / başarıyla tamamlandı / hata ile tamamlandı). AsyncSnapshot<T>, Dart Bölüm 9'da öğrendiğimiz generic bir sınıf olarak, bu üç durumu tek bir nesnede kapsüller:

snapshot.connectionState  // ConnectionState.none / waiting / active / done
snapshot.hasData          // veri geldi mi? (bool)
snapshot.data             // gelen veri (T?, nullable!)
snapshot.hasError         // hata oluştu mu? (bool)
snapshot.error            // oluşan hata (Object?, nullable!)

Dikkat et: snapshot.data, nullable'dır (Dart Bölüm 2'yi hatırla) — çünkü Future henüz tamamlanmamışsa, henüz bir veri yok. Bu yüzden snapshot.data kullanmadan önce, connectionState veya hasData ile kontrol etmen gerekir — tıpkı Bölüm 2'de öğrendiğimiz null safety pratiklerinde olduğu gibi.

#ConnectionState — Bir Enum, Dart Bölüm 7'yi Hatırla

enum ConnectionState { none, waiting, active, done }

Bu, Dart Bölüm 7'de öğrendiğimiz enum'un, Flutter'ın kendi kütüphanesinde tanımlanmış bir örneğidir:

• none: henüz bir future verilmedi.
• waiting: future çalışıyor, henüz tamamlanmadı.
• done: future tamamlandı (başarılı veya hatalı).

FutureBuilder ile en sık waiting ve done durumlarını kontrol edersin.

#Gerçek Bir Örnek — Simüle Edilmiş API Çağrısı

class VeriEkrani extends StatelessWidget {
  const VeriEkrani({super.key});

  Future<String> _veriGetir() async {
    await Future.delayed(Duration(seconds: 2)); // Dart Bölüm 10'u hatırla
    return 'Sunucudan gelen veri';
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Veri Ekranı')),
      body: Center(
        child: FutureBuilder<String>(
          future: _veriGetir(),
          builder: (context, snapshot) {
            if (snapshot.connectionState == ConnectionState.waiting) {
              return CircularProgressIndicator();
            }
            if (snapshot.hasError) {
              return Text('Bir hata oluştu: ${snapshot.error}');
            }
            return Text(snapshot.data!); // done durumunda, data artık null değil
          },
        ),
      ),
    );
  }
}

Bu kod çalıştığında: 2 saniye boyunca bir yükleme göstergesi (CircularProgressIndicator) görünür, sonra otomatik olarak "Sunucudan gelen veri" metnine geçer — kullanıcı hiçbir şey yapmadan.

#Kritik Bir Tuzak — future: Parametresini build() İçinde Doğrudan Çağırmak

// ❌ TEHLİKELİ pratik
class VeriEkraniYanlis extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return FutureBuilder<String>(
      future: _veriGetir(), // HER rebuild'de YENİDEN çağrılır!
      builder: (context, snapshot) { ... },
    );
  }
}

Bölüm 2 Konu 6'da öğrendiğimiz build()'in her rebuild'de tekrar çalıştığını hatırlarsan — bu, ciddi bir soruna yol açıyor: eğer bu widget'ı içeren bir üst widget herhangi bir sebeple setState() çağırırsa (Bölüm 2'yi hatırla), build() tekrar çalışır, ve _veriGetir() her seferinde yeniden çağrılır — yani API isteği gereksiz yere tekrar tekrar atılır!

Doğru pratik — Future'ı StatefulWidget'ın state'inde saklamak:

class VeriEkraniDogru extends StatefulWidget {
  const VeriEkraniDogru({super.key});

  @override
  State<VeriEkraniDogru> createState() => _VeriEkraniDogruState();
}

class _VeriEkraniDogruState extends State<VeriEkraniDogru> {
  late final Future<String> _veriFuture; // late final — Dart Bölüm 8'i hatırla!

  @override
  void initState() {
    super.initState();
    _veriFuture = _veriGetir(); // SADECE BİR KERE çağrılır
  }

  Future<String> _veriGetir() async {
    await Future.delayed(Duration(seconds: 2));
    return 'Sunucudan gelen veri';
  }

  @override
  Widget build(BuildContext context) {
    return FutureBuilder<String>(
      future: _veriFuture, // her rebuild'de AYNI future kullanılıyor
      builder: (context, snapshot) {
        if (snapshot.connectionState == ConnectionState.waiting) {
          return CircularProgressIndicator();
        }
        return Text(snapshot.data ?? 'Veri yok');
      },
    );
  }
}

late final Future<String> _veriFuture — Dart Bölüm 8 Konu 40'ta öğrendiğimiz late'in lazy initialization dışındaki asıl kullanım senaryosunu görüyorsun: alan, constructor'da değil, initState() içinde (Bölüm 2 Konu 6'da kısaca gördüğümüz, bir kere çalışan metod) atanıyor, ama non-nullable kalıyor. initState(), sadece bir kere çağrıldığı için, _veriGetir() de sadece bir kere çalışıyor — build() ne kadar tekrar çalışırsa çalışsın, aynı Future nesnesi kullanılıyor.

#?? ile Güvenli Varsayılan Değer

Text(snapshot.data ?? 'Veri yok')

Dart Bölüm 2/3'te öğrendiğimiz ?? operatörü, burada çok yaygın bir kalıptır — snapshot.data nullable olduğu için, ! ile zorlamak yerine (riskli, Bölüm 2'yi hatırla), ?? ile güvenli bir varsayılan sağlamak daha iyi bir pratiktir.

#🎯 Bu Dersten Çıkarılması Gerekenler

• build() senkron çalışmak zorundadır, await kullanamaz — FutureBuilder, bir Future'ın durumuna göre farklı UI göstermeyi sağlar.
• AsyncSnapshot, bir Future'ın o anki durumunu (waiting/done, data, error) kapsülleyen generic bir sınıftır.
• snapshot.data/snapshot.error nullable'dır — kullanmadan önce connectionState veya hasData/hasError ile kontrol edilmelidir.
• Kritik tuzak: future: parametresine build() içinde doğrudan bir fonksiyon çağrısı vermek, her rebuild'de gereksiz yeniden çağrılara yol açar — Future'ı initState() içinde, late final bir alanda saklamak doğru çözümdür.

#📝 Ödevler

• [ ] Future.delayed ile sahte bir veri çeken, FutureBuilder ile loading/error/success durumlarını yöneten bir ekran yaz.
• [ ] Bilerek future: parametresine doğrudan bir fonksiyon çağrısı ver, üst widget'ta bir setState() tetikleyerek API çağrısının tekrar tekrar yapıldığını (bir print ile sayarak) kanıtla.
• [ ] Aynı sorunu, initState() + late final kalıbıyla düzelt, artık sadece bir kere çağrıldığını doğrula.
• [ ] FutureBuilder'da bilerek bir hata fırlatan bir future kullan (throw Exception(...)), snapshot.hasError ile bunu yakalayıp kullanıcıya göster.
• [ ] ConnectionState'in farklı durumlarını (waiting, done) print ile takip ederek, FutureBuilder'ın builder fonksiyonunun kaç kez çağrıldığını gözlemle.

Sıradaki konu: Bölüm 5 — Konu 19: Stream, StreamBuilder

Bir önceki derste FutureBuilder'ı ("bir kerelik" asenkron veri için) öğrendik. Bu derste, Dart Bölüm 10'da öğrendiğimiz Stream ("zamanla, tekrar tekrar gelen veri") kavramının Flutter karşılığını işleyeceğiz.

#StreamBuilder — FutureBuilder'ın Kuzeni

StreamBuilder<int>(
  stream: sayacStream(),
  builder: (BuildContext context, AsyncSnapshot<int> snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return CircularProgressIndicator();
    }
    if (snapshot.hasError) {
      return Text('Hata: ${snapshot.error}');
    }
    return Text('Değer: ${snapshot.data}');
  },
)

Fark hemen görülüyor: StreamBuilder, future: yerine stream: parametresi alıyor — ama builder fonksiyonunun imzası birebir aynı (AsyncSnapshot<T> kullanıyor, Bölüm 5 Konu 18'i hatırla). Bu, Flutter'ın API tasarımında tutarlılığı ne kadar önemsediğini gösteriyor — bir kere FutureBuilder'ı öğrendiğinde, StreamBuilder'ı öğrenmek neredeyse ücretsiz oluyor.

#Temel Fark: builder, Kaç Kere Çağrılır?

Dart Bölüm 10 Konu 47'de Stream'in zamanla birden fazla değer ürettiğini öğrenmiştik. StreamBuilder'ın builder fonksiyonu, bu yüzden her yeni veri geldiğinde tekrar çağrılır:

Stream<int> sayacStream() async* {
  for (int i = 1; i <= 5; i++) {
    await Future.delayed(Duration(seconds: 1));
    yield i;
  }
}

Bu stream'i StreamBuilder ile dinlediğinde, ekranda sırasıyla 1, 2, 3, 4, 5 görürsün — her yield gerçekleştiğinde, StreamBuilder otomatik olarak widget'ı yeniden çizer (Bölüm 2 Konu 6'da öğrendiğimiz setState()'e benzer bir mekanizmayı, framework senin için otomatik olarak yönetiyor).

#Neden Bu Kadar Değerli? — setState() ile Karşılaştırma

StreamBuilder olmadan, aynı işi yapmak isteseydin:

// ❌ Elle yönetim — çok daha karmaşık
class SayacWidget extends StatefulWidget {
  @override
  State<SayacWidget> createState() => _SayacWidgetState();
}

class _SayacWidgetState extends State<SayacWidget> {
  int? _deger;
  late StreamSubscription _subscription;

  @override
  void initState() {
    super.initState();
    _subscription = sayacStream().listen((veri) {
      setState(() {
        _deger = veri;
      });
    });
  }

  @override
  void dispose() {
    _subscription.cancel(); // Bölüm 5 Konu 20'de dispose'u derinlemesine göreceğiz
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Text('Değer: ${_deger ?? "Bekleniyor"}');
  }
}

Bu, çalışır ama çok daha fazla kod ve elle yönetilmesi gereken kaynaklar (_subscription.cancel()'ı unutursan, Dart Bölüm 10'da öğrendiğimiz stream kaynak sızıntısı riski) içeriyor. StreamBuilder, bunların hepsini otomatik olarak yapar — widget ekrandan kaldırıldığında, aboneliği kendisi iptal eder.

#Gerçek Dünya Senaryosu — Canlı Sayaç

class CanliSayac extends StatelessWidget {
  const CanliSayac({super.key});

  Stream<int> _sayacStream() async* {
    int sayi = 0;
    while (true) {
      await Future.delayed(Duration(seconds: 1));
      yield sayi++;
    }
  }

  @override
  Widget build(BuildContext context) {
    return StreamBuilder<int>(
      stream: _sayacStream(),
      initialData: 0, // stream'den ilk veri gelene kadar gösterilecek değer
      builder: (context, snapshot) {
        return Text(
          '${snapshot.data}',
          style: TextStyle(fontSize: 48),
        );
      },
    );
  }
}

initialData parametresi — Dart Bölüm 5'te öğrendiğimiz varsayılan parametre kavramına benzer bir mantıkla çalışır: stream henüz hiç veri üretmemişse (ilk yield'den önce), snapshot.data yerine bu başlangıç değeri kullanılır. Bu, FutureBuilder'da olmayan, StreamBuilder'a özgü kullanışlı bir parametredir — çünkü stream'in "hiç veri üretmeden bekleme" süresi genelde daha belirsiz olabilir.

#Stream Aynı Future'daki Gibi Tuzağa Dikkat

Bölüm 5 Konu 18'de öğrendiğimiz kritik tuzağı hatırla — stream: parametresine build() içinde doğrudan bir fonksiyon çağrısı vermek, burada da aynı sorunu yaratır:

// ❌ TEHLİKELİ — her rebuild'de YENİ bir stream başlatılır
StreamBuilder<int>(
  stream: _sayacStream(), // her build() çağrısında yeni bir stream!
  builder: (context, snapshot) => Text('${snapshot.data}'),
)

Doğru çözüm, aynı kalıp:

class CanliSayacDogru extends StatefulWidget {
  @override
  State<CanliSayacDogru> createState() => _CanliSayacDogruState();
}

class _CanliSayacDogruState extends State<CanliSayacDogru> {
  late final Stream<int> _stream; // Bölüm 5 Konu 18'deki AYNI kalıp

  @override
  void initState() {
    super.initState();
    _stream = _sayacStream(); // sadece bir kere oluşturulur
  }

  Stream<int> _sayacStream() async* {
    int sayi = 0;
    while (true) {
      await Future.delayed(Duration(seconds: 1));
      yield sayi++;
    }
  }

  @override
  Widget build(BuildContext context) {
    return StreamBuilder<int>(
      stream: _stream,
      builder: (context, snapshot) => Text('${snapshot.data ?? 0}'),
    );
  }
}

#Broadcast Stream ile Kullanım — Dart Bölüm 10'u Hatırlama

Dart Bölüm 10 Konu 48'de öğrendiğimiz broadcast stream'i hatırlarsan — eğer aynı stream'i birden fazla StreamBuilder (farklı widget'larda) dinleyecekse, o stream'in broadcast olması gerekir:

class BildirimServisi {
  final StreamController<String> _controller = StreamController<String>.broadcast();
  Stream<String> get bildirimler => _controller.stream;

  void bildirimGonder(String mesaj) {
    _controller.add(mesaj);
  }
}

Bu, gerçek uygulamalarda birden fazla ekranın aynı veri kaynağını (örneğin bir "okunmamış mesaj sayısı" göstergesi, hem ana ekranda hem ayarlar ekranında) dinlemesi gerektiğinde kullanılan bir kalıptır — Bölüm 6'da state management konusuna geldiğimizde, bu kalıbın daha gelişmiş versiyonlarını (Provider, Riverpod gibi araçlarla) göreceğiz.

#FutureBuilder vs StreamBuilder — Ne Zaman Hangisi?

#🎯 Bu Dersten Çıkarılması Gerekenler

• StreamBuilder, FutureBuilder ile aynı AsyncSnapshot<T> API'sini kullanır, ama builder, stream her yeni veri ürettiğinde tekrar çağrılır.
• StreamBuilder, elle listen()/setState()/cancel() yönetiminin yerine geçer — abonelik yönetimini otomatik yapar.
• initialData, stream ilk veriyi üretene kadar gösterilecek varsayılan değeri belirtir.
• stream: parametresine build() içinde doğrudan fonksiyon çağrısı vermek, FutureBuilder'daki gibi bir tuzaktır — initState() + late final ile çözülür.
• Birden fazla widget aynı stream'i dinleyecekse, stream'in broadcast olması gerekir (Dart Bölüm 10'u hatırla).

#📝 Ödevler

• [ ] Stream.periodic veya async*/yield ile her saniye artan bir sayaç gösteren StreamBuilder örneği yaz.
• [ ] initialData kullanarak, stream ilk veriyi üretmeden önce gösterilecek bir başlangıç değeri belirle.
• [ ] Bilerek stream: parametresine doğrudan fonksiyon çağrısı vererek tuzağa düş, sonra initState() + late final ile düzelt.
• [ ] Broadcast bir StreamController oluştur, aynı stream'i iki farklı StreamBuilder widget'ında dinle.
• [ ] Kendi cümlelerinle, "FutureBuilder ile StreamBuilder'ı ne zaman kullanmalıyım" sorusunu, Dart Bölüm 10'da öğrendiğin Future/Stream farkına dayanarak açıkla.

Sıradaki konu: Bölüm 5 — Konu 20: HTTP İstekleri (http / dio Paketleri)

Bu derste, uygulamanı gerçek bir API'ye bağlayacaksın — Bölüm 5 Konu 18'de simüle ettiğimiz "sahte gecikme"leri, artık gerçek ağ istekleriyle değiştireceğiz.

#Paketi Ekleme — Dart Bölüm 12'yi Hatırlama

flutter pub add http

Bu, Dart Bölüm 12 Konu 53'te öğrendiğimiz dart pub add'in birebir aynısı — Flutter projelerinde de aynı komut (flutter pub add, dart pub add'in Flutter'a özel bir sarmalayıcısıdır) kullanılır.

#Basit Bir GET İsteği

import 'package:http/http.dart' as http;
import 'dart:convert';

Future<void> veriGetir() async {
  final response = await http.get(
    Uri.parse('https://jsonplaceholder.typicode.com/posts/1'),
  );

  if (response.statusCode == 200) {
    print('Başarılı: ${response.body}');
  } else {
    print('Hata: ${response.statusCode}');
  }
}

import 'package:http/http.dart' as http; — Dart Bölüm 12 Konu 54'te öğrendiğimiz as ile isim çakışmasını önleme kalıbı burada standart bir pratik olarak kullanılıyor. http.get(...), Bölüm 5 Konu 18'de öğrendiğimiz Future<String> mantığına tamamen benzer bir Future<Response> döndürür — await ile bekliyoruz.

response.statusCode — HTTP protokolünün durum kodları (200 başarılı, 404 bulunamadı, 500 sunucu hatası gibi). Bu, Dart Bölüm 3'te öğrendiğimiz switch/if-else ile kontrol edilebilecek bir değerdir.

#JSON Parse Etme — dart:convert

import 'dart:convert';

Future<void> veriGetir() async {
  final response = await http.get(Uri.parse('https://jsonplaceholder.typicode.com/posts/1'));

  if (response.statusCode == 200) {
    final Map<String, dynamic> veri = jsonDecode(response.body);
    print(veri['title']); // JSON içindeki 'title' alanına erişim
  }
}

jsonDecode(), bir JSON string'ini, Dart Bölüm 4'te öğrendiğimiz Map<String, dynamic> (veya List<dynamic>, eğer JSON bir dizi ise) yapısına çevirir. Bölüm 4 Konu 18'de "JSON gibi karışık tipli verilerle çalışırken dynamic meşru bir kullanım alanıdır" demiştik — işte tam olarak bu senaryo.

#Bunu FutureBuilder ile Ekrana Bağlamak

class GonderiEkrani extends StatefulWidget {
  const GonderiEkrani({super.key});

  @override
  State<GonderiEkrani> createState() => _GonderiEkraniState();
}

class _GonderiEkraniState extends State<GonderiEkrani> {
  late final Future<Map<String, dynamic>> _gonderiFuture; // Bölüm 5 Konu 18'deki kalıp!

  @override
  void initState() {
    super.initState();
    _gonderiFuture = _gonderiGetir();
  }

  Future<Map<String, dynamic>> _gonderiGetir() async {
    final response = await http.get(
      Uri.parse('https://jsonplaceholder.typicode.com/posts/1'),
    );
    if (response.statusCode == 200) {
      return jsonDecode(response.body);
    } else {
      throw Exception('Veri alınamadı: ${response.statusCode}'); // Dart Bölüm 8'i hatırla
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Gönderi')),
      body: FutureBuilder<Map<String, dynamic>>(
        future: _gonderiFuture,
        builder: (context, snapshot) {
          if (snapshot.connectionState == ConnectionState.waiting) {
            return Center(child: CircularProgressIndicator());
          }
          if (snapshot.hasError) {
            return Center(child: Text('Hata: ${snapshot.error}'));
          }
          final veri = snapshot.data!;
          return Padding(
            padding: EdgeInsets.all(16),
            child: Column(
              crossAxisAlignment: CrossAxisAlignment.start,
              children: [
                Text(veri['title'], style: TextStyle(fontSize: 20, fontWeight: FontWeight.bold)),
                SizedBox(height: 8),
                Text(veri['body']),
              ],
            ),
          );
        },
      ),
    );
  }
}

Bu kod, Bölüm 5 Konu 18'de öğrendiğimiz tüm doğru pratiği (late final + initState()) gerçek bir API çağrısıyla birleştiriyor — ve Dart Bölüm 8'de öğrendiğimiz throw Exception(...)'ın, FutureBuilder'ın snapshot.hasError mekanizmasıyla doğal olarak nasıl entegre olduğunu gösteriyor.

#POST İsteği — Sunucuya Veri Gönderme

Future<void> gonderiOlustur(String baslik, String icerik) async {
  final response = await http.post(
    Uri.parse('https://jsonplaceholder.typicode.com/posts'),
    headers: {'Content-Type': 'application/json'},
    body: jsonEncode({
      'title': baslik,
      'body': icerik,
    }),
  );

  if (response.statusCode == 201) {
    print('Gönderi oluşturuldu: ${response.body}');
  }
}

jsonEncode(), jsonDecode()'un tersidir — bir Dart Map (veya List) alır, JSON string'ine çevirir. Dart Bölüm 4'te öğrendiğimiz {...} map literal sözdizimini kullanarak, sunucuya göndereceğin veriyi kolayca oluşturabiliyorsun.

#dio Paketi — Daha Gelişmiş Bir Alternatif

flutter pub add dio

import 'package:dio/dio.dart';

final dio = Dio();

Future<void> veriGetir() async {
  try {
    final response = await dio.get('https://jsonplaceholder.typicode.com/posts/1');
    print(response.data); // dio, JSON'u OTOMATİK olarak decode eder!
  } on DioException catch (e) {
    print('Hata: ${e.message}');
  }
}

http ile dio arasındaki temel farklar:

Pratik tavsiye: Basit, küçük projeler için http yeterlidir. Daha büyük uygulamalarda, özellikle her isteğe otomatik bir authentication token eklemek, istekleri loglama, veya karmaşık hata yönetimi gerektiğinde, dio'nun sunduğu interceptor mekanizması çok değerli hale gelir.

#DioException — Dart Bölüm 8'i Hatırlama

try {
  final response = await dio.get('https://olmayan-bir-site.com');
} on DioException catch (e) {
  if (e.type == DioExceptionType.connectionTimeout) {
    print('Bağlantı zaman aşımına uğradı');
  } else if (e.type == DioExceptionType.badResponse) {
    print('Sunucu hatası: ${e.response?.statusCode}');
  } else {
    print('Bilinmeyen hata: ${e.message}');
  }
}

Bu, Dart Bölüm 8 Konu 39'da öğrendiğimiz özel exception sınıfları ve on TipAdı catch kalıbının, dio paketinin kendi tanımladığı bir exception türü (DioException) ile kullanılmasıdır — üçüncü parti paketler, kendi özel exception hiyerarşilerini tanımlayarak, sana daha anlamlı hata yönetimi imkanı sunar.

#🎯 Bu Dersten Çıkarılması Gerekenler

• http paketi, http.get()/http.post() ile basit HTTP istekleri yapmanı sağlar; Future<Response> döndürür.
• jsonDecode(), JSON string'ini Map<String, dynamic>'e çevirir; jsonEncode() bunun tersini yapar.
• FutureBuilder + initState()/late final kalıbı, gerçek API çağrılarında birebir aynı şekilde kullanılır.
• dio paketi, otomatik JSON decode, interceptor'lar ve gelişmiş hata yönetimi sunan daha güçlü bir alternatiftir.
• DioException, Dart'ta öğrendiğimiz özel exception sınıflarının, üçüncü parti bir pakette nasıl kullanıldığına dair gerçek bir örnektir.

#📝 Ödevler

• [ ] http paketi ile genel bir test API'sinden (jsonplaceholder.typicode.com gibi) veri çek, jsonDecode ile parse et, konsola yazdır.
• [ ] Çektiğin veriyi, FutureBuilder + initState()/late final kalıbıyla bir ekranda göster.
• [ ] http.post() ile aynı API'ye sahte bir veri gönder, cevabı yazdır.
• [ ] dio paketini kur, aynı GET isteğini dio ile tekrar yap, otomatik JSON decode'un farkını gözlemle.
• [ ] Var olmayan bir URL'ye istek atarak bir hata oluştur, FutureBuilder'ın snapshot.hasError mekanizmasıyla kullanıcıya anlamlı bir hata mesajı göster.

Sıradaki konu: Bölüm 5 — Konu 21: JSON Serialization (Manuel → json_serializable/freezed)

Bir önceki derste Map<String, dynamic> ile JSON verisiyle çalıştık — ama bu, Bölüm 4 Konu 18'de (Dart) "geçici bir kullanım, genelde sonra somut bir modele çevrilir" dediğimiz durumun tam olarak henüz o adımı atmadığımız halidir. Bu derste, JSON'u somut Dart sınıflarına çevirmeyi öğreneceğiz.

#Sorun: Map<String, dynamic> ile Çalışmanın Riskleri

final veri = jsonDecode(response.body);
print(veri['titel']); // ❌ Yazım hatası! "titel" değil "title" olmalıydı

Bu kod derlenir (çünkü dynamic — Dart Bölüm 2 Konu 8'i hatırla, tip kontrolünü kapatır) ama çalışma zamanında null döner (çünkü titel diye bir anahtar yok) — bu, tam olarak Bölüm 2'de "dynamic'ten mümkün olduğunca kaçın" dediğimiz riskin somut bir örneği.

#Manuel Model Sınıfı — fromJson/toJson

class Gonderi {
  final int id;
  final String title;
  final String body;

  Gonderi({required this.id, required this.title, required this.body});

  factory Gonderi.fromJson(Map<String, dynamic> json) {
    return Gonderi(
      id: json['id'],
      title: json['title'],
      body: json['body'],
    );
  }

  Map<String, dynamic> toJson() {
    return {
      'id': id,
      'title': title,
      'body': body,
    };
  }
}

factory Gonderi.fromJson(...) — Dart Bölüm 6 Konu 27'de öğrendiğimiz factory constructor'ı hatırlıyor musun? "Oluşturma mantığını özelleştirmeye izin verir" demiştik — işte tam olarak budur: bir Map<String, dynamic> alıp, onu doğrulayıp/dönüştürüp bir Gonderi nesnesi üreten özel bir oluşturma yolu.

Kullanımı:

Future<Gonderi> gonderiGetir() async {
  final response = await http.get(Uri.parse('https://jsonplaceholder.typicode.com/posts/1'));
  final Map<String, dynamic> json = jsonDecode(response.body);
  return Gonderi.fromJson(json); // artık tip güvenli!
}

final gonderi = await gonderiGetir();
print(gonderi.title); // ✅ IDE, 'title' alanının VAR OLDUĞUNU biliyor, yazım hatası imkansız

Artık gonderi.titel yazarsan, bu derleme zamanında hata verir (Dart Bölüm 6'da öğrendiğimiz alan erişimi kuralları geçerli) — tıpkı Bölüm 4'te (Dart) "JSON'u kısa süre sonra somut bir modele çevireceksen dynamic meşrudur" dediğimiz geçiş sürecinin tamamlandığı an.

#Listelerle Çalışma

Future<List<Gonderi>> gonderilerGetir() async {
  final response = await http.get(Uri.parse('https://jsonplaceholder.typicode.com/posts'));
  final List<dynamic> jsonListesi = jsonDecode(response.body);
  return jsonListesi.map((json) => Gonderi.fromJson(json)).toList();
}

jsonListesi.map(...) — Dart Bölüm 11'de öğrendiğimiz .map() metodu, burada son derece doğal bir kullanım alanı buluyor: her ham JSON nesnesini, Gonderi.fromJson() ile somut bir Dart nesnesine dönüştürüyoruz. Bu, Dart Bölüm 11'de öğrendiğimiz "koleksiyon dönüşümü" bilgisinin, gerçek dünya API entegrasyonunda doğrudan kullanıldığı bir andır.

#Manuel Yazmanın Sorunu — Tekrarlayan, Sıkıcı Kod

Küçük modellerde manuel fromJson/toJson yazmak makul, ama büyük, çok alanlı modellerde bu hem uzun hem hataya açık hale gelir. İşte bu yüzden Dart Bölüm 13 Konu 66'da öğrendiğimiz kod üretimi (code generation) burada devreye giriyor.

#json_serializable — Otomatik Üretim

flutter pub add json_annotation
flutter pub add --dev json_serializable build_runner

import 'package:json_annotation/json_annotation.dart';

part 'gonderi.g.dart'; // Dart Bölüm 12'de öğrendiğimiz part/part of!

@JsonSerializable()
class Gonderi {
  final int id;
  final String title;
  final String body;

  Gonderi({required this.id, required this.title, required this.body});

  factory Gonderi.fromJson(Map<String, dynamic> json) => _$GonderiFromJson(json);
  Map<String, dynamic> toJson() => _$GonderiToJson(this);
}

dart run build_runner build

Bu, Dart Bölüm 13 Konu 66'da tam olarak işlediğimiz kalıbın birebir aynısı — @JsonSerializable() annotation'ı, build_runner'a "bu class için fromJson/toJson implementasyonunu otomatik üret" diyor. Üretilen gonderi.g.dart dosyası, _$GonderiFromJson/_$GonderiToJson fonksiyonlarının gerçek kodunu içeriyor — sen bunu elle yazmak zorunda değilsin.

Neden değerli? 20 alanlı bir modelde, her alanı elle json['alan_adi'] şeklinde eşleştirmek yerine, build_runner bunu senin için, hatasız yapıyor — ve model değiştiğinde (yeni alan eklediğinde), sadece dart run build_runner build'i tekrar çalıştırman yeterli.

#freezed — Immutable Modeller + JSON Serialization Bir Arada

flutter pub add freezed_annotation
flutter pub add --dev build_runner freezed

import 'package:freezed_annotation/freezed_annotation.dart';

part 'gonderi.freezed.dart';
part 'gonderi.g.dart';

@freezed
class Gonderi with _$Gonderi {
  const factory Gonderi({
    required int id,
    required String title,
    required String body,
  }) = _Gonderi;

  factory Gonderi.fromJson(Map<String, dynamic> json) => _$GonderiFromJson(json);
}

Dart Bölüm 13 Konu 66'da freezed'i kısaca tanıtmıştık — burada tam olarak neyi otomatikleştirdiğini görelim. freezed, sadece JSON serialization'ı değil, tüm immutable veri sınıfı davranışlarını üretir:

• == ve hashCode (içerik bazlı eşitlik — Dart Bölüm 6'da bahsettiğimiz ama elle yazmadığımız bir konu).
• toString() (Bölüm 6'da elle yazdığımız kalıbın otomasyonu).
• copyWith() — Bölüm 3 Konu 12'de (Flutter) öğrendiğimiz TextStyle.copyWith() kalıbının, kendi modellerin için otomatik üretilmiş hali!

final gonderi = Gonderi(id: 1, title: 'Başlık', body: 'İçerik');
final guncellenmisGonderi = gonderi.copyWith(title: 'Yeni Başlık');
// id ve body aynı kaldı, sadece title değişti

#Manuel vs json_serializable vs freezed — Ne Zaman Hangisi?

Pratik tavsiye: Küçük prototiplerde manuel yazmak hızlıdır. Gerçek, büyüyen bir projede, freezed, hem JSON serialization'ı hem immutability (Bölüm 6'da state management'ta çok değerli olacak) hem de copyWith()'i tek bir araçla hallettiği için genelde en tercih edilen seçenektir.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Map<String, dynamic> ile doğrudan çalışmak, yazım hatalarını çalışma zamanına kadar gizler; somut model sınıfları (fromJson/toJson) bunu derleme zamanına taşır.
• factory Gonderi.fromJson(...), Dart'ta öğrendiğimiz factory constructor'ın gerçek bir JSON dönüştürme senaryosudur.
• .map() ile bir JSON listesini, somut model nesnelerinin listesine dönüştürmek, Dart'ta öğrendiğimiz koleksiyon dönüşümünün doğal bir uygulamasıdır.
• json_serializable, build_runner ile fromJson/toJson kodunu otomatik üretir — Dart Bölüm 13'te öğrendiğimiz kod üretimi kalıbının gerçek kullanımı.
• freezed, JSON serialization'a ek olarak copyWith(), ==, toString() gibi tüm immutable veri sınıfı davranışlarını otomatik üretir.

#📝 Ödevler

• [ ] Basit bir JSON yanıtı için (örn. bir kullanıcı: id, isim, email) manuel bir model sınıfı yaz, fromJson/toJson ekle.
• [ ] Bir JSON listesini, .map() ile model nesnelerinin listesine dönüştür.
• [ ] json_serializable kurup, aynı modeli @JsonSerializable() ile yeniden yaz, build_runner ile kod üret, üretilen dosyayı incele.
• [ ] freezed kurup, aynı modeli @freezed ile yeniden yaz, copyWith()'i kullanarak bir alanı güncelle.
• [ ] Kendi cümlelerinle, "neden büyük projelerde manuel JSON serialization yerine kod üretimi tercih edilir" sorusunu açıkla.

#🎮 Mini Uygulama — Gerçek API'den Gönderi Listesi

Bölüm 5'te öğrendiğin her şeyi birleştiren bir mini proje:

Gereksinimler:

• jsonplaceholder.typicode.com/posts API'sinden gönderi listesini çek (http paketi).
• Ham JSON'u, kendi yazdığın Gonderi model sınıfına (fromJson ile) dönüştür.
• FutureBuilder + initState()/late final kalıbıyla, listeyi bir ListView.builder (Bölüm 3 Konu 11'i hatırla) içinde göster.
• Her gönderiye tıklandığında (Bölüm 3 Konu 14'ü hatırla), o gönderinin tam detayını gösteren bir ekrana geç (constructor parametresi ile veri gönder).
• Yükleme sırasında CircularProgressIndicator, hata durumunda anlamlı bir mesaj göster.

Bu, artık gerçek, uçtan uca çalışan bir uygulama parçası — internetten veri çekiyor, tip güvenli modellere dönüştürüyor, listeliyorsun ve detaya gidebiliyorsun.

Sıradaki konu: Bölüm 5 — Konu 22: Local Storage (shared_preferences → Hive → sqflite/Drift)

Bölüm 5'in son konusundayız. Şimdiye kadar veriyi ağdan (HTTP ile) çektik — bu derste, veriyi cihazın kendisinde, kalıcı olarak saklamayı öğreneceğiz. Uygulama kapanıp yeniden açıldığında bile verinin kaybolmamasını sağlayan üç farklı yaklaşımı, artan karmaşıklık sırasına göre işleyeceğiz.

#Neden "Kalıcı" Depolamaya İhtiyaç Var?

Dart Bölüm 13 Konu 62'de öğrendiğimiz bellek (RAM), uygulama kapandığında tamamen silinir. Bir StatefulWidget'ın state'i (Bölüm 2 Konu 6'yı hatırla), sadece uygulama çalışırken var olur. Kullanıcının bir tercihini (örneğin tema seçimi), oturum bilgisini, veya çektiği verileri kalıcı olarak saklamak istiyorsan, cihazın disk depolamasını kullanman gerekir.

#Seviye 1: shared_preferences — Basit Anahtar-Değer Depolama

flutter pub add shared_preferences

import 'package:shared_preferences/shared_preferences.dart';

Future<void> kullaniciAdiKaydet(String isim) async {
  final prefs = await SharedPreferences.getInstance();
  await prefs.setString('kullanici_adi', isim);
}

Future<String?> kullaniciAdiOku() async {
  final prefs = await SharedPreferences.getInstance();
  return prefs.getString('kullanici_adi');
}

shared_preferences, Dart Bölüm 4'te öğrendiğimiz Map<String, dynamic> mantığına çok benzer — basit anahtar-değer çiftleri (String, int, bool, double, List<String>) saklar. getInstance(), Dart Bölüm 6'da öğrendiğimiz static metod kalıbının bir örneği — bu, aslında singleton deseninin (Dart Bölüm 6 Konu 27'de "factory constructor, var olan bir nesneyi döndürebilir" dediğimiz kavramın somut uygulaması) bir kullanımıdır.

Ne zaman kullanılır? Basit ayarlar (tema tercihi, "bir daha gösterme" seçeneği, giriş yapmış kullanıcının adı gibi) için idealdir. Büyük veya karmaşık veri için uygun değildir — çünkü arka planda, tüm veri tek bir dosyada, düz metin olarak saklanır, bu da büyük veri setlerinde yavaşlar.

#Seviye 2: Hive — Hızlı, NoSQL Tarzı Yerel Veritabanı

flutter pub add hive hive_flutter

import 'package:hive_flutter/hive_flutter.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Hive.initFlutter();
  await Hive.openBox('ayarlar');
  runApp(MyApp());
}

// Yazma
Future<void> ayarKaydet(String anahtar, dynamic deger) async {
  final box = Hive.box('ayarlar');
  await box.put(anahtar, deger);
}

// Okuma
dynamic ayarOku(String anahtar) {
  final box = Hive.box('ayarlar');
  return box.get(anahtar);
}

WidgetsFlutterBinding.ensureInitialized() — bu, Bölüm 1 Konu 1'de öğrendiğimiz Flutter'ın motor başlatma sürecine ait bir çağrıdır; main() içinde, runApp()'tan önce herhangi bir native platform işlemi (Hive gibi disk erişimi gerektiren kütüphaneler) çalıştırmadan önce gereklidir — Flutter'ın widget sistemini, native koda bağlamadan önce "hazırlar."

Hive'ın shared_preferences'tan farkı: Hive, Box adı verilen "kutulara" organize edilmiş, daha büyük ve karmaşık veri saklayabilir — sadece basit tipler değil, kendi tanımladığın class'ları bile (uygun bir "adapter" ile) saklayabilirsin. Ayrıca Hive, performans için optimize edilmiştir — Dart'ın kendisiyle (native olmayan) yazıldığı için, tüm platformlarda (özellikle web'de) tutarlı çalışır.

#Seviye 3: sqflite/Drift — İlişkisel (SQL) Veritabanı

flutter pub add sqflite

import 'package:sqflite/sqflite.dart';
import 'package:path/path.dart';

Future<Database> veriTabaniAc() async {
  return openDatabase(
    join(await getDatabasesPath(), 'uygulama.db'),
    onCreate: (db, version) {
      return db.execute(
        'CREATE TABLE kullanicilar(id INTEGER PRIMARY KEY, isim TEXT, yas INTEGER)',
      );
    },
    version: 1,
  );
}

Future<void> kullaniciEkle(Database db, String isim, int yas) async {
  await db.insert('kullanicilar', {'isim': isim, 'yas': yas});
}

Future<List<Map<String, dynamic>>> kullanicilariGetir(Database db) async {
  return await db.query('kullanicilar');
}

sqflite, SQLite (dünyada en yaygın kullanılan gömülü ilişkisel veritabanı motoru) için bir Flutter bağlayıcısıdır. Ham SQL sorgularını (CREATE TABLE, INSERT, SELECT) yazmanı gerektirir. Dart Bölüm 4'te öğrendiğimiz Map<String, dynamic> burada yine karşımıza çıkıyor — db.query(), sonucu bu formatta döndürür, tıpkı JSON'da olduğu gibi.

#Drift — Tip Güvenli SQL (Kod Üretimi ile)

flutter pub add drift sqlite3_flutter_libs
flutter pub add --dev drift_dev build_runner

import 'package:drift/drift.dart';

part 'veritabani.g.dart'; // Bölüm 5 Konu 21'i hatırla — code generation!

class Kullanicilar extends Table {
  IntColumn get id => integer().autoIncrement()();
  TextColumn get isim => text()();
  IntColumn get yas => integer()();
}

@DriftDatabase(tables: [Kullanicilar])
class VeriTabani extends _$VeriTabani {
  VeriTabani() : super(_openConnection());
  // ...
}

Drift, sqflite'ın üzerine inşa edilmiş, Bölüm 5 Konu 21'de öğrendiğimiz kod üretimi (build_runner) kullanarak, ham SQL string'leri yazmadan, tip güvenli bir şekilde veritabanı sorguları yazmanı sağlar. Bu, tıpkı json_serializable'ın "elle JSON parse etmek yerine, tip güvenli, otomatik üretilen kod" felsefesinin, veritabanı sorgularına uygulanmış halidir.

#Üç Seviyeyi Karşılaştıralım

#Pratik Bir Karar Rehberi

shared_preferences kullan, eğer:

• Sadece birkaç basit ayar saklıyorsan (tema, dil tercihi, "onboarding gösterildi mi" gibi bool bayraklar).

Hive kullan, eğer:

• Orta karmaşıklıkta veri saklıyorsan (kullanıcı profili, favori listesi) ve hızlı, basit bir API istiyorsan.
• Web dahil tüm platformlarda tutarlı performans istiyorsan.

sqflite/Drift kullan, eğer:

• Verilerin birbiriyle ilişkili olması gerekiyorsa (örneğin bir "sipariş" tablosu, bir "sipariş kalemleri" tablosuyla ilişkili).
• Karmaşık sorgular (filtreleme, sıralama, gruplama) yapman gerekiyorsa.
• Uygulaman çevrimdışı-öncelikli (offline-first) bir mimari kullanıyorsa ve büyük miktarda yapılandırılmış veri tutuyorsa.

#🎯 Bu Dersten Çıkarılması Gerekenler

• shared_preferences, basit anahtar-değer çiftlerini kalıcı olarak saklamanın en kolay yoludur — küçük ayarlar için idealdir.
• Hive, daha karmaşık nesneleri, kutulara organize ederek, yüksek performansla saklayan bir NoSQL tarzı çözümdür.
• sqflite, SQLite'a doğrudan erişim sağlar; Drift, bunun üzerine kod üretimiyle tip güvenli bir katman ekler (Bölüm 5 Konu 21'de öğrendiğimiz code generation kalıbı).
• Seçim, verinin karmaşıklığına, ilişkisel olup olmadığına ve sorgu ihtiyaçlarına göre yapılmalıdır.

#📝 Ödevler

• [ ] shared_preferences ile bir kullanıcı tercihini (örn. tema seçimi) kaydet, uygulamayı kapatıp yeniden açtığında (hot restart ile test edilebilir) hatırlandığını doğrula.
• [ ] Hive kurup basit bir "not" nesnesini (başlık + içerik) bir box'a kaydet, okuyup ekranda listele.
• [ ] sqflite ile basit bir tablo oluştur, birkaç kayıt ekle, query() ile hepsini çek ve listele.
• [ ] Üç yaklaşımı da (shared_preferences, Hive, sqflite) kullanarak aynı basit veriyi (örn. bir isim listesi) saklayıp okuyan üç ayrı küçük örnek yaz, hangi durumda hangisini seçeceğine karar ver.
• [ ] Kendi cümlelerinle, "neden bazı veriler için basit anahtar-değer depolama yeterli değil, SQL veritabanı gerekiyor" sorusunu, ilişkisel veri kavramıyla açıkla.

#🏁 Bölüm 5 Tamamlandı!

Asenkron dünya ve veri yönetimini tamamladık: FutureBuilder, StreamBuilder, HTTP istekleri, JSON serialization ve yerel depolama. Artık uygulamanı gerçek bir API'ye bağlayabiliyor, veriyi tip güvenli modellere dönüştürebiliyor ve kalıcı olarak saklayabiliyorsun — bu, gerçek dünya uygulamalarının omurgasını oluşturan bir bilgi birikimi.

Sıradaki durak Bölüm 6 — State Management: Şimdiye kadar sadece setState() kullandık, ama uygulaman büyüdükçe bu yetersiz kalmaya başlar. InheritedWidget'ın temellerinden, Provider ve Riverpod gibi modern çözümlere kadar, büyük uygulamalarda state'i nasıl yöneteceğini öğreneceksin.

Bölüm 6'ya hoş geldin — Flutter'ın en çok tartışılan konusuna giriyoruz. Bu derste, Bölüm 4 Konu 16 ve 17'de "bunu Bölüm 8'de (o zaman Bölüm 8 olarak planlanmıştı, şimdi Bölüm 6) tam göreceğiz" dediğimiz Theme.of(context)/MediaQuery.of(context) mekanizmasının gerçek işleyişini açıklayacağız.

#Sorun: setState() Sadece "Yerel"dir

Bölüm 2 Konu 6'da öğrendiğimiz setState(), sadece o widget'ın kendi State'ini günceller. Peki, birbirinden uzak iki widget'ın aynı veriyi paylaşması gerekiyorsa (örneğin bir "sepet" state'i, hem ürün listesi ekranında hem sepet ikonu göstergesinde)?

class UstEkran extends StatefulWidget {
  @override
  State<UstEkran> createState() => _UstEkranState();
}

class _UstEkranState extends State<UstEkran> {
  int _sepetSayisi = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        UrunListesi(), // burada bir ürün eklendiğinde _sepetSayisi'nı artırmak istiyoruz
        SepetIkonu(sayi: _sepetSayisi), // burada bu sayıyı GÖSTERMEK istiyoruz
      ],
    );
  }
}

UrunListesi ve SepetIkonu, kardeş widget'lardır (aynı ebeveynin çocukları) — birbirlerinin State'ine doğrudan erişemezler. Naif bir çözüm, tüm veriyi en üstteki widget'ta tutup, her seviyede elle parametre olarak aşağı aktarmaktır ("prop drilling" — çok yaygın bir problem).

// ❌ "Prop drilling" — veri, her seviyeden elle geçirilmek zorunda
UrunListesi(sepeteEkle: (urun) { setState(() { _sepetSayisi++; }); })

Küçük ağaçlarda bu çalışır, ama widget ağacı derinleştikçe (5-6 seviye), her ara widget'ın, kendisiyle hiç ilgisi olmayan bir veriyi sadece "aşağı aktarmak için" parametre olarak taşıması gerekir — bu, Bölüm 3 Konu 13'te öğrendiğimiz "tek sorumluluk" prensibini ihlal eder.

#InheritedWidget — Widget Ağacı Boyunca Veri "Yayınlama"

class SepetSaglayici extends InheritedWidget {
  final int sepetSayisi;
  final Widget child;

  const SepetSaglayici({
    super.key,
    required this.sepetSayisi,
    required this.child,
  }) : super(child: child);

  static SepetSaglayici? of(BuildContext context) {
    return context.dependOnInheritedWidgetOfExactType<SepetSaglayici>();
  }

  @override
  bool updateShouldNotify(SepetSaglayici oldWidget) {
    return sepetSayisi != oldWidget.sepetSayisi;
  }
}

InheritedWidget, Dart Bölüm 7'de öğrendiğimiz extends ile türetilen özel bir widget türüdür — Bölüm 2 Konu 5'te öğrendiğimiz normal widget'lardan farklı bir amaca hizmet eder: kendi altındaki (descendant) tüm widget'lara, ağaç boyunca "elle taşımadan" veri erişimi sağlamak.

Parça parça inceleyelim:

1. static SepetSaglayici? of(BuildContext context) — Bu, Theme.of(context)/MediaQuery.of(context)'in tam olarak nasıl çalıştığını gösteriyor! Bölüm 6 Konu 16'da "bu, InheritedWidget'a dayanır" demiştik — işte gerçek mekanizma bu: context.dependOnInheritedWidgetOfExactType<T>(), widget ağacında yukarı doğru giderek, en yakın SepetSaglayici'yi bulur.

2. updateShouldNotify(...) — Dart Bölüm 7'de öğrendiğimiz override edilen bir metod. Bu, "veri değiştiğinde, bana bağımlı olan widget'ları yeniden çizmeli miyim?" sorusunun cevabıdır. sepetSayisi != oldWidget.sepetSayisi, Dart Bölüm 3'te öğrendiğimiz != karşılaştırma operatörüyle, eski ve yeni değeri kıyaslıyor.

#Nasıl Kullanılır?

class UstEkran extends StatefulWidget {
  @override
  State<UstEkran> createState() => _UstEkranState();
}

class _UstEkranState extends State<UstEkran> {
  int _sepetSayisi = 0;

  void _sepeteEkle() {
    setState(() {
      _sepetSayisi++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return SepetSaglayici(
      sepetSayisi: _sepetSayisi,
      child: Column(
        children: [
          ElevatedButton(onPressed: _sepeteEkle, child: Text('Sepete Ekle')),
          SepetIkonu(), // artık parametre almasına GEREK YOK
        ],
      ),
    );
  }
}

class SepetIkonu extends StatelessWidget {
  const SepetIkonu({super.key});

  @override
  Widget build(BuildContext context) {
    final sepetSaglayici = SepetSaglayici.of(context)!; // context'ten DOĞRUDAN erişim
    return Icon(Icons.shopping_cart);
    // (Gerçek uygulamada sepetSaglayici.sepetSayisi ile bir rozet gösterirdik)
  }
}

Kritik gözlem: SepetIkonu, artık _sepetSayisi'yi hiçbir parametre almadan, doğrudan SepetSaglayici.of(context) ile alıyor — Bölüm ağacında ne kadar derinde olursa olsun, context'i olan her widget, bu veriye erişebilir.

#dependOnInheritedWidgetOfExactType — Otomatik Rebuild Kaydı

Buradaki en önemli detay, sadece "veriye erişmek" değil — dependOnInheritedWidgetOfExactType<T>() çağrıldığında, Flutter, o widget'ı, bu InheritedWidget'a "bağımlı" olarak kaydeder. Bölüm 2 Konu 6'da öğrendiğimiz rebuild mekanizmasını hatırlarsan — SepetSaglayici'nin sepetSayisi'si değiştiğinde (ve updateShouldNotify true döndürdüğünde), bu veriye bağımlı olan HER widget otomatik olarak yeniden çizilir — sen elle setState() çağırmana gerek kalmadan!

Bu, Bölüm 4 Konu 16'da "Theme değiştiğinde, temayı kullanan her widget otomatik güncellenir" dediğimiz davranışın tam açıklamasıdır.

#InheritedModel — Seçici Güncelleme (İleri Bir Optimizasyon)

InheritedWidget'ın bir sınırlaması var: updateShouldNotify true döndürdüğünde, ona bağımlı OLAN HER widget yeniden çizilir — veri birden fazla alt-parça içeriyorsa (örneğin bir "kullanıcı profili" hem isim hem yaş içeriyorsa), sadece isim değiştiğinde bile, yaşı kullanan widget'lar da gereksiz yere yeniden çizilir.

class ProfilModeli extends InheritedModel<String> {
  final String isim;
  final int yas;
  // ...

  @override
  bool updateShouldNotifyDependent(ProfilModeli oldWidget, Set<String> dependencies) {
    if (dependencies.contains('isim') && isim != oldWidget.isim) return true;
    if (dependencies.contains('yas') && yas != oldWidget.yas) return true;
    return false;
  }
}

InheritedModel<T>, Dart Bölüm 9'da öğrendiğimiz generic sınırlamayı kullanarak (burada T = String, "hangi alana bağımlı olduğunu" bir string ile belirtiyoruz), sadece kullanılan alt-parçaya bağımlı widget'ların güncellenmesini sağlar — bu, Bölüm 9'da (performans) derinlemesine işleyeceğimiz bir optimizasyon tekniğidir. Pratikte, InheritedModel'i doğrudan elle yazman nadirdir — modern state management araçları (Provider, Riverpod) bu tarz optimizasyonları senin için halleder.

#Neden Bu Kadar Temel? — Provider/Riverpod'a Köprü

Önemli bir gerçek: Bölüm 6'nın ilerleyen konularında öğreneceğin Provider paketi, aslında arka planda InheritedWidget kullanır! Provider, InheritedWidget'ın kaynak kodunu elle yazma zahmetini ortadan kaldıran, üzerine inşa edilmiş kullanışlı bir katmandır. Bu, Bölüm 5 Konu 20'de dio'nun http'nin üzerine bir kolaylık katmanı olması gibi bir ilişki.

Bu dersi neden bu kadar derinlemesine işledik? Çünkü Provider/Riverpod'u "sihir" olarak değil, temelini anlayarak öğrenmen, ileride karşılaşacağın hataları çok daha kolay çözmeni sağlayacak — "neden bu widget güncellenmiyor" gibi sorularla karşılaştığında, artık arka planda InheritedWidget mekanizmasının nasıl çalıştığını bileceksin.

#🎯 Bu Dersten Çıkarılması Gerekenler

• setState(), sadece kendi State'ini günceller — kardeş/uzak widget'lar arasında veri paylaşmak için "prop drilling" gerekir, bu da tek sorumluluk prensibini ihlal eder.
• InheritedWidget, widget ağacı boyunca veri "yayınlamanın" temel Flutter mekanizmasıdır; of(context) static metodu, dependOnInheritedWidgetOfExactType ile en yakın örneği bulur.
• dependOnInheritedWidgetOfExactType, sadece veri okumakla kalmaz, o widget'ı otomatik rebuild'e kaydeder — veri değiştiğinde bağımlı widget'lar kendiliğinden güncellenir.
• Theme.of(context) ve MediaQuery.of(context), bu mekanizmanın gerçek kullanım örnekleridir.
• InheritedModel, seçici (sadece kullanılan alt-parçaya bağımlı) güncelleme sağlayan ileri bir optimizasyondur.
• Provider ve Riverpod gibi modern araçlar, arka planda InheritedWidget'ı kullanır — bu dersi anlamak, onları "sihir" olmaktan çıkarır.

#📝 Ödevler

• [ ] Sadece InheritedWidget kullanarak, iki farklı (kardeş) widget arasında paylaşılan bir sayaç state'i kur.
• [ ] updateShouldNotify'ı bilerek her zaman false döndürecek şekilde yaz, bağımlı widget'ların güncellenmediğini gözlemle; sonra doğru mantıkla düzelt.
• [ ] SepetSaglayici.of(context) çağrısını, InheritedWidget olmayan bir yerde (örn. hiç SepetSaglayici olmayan bir widget ağacında) yapmayı dene, null döndüğünü gözlemle (ve ! ile zorladığında hatayı gör).
• [ ] Kendi cümlelerinle, "Theme.of(context) çağrıldığında Flutter'ın arka planda ne yaptığını", bu derste öğrendiğin mekanizmayla açıkla.
• [ ] Kendi basit bir InheritedWidget'ını (örn. bir "kullanıcı adı" paylaşan) yaz, en az 3 seviye derinlikte bir widget'tan bu veriye eriş.

Sıradaki konu: Bölüm 6 — Konu 24: Provider Paketi

Bir önceki derste InheritedWidget'ı elle yazmanın ne kadar detaylı olduğunu gördük (of() metodu, updateShouldNotify, vb.). Provider, bu süreci büyük ölçüde basitleştiren, en popüler Flutter state management paketlerinden biridir.

#Paketi Ekleme

flutter pub add provider

#ChangeNotifier — State'i Tanımlama

import 'package:flutter/foundation.dart';

class SepetModeli extends ChangeNotifier {
  int _sepetSayisi = 0;
  int get sepetSayisi => _sepetSayisi; // Bölüm 6 Konu 30'u hatırla — getter ile salt-okunur erişim

  void urunEkle() {
    _sepetSayisi++;
    notifyListeners(); // "bana bağımlı olan herkese haber ver, güncellenin!"
  }
}

ChangeNotifier, Dart Bölüm 7'de öğrendiğimiz extends ile türetilen, Flutter'ın kendi kütüphanesinde tanımlı bir sınıftır (dart:core'da değil, flutter/foundation.dart'ta — Dart Bölüm 12'de öğrendiğimiz import mekanizmasını hatırla). Bu class, "beni dinleyen widget'lara değişiklik bildirebilme" yeteneğini sağlar.

notifyListeners() — bu, Bölüm 6 Konu 23'te öğrendiğimiz updateShouldNotify + otomatik rebuild mekanizmasının, senin elle yazmana gerek kalmadan çalışan halidir. _sepetSayisi değiştiğinde notifyListeners() çağırıyorsun, ve Provider, arka planda, bu değişikliği dinleyen tüm widget'ları günceller.

#ChangeNotifierProvider — State'i Widget Ağacına "Enjekte Etme"

void main() {
  runApp(
    ChangeNotifierProvider(
      create: (context) => SepetModeli(),
      child: MyApp(),
    ),
  );
}

ChangeNotifierProvider, Bölüm 6 Konu 23'te elle yazdığımız SepetSaglayici widget'ının hazır, genel amaçlı bir versiyonudur — create: parametresi (Dart Bölüm 3 Konu 11'de öğrendiğimiz builder pattern), state nesnesini bir kere oluşturur ve tüm alt ağaca "yayınlar."

#context.watch<T>() — Veriye Erişim ve Otomatik Rebuild

class SepetIkonu extends StatelessWidget {
  const SepetIkonu({super.key});

  @override
  Widget build(BuildContext context) {
    final sepet = context.watch<SepetModeli>(); // Dart Bölüm 9'u hatırla — generic!
    return Badge(
      label: Text('${sepet.sepetSayisi}'),
      child: Icon(Icons.shopping_cart),
    );
  }
}

context.watch<SepetModeli>() — Dart Bölüm 9'da öğrendiğimiz generic tip parametresi (<SepetModeli>), Provider'a hangi state'e erişmek istediğini söylüyor. Bu, arka planda tam olarak Bölüm 6 Konu 23'te öğrendiğimiz dependOnInheritedWidgetOfExactType<T>() çağrısını kullanır — Provider, aslında kendi içinde bir InheritedWidget sarmalıyor.

watch, "bu değeri izle, değiştiğinde beni otomatik olarak yeniden çiz" demektir — az önce öğrendiğimiz SepetIkonu, SepetModeli.urunEkle() çağrıldığında (ve notifyListeners() tetiklendiğinde), otomatik olarak yeniden çizilir.

#context.read<T>() — Sadece Erişim, Rebuild Tetiklemeden

ElevatedButton(
  onPressed: () {
    context.read<SepetModeli>().urunEkle(); // SADECE metod çağırmak için
  },
  child: Text('Sepete Ekle'),
)

read ile watch arasındaki kritik fark: watch, o widget'ı değişikliklere bağımlı yapar (her değişiklikte rebuild). read, sadece o anki değere/metoda erişim sağlar, rebuild tetiklemez. Bir onPressed callback'i içinde (Dart Bölüm 5'te öğrendiğimiz anonim fonksiyon), genelde read kullanılır — çünkü bir buton, sepet sayısı değiştiğinde kendisinin yeniden çizilmesine gerek yoktur, sadece metodu tetiklemek ister.

Yanlış kullanım örneği — performans sorunu yaratır:

// ❌ Kötü pratik — build() içinde watch kullanıp sadece bir metod çağırmak
onPressed: () {
  context.watch<SepetModeli>().urunEkle(); // ❌ HATA! watch, build() dışında kullanılamaz zaten
}

Aslında Provider, bu hatayı çalışma zamanında yakalar — watch, sadece build() metodunun içinde (rebuild mantığı gerektiren bağlamda) kullanılabilir.

#context.select<T, R>() — İnce Ayarlı İzleme (Bölüm 6 Konu 23'teki InheritedModel'in Pratik Karşılığı)

class SepetSayisiGostergesi extends StatelessWidget {
  const SepetSayisiGostergesi({super.key});

  @override
  Widget build(BuildContext context) {
    final sayi = context.select<SepetModeli, int>((model) => model.sepetSayisi);
    return Text('$sayi');
  }
}

Bölüm 6 Konu 23'te öğrendiğimiz InheritedModel'in "sadece kullanılan alt-parçaya bağımlı olma" optimizasyonunu hatırlarsan — select, tam olarak bunu Provider ile kolayca yapmanı sağlıyor. Eğer SepetModeli'nin başka bir alanı (örneğin bir indirimOrani) değişirse ama sepetSayisi değişmezse, select kullanan bu widget yeniden çizilmez — sadece sepetSayisi'ye gerçekten bağımlı olduğu için, gereksiz rebuild'lerden kaçınır.

#Birden Fazla Provider — MultiProvider

void main() {
  runApp(
    MultiProvider(
      providers: [
        ChangeNotifierProvider(create: (context) => SepetModeli()),
        ChangeNotifierProvider(create: (context) => KullaniciModeli()),
      ],
      child: MyApp(),
    ),
  );
}

MultiProvider, Dart Bölüm 4'te öğrendiğimiz List yapısını kullanarak (providers: [...]), birden fazla state kaynağını tek bir yerde tanımlamanı sağlar — gerçek uygulamalarda, genelde birden fazla ChangeNotifier (kullanıcı, sepet, ayarlar gibi) aynı anda yönetilir.

#Tam Bir Örnek

class SepetModeli extends ChangeNotifier {
  final List<String> _urunler = [];
  List<String> get urunler => List.unmodifiable(_urunler); // Dart Bölüm 4'ü hatırla!

  void ekle(String urun) {
    _urunler.add(urun);
    notifyListeners();
  }
}

class SepetEkrani extends StatelessWidget {
  const SepetEkrani({super.key});

  @override
  Widget build(BuildContext context) {
    final sepet = context.watch<SepetModeli>();
    return Scaffold(
      appBar: AppBar(title: Text('Sepetim (${sepet.urunler.length})')),
      body: ListView.builder(
        itemCount: sepet.urunler.length,
        itemBuilder: (context, index) => ListTile(title: Text(sepet.urunler[index])),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => context.read<SepetModeli>().ekle('Yeni Ürün ${sepet.urunler.length + 1}'),
        child: Icon(Icons.add),
      ),
    );
  }
}

List.unmodifiable(_urunler) — Dart Bölüm 4 Konu 16'yı hatırlıyor musun? Bu, dışarıya salt-okunur bir liste sunmanın yoludur — SepetModeli'nin dışındaki kod, urunler listesine doğrudan eleman ekleyemez, sadece ekle() metodu üzerinden, kontrollü bir şekilde değiştirebilir. Bu, Bölüm 6 Konu 30'da (Dart) öğrendiğimiz encapsulation prensibinin, state management'ta kritik bir uygulamasıdır.

#🎯 Bu Dersten Çıkarılması Gerekenler

• ChangeNotifier, notifyListeners() ile bağımlı widget'lara değişiklik bildiren bir sınıftır — InheritedWidget'ın elle yazılmasının otomatikleştirilmiş halidir.
• ChangeNotifierProvider/MultiProvider, state nesnelerini widget ağacına "enjekte eder."
• context.watch<T>(), veriye erişir VE değişince otomatik rebuild tetikler; context.read<T>(), sadece erişir, rebuild tetiklemez (genelde callback'lerde kullanılır).
• context.select<T, R>(), sadece belirli bir alt-alana bağımlı olarak, gereksiz rebuild'lerden kaçınmayı sağlar (InheritedModel'in pratik karşılığı).
• List.unmodifiable, state modelinin içindeki koleksiyonları dışarıya salt-okunur sunmanın, encapsulation'ı koruyan bir yoludur.

#📝 Ödevler

• [ ] ChangeNotifier'dan türeyen basit bir sayaç modeli yaz, ChangeNotifierProvider ile widget ağacına ekle.
• [ ] context.watch kullanan bir widget ile context.read kullanan bir buton yaz, aralarındaki davranış farkını (rebuild tetikleyip tetiklemediğini) gözlemle.
• [ ] context.select kullanarak, modelin sadece belirli bir alanına bağımlı bir widget yaz; modelin başka bir alanını değiştirip bu widget'ın rebuild olmadığını kanıtla.
• [ ] MultiProvider ile en az iki farklı ChangeNotifier modelini aynı anda yönet.
• [ ] Konu 24'teki "SepetEkrani" örneğine benzer, kendi basit bir alışveriş sepeti uygulaması yaz (ürün ekleme + liste gösterme).

Sıradaki konu: Bölüm 6 — Konu 25: Riverpod (Modern Yaklaşım, Provider'ın Halefi)

#Riverpod Neden Var? — Provider'ın Sınırlamaları

Bir önceki derste Provider'ı öğrendik — güçlü bir araç, ama BuildContext'e bağımlı olmasından kaynaklanan bazı sınırlamaları var:

// Provider ile — context olmadan state'e erişemezsin
context.read<SepetModeli>().ekle('Ürün');

Bu, widget ağacının dışında (örneğin bir initState() dışı yardımcı fonksiyonda, ya da tamamen widget olmayan bir test kodunda) state'e erişmeyi zorlaştırır. Ayrıca, Provider'da aynı tipte birden fazla provider tanımlamak (örneğin iki farklı SepetModeli — belki bir "geçici sepet", bir "onaylı sepet") karmaşıklaşır.

Riverpod, aynı ekip (Provider'ın da yaratıcısı) tarafından geliştirilen, bu sınırlamaları çözen bir sonraki nesil state management çözümüdür. Önemli: "Riverpod", Provider'ın harflerinin anagramıdır (P-R-O-V-I-D-E-R → R-I-V-E-R-P-O-D) — bu, paketin Provider'ın ruhani halefi olduğunu isim düzeyinde bile gösteriyor.

Bir uyarı: Riverpod, zaman içinde API'sini bir kez büyük ölçüde değiştirdi. İnternette veya eski kaynaklarda göreceğin StateNotifier + StateNotifierProvider kalıbı artık eski (legacy) kabul ediliyor — hâlâ çalışıyor ama Riverpod ekibi yeni projelerde bunun yerine Notifier + NotifierProvider kullanılmasını öneriyor. Bu derste doğrudan güncel kalıbı öğreneceğiz.

#Paketi Ekleme

flutter pub add flutter_riverpod

#ProviderScope — Uygulamayı Sarmalamak

void main() {
  runApp(
    ProviderScope( // tüm provider'ları barındıran kök widget
      child: MyApp(),
    ),
  );
}

ProviderScope, tüm provider'ları (Riverpod'da "provider" terimi biraz farklı kullanılır — birazdan göreceğiz) barındıran, context'e bağımlı olmayan bir depoyu (store) temsil eder. runApp()'ın en dışına, bir kere, uygulamanın kökünde konur.

#Provider (Riverpod'un Kendi Terimi) — Basit, Değişmeyen Değerler

final versiyonProvider = Provider<String>((ref) => '1.0.0');

Dart Bölüm 5 Konu 21'de öğrendiğimiz fonksiyonları değişkene atama kavramını hatırlarsan — burada Provider<String>(...), bir fonksiyon alıyor ((ref) => '1.0.0', bir anonim fonksiyon), ve bu, global bir değişken gibi tanımlanıyor. Ama dikkat: bu gerçek bir global değişken değil — Riverpod'un kendi izole edilmiş deposunda yaşıyor (Dart Bölüm 12'de öğrendiğimiz kütüphane/scope kavramına benzer bir izolasyon).

#Notifier — Değişebilir State'i Tanımlamanın Güncel Yolu

Provider dersinde ChangeNotifier ile notifyListeners() çağırarak state güncellemesi yapmıştık. Riverpod'un güncel karşılığı Notifier sınıfıdır:

import 'package:flutter_riverpod/flutter_riverpod.dart';

class SepetNotifier extends Notifier<int> {
  @override
  int build() => 0; // başlangıç state — StatefulWidget'taki initState gibi düşünebilirsin

  void ekle() {
    state = state + 1; // 'state' özel bir alan — atama otomatik olarak dinleyicileri günceller
  }
}

final sepetProvider = NotifierProvider<SepetNotifier, int>(SepetNotifier.new);

Notifier<int> — Dart Bölüm 9'da öğrendiğimiz generic sınıf kullanımı burada net görülüyor: <int>, bu notifier'ın hangi tipte state tuttuğunu belirtiyor.

build() metodu — eski yaklaşımdan temel fark: Eski StateNotifier API'sinde başlangıç değeri constructor'da (super(0)) veriliyordu. Güncel Notifier API'sinde, tıpkı bir widget'ın build() metodu gibi, build() metodu çağrılır ve döndürdüğü değer başlangıç state'i olur. Bu tasarım, Riverpod'un widget yaşam döngüsüyle tutarlı bir mantık kurmasını sağlıyor — provider'lar da widget'lar gibi "yeniden inşa edilebilir" (örneğin ref.invalidate() ile).

SepetNotifier.new — bu, Dart'ın constructor tear-off sözdizimi: (ref) => SepetNotifier() yazmak yerine, doğrudan constructor'a bir referans veriyoruz (fonksiyonu değişkene atama kavramının constructor'lara uygulanmış hali). İkisi de aynı işi yapar, .new biraz daha kısa ve idiomatik.

Kritik fark — notifyListeners() yerine state =: Provider'da notifyListeners()'ı elle çağırıyorduk (Bölüm 6 Konu 24'ü hatırla). Riverpod'da, state alanına atama yapmak, otomatik olarak dinleyicilere haber verir — bu, Dart Bölüm 6'da öğrendiğimiz setter kavramına benzer bir "gizli mekanizma" (Riverpod'un kendi Notifier sınıfı, arka planda bir setter/getter kullanır).

NotifierProvider<SepetNotifier, int> — burada iki generic tip parametresi var: SepetNotifier (notifier class'ının kendisi) ve int (tuttuğu state'in tipi). Dart Bölüm 9'da öğrendiğimiz "birden fazla tip parametresi" kavramının (Map<K, V> gibi) burada tekrar kullanıldığını görüyorsun.

#Widget İçinde Kullanım — ConsumerWidget

class SepetIkonu extends ConsumerWidget { // StatelessWidget YERİNE ConsumerWidget!
  const SepetIkonu({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) { // EK bir parametre: WidgetRef!
    final sepetSayisi = ref.watch(sepetProvider);
    return Badge(
      label: Text('$sepetSayisi'),
      child: Icon(Icons.shopping_cart),
    );
  }
}

ConsumerWidget — Bölüm 2 Konu 5'te öğrendiğimiz StatelessWidget'ın Riverpod'a özel bir versiyonudur (Dart Bölüm 7'de öğrendiğimiz kalıtım hiyerarşisini hatırla — ConsumerWidget, aslında StatelessWidget'a çok benzer bir işlev görür ama Riverpod'un ref mekanizmasını build()'e ekler).

WidgetRef ref — bu, Provider'daki context.watch<T>() çağrısının yerini alan bir mekanizma. ref.watch(sepetProvider), tıpkı context.watch<SepetModeli>() gibi çalışır — ama context'e bağımlı değildir, ref üzerinden çalışır.

#ref.read() — Callback'lerde Kullanım

ElevatedButton(
  onPressed: () {
    ref.read(sepetProvider.notifier).ekle(); // .notifier ile NOTIFIER'a erişim
  },
  child: Text('Sepete Ekle'),
)

sepetProvider.notifier — Riverpod'da, ref.watch(sepetProvider) sadece state değerini (int) verir; metodları çağırmak için, .notifier ile notifier nesnesinin kendisine erişmen gerekir. Bu, Bölüm 6 Konu 24'te öğrendiğimiz Provider'daki context.read<SepetModeli>().ekle()'nin, biraz daha açık (explicit) bir versiyonu.

#ConsumerStatefulWidget — StatefulWidget + Riverpod

class SepetEkrani extends ConsumerStatefulWidget {
  const SepetEkrani({super.key});

  @override
  ConsumerState<SepetEkrani> createState() => _SepetEkraniState();
}

class _SepetEkraniState extends ConsumerState<SepetEkrani> {
  @override
  void initState() {
    super.initState();
    // burada ref, this.ref üzerinden erişilebilir
  }

  @override
  Widget build(BuildContext context) {
    final sepetSayisi = ref.watch(sepetProvider); // ConsumerState içinde 'ref' otomatik mevcut
    return Text('$sepetSayisi');
  }
}

Bu, Bölüm 2 Konu 6'da öğrendiğimiz iki-sınıflı StatefulWidget yapısının, Riverpod'a özel versiyonudur (ConsumerStatefulWidget + ConsumerState) — initState() gibi yaşam döngüsü metodlarına ek olarak, ref'e de erişim sağlar.

#Bir Adım İleri — Code Generation (@riverpod)

Riverpod ekibinin resmi olarak önerdiği en güncel yaklaşım, provider'ları elle yazmak yerine riverpod_generator paketiyle otomatik ürettirmektir (Dart Bölüm 13 Konu 66'da öğrendiğimiz build_runner mekanizmasını hatırla):

import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'sepet_provider.g.dart';

@riverpod
class SepetNotifier extends _$SepetNotifier {
  @override
  int build() => 0;

  void ekle() {
    state = state + 1;
  }
}

Bu kod, dart run build_runner build çalıştırıldığında, yukarıda elle yazdığımız NotifierProvider tanımını senin için otomatik üretir (üstelik daha az kod ve daha güçlü tip çıkarımıyla). Bu tutorial'da öğrenmeye devam ettiğimiz elle yazılan Notifier/NotifierProvider kalıbı, arka planda tam olarak neyin üretildiğini anlaman için gerekli temel — code generation'ı, bu temeli kavradıktan sonra kullanmak çok daha mantıklı olur. Şimdilik elle yazma kalıbına odaklanmamız yeterli.

#Provider vs Riverpod — Karşılaştırma

#Pratik Tavsiye

Yeni başlayan biri için, Provider ile başlamak (kavramları öğrenmek için) makul bir yoldur — az önce gördüğün gibi, Riverpod'daki kavramlar (watch, read, notifier pattern) Provider'ınkilere çok benziyor. Ama büyük, uzun soluklu bir proje için, Riverpod'un sunduğu daha güçlü tip güvenliği ve context bağımsızlığı, uzun vadede daha sürdürülebilir bir seçimdir. Bu tutorial'ın ilerleyen kısımlarında (özellikle Bölüm 8'de, ileri state management pattern'lerinde), her ikisini de göreceğiz.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Riverpod, Provider'ın BuildContext bağımlılığını ortadan kaldıran, daha güçlü tip güvenliğine sahip bir sonraki nesil state management çözümüdür.
• ProviderScope, uygulamanın kökünde bir kere sarmalayıcı olarak kullanılır; NotifierProvider + Notifier<T>, güncel state yönetim kalıbıdır (eski kaynaklarda göreceğin StateNotifierProvider/StateNotifier artık legacy).
• build() metodu, başlangıç state'ini döndürür (eski API'deki super(0) çağrısının yerini aldı); state = ... ataması, Provider'daki notifyListeners() çağrısının otomatikleştirilmiş halidir.
• ConsumerWidget/ConsumerStatefulWidget, ref parametresi aracılığıyla, context.watch/context.read'in Riverpod karşılığı olan ref.watch/ref.read'i kullanır.
• .notifier, sadece state değerine değil, notifier'ın metodlarına erişmek için kullanılır.
• Riverpod ekibinin resmi önerisi artık @riverpod code generation'dır — bu tutorial'da elle yazma kalıbını öğrenmek, arkasındaki mekanizmayı anlaman için tercih edildi.

#📝 Ödevler

• [ ] Notifier<int> ile basit bir sayaç yaz, NotifierProvider ile tanımla, ConsumerWidget ile ekrana bağla.
• [ ] ref.watch ile değeri gösteren, ref.read(...).notifier ile bir metodu çağıran bir buton yaz.
• [ ] ConsumerStatefulWidget kullanarak, initState() içinde bir işlem yapan (örn. bir başlangıç değeri ayarlayan) bir widget yaz.
• [ ] Aynı basit sepet uygulamasını (Bölüm 6 Konu 24'teki), bu sefer Provider yerine Riverpod ile yeniden yaz, iki yaklaşımı karşılaştır.
• [ ] Kendi cümlelerinle, "Riverpod'un BuildContext'e bağımlı olmaması neden değerli" sorusunu açıkla.

Sıradaki konu: Bölüm 6 — Konu 26: BLoC/Cubit Pattern (flutter_bloc)

#BLoC Nedir? — Felsefi Farkı Anlama

Şimdiye kadar gördüğümüz Provider ve Riverpod, "state'i tut ve değişince haber ver" felsefesiyle çalışıyordu. BLoC (Business Logic Component), biraz daha katı ve yapılandırılmış bir felsefeye sahiptir: "her state değişikliği, açıkça tanımlanmış bir 'olay' (event) sonucunda gerçekleşmelidir."

Bu, Dart Bölüm 13 Konu 61'de öğrendiğimiz event loop kavramına isim olarak benzese de, farklı bir şey — burada "event", kullanıcı eyleminin veya iş mantığı tetikleyicisinin açık bir temsilidir.

#Cubit — BLoC'un Basitleştirilmiş Hali

BLoC ekosisteminde, önce daha basit olan Cubit'i öğrenmek mantıklıdır — Cubit, tam BLoC pattern'inin event katmanı olmayan bir versiyonudur.

flutter pub add flutter_bloc

import 'package:flutter_bloc/flutter_bloc.dart';

class SepetCubit extends Cubit<int> { // Dart Bölüm 9'u hatırla - generic!
  SepetCubit() : super(0); // başlangıç state'i: 0

  void ekle() {
    emit(state + 1); // "yeni bir state yayınla" — Riverpod'daki 'state =' ile BENZER
  }

  void azalt() {
    if (state > 0) emit(state - 1);
  }
}

Cubit<int> — Bölüm 6 Konu 25'te öğrendiğimiz Riverpod'un Notifier<int>'ine kavramsal olarak çok benzer — ikisi de generic (Dart Bölüm 9), ikisi de bir state kavramına sahip. emit(...), Riverpod'daki state = ... atamasının biraz daha açık (explicit) halidir — "yeni bir state değerini dünyaya yayınla" anlamına geliyor.

#Widget İçinde Kullanım — BlocProvider ve BlocBuilder

void main() {
  runApp(
    BlocProvider(
      create: (context) => SepetCubit(),
      child: MyApp(),
    ),
  );
}

BlocProvider, Bölüm 6 Konu 24'te öğrendiğimiz ChangeNotifierProvider'a yapısal olarak çok benziyor — create: ile (Dart Bölüm 3 Konu 11'deki builder pattern) bir Cubit/Bloc oluşturup widget ağacına "enjekte ediyor."

class SepetIkonu extends StatelessWidget {
  const SepetIkonu({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocBuilder<SepetCubit, int>(
      builder: (context, sepetSayisi) {
        return Badge(
          label: Text('$sepetSayisi'),
          child: Icon(Icons.shopping_cart),
        );
      },
    );
  }
}

BlocBuilder<SepetCubit, int> — burada da Dart Bölüm 9'da öğrendiğimiz birden fazla generic tip parametresi kullanılıyor: SepetCubit (hangi Cubit'i dinleyeceği), int (state'in tipi). builder: fonksiyonu, Bölüm 5 Konu 18-19'da öğrendiğimiz FutureBuilder/StreamBuilder'ın builder pattern'ine çok benzer — context ve o anki state değeri parametre olarak veriliyor, state her emit() edildiğinde bu fonksiyon otomatik olarak yeniden çağrılıyor.

#Cubit'in Metoduna Erişim — context.read

ElevatedButton(
  onPressed: () {
    context.read<SepetCubit>().ekle(); // Provider'daki context.read ile AYNI sözdizimi!
  },
  child: Text('Sepete Ekle'),
)

flutter_bloc, Provider ile aynı context.read<T>()/context.watch<T>() sözdizimini kullanır (çünkü flutter_bloc, aslında arka planda provider paketini kullanır — bu, Dart Bölüm 12'de öğrendiğimiz paket bağımlılıklarının gerçek bir örneği). Bu, üç state management aracının (Provider, Riverpod, BLoC) birbirinden tamamen kopuk olmadığını, aksine ortak temellere (InheritedWidget) dayandığını gösteriyor.

#Tam BLoC Pattern — Events ile

Cubit'ten bir adım öteye geçersek, tam BLoC pattern, state değişikliklerini event class'ları aracılığıyla tetikler — bu, Dart Bölüm 13 Konu 59'da öğrendiğimiz sealed class + pattern matching kavramının mükemmel bir kullanım alanıdır.

sealed class SepetEvent {}
class UrunEklendi extends SepetEvent {
  final String urunAdi;
  UrunEklendi(this.urunAdi);
}
class SepetTemizlendi extends SepetEvent {}

class SepetBloc extends Bloc<SepetEvent, List<String>> {
  SepetBloc() : super([]) {
    on<UrunEklendi>((event, emit) {
      emit([...state, event.urunAdi]); // Dart Bölüm 4'ü hatırla — spread operatörü!
    });
    on<SepetTemizlendi>((event, emit) {
      emit([]);
    });
  }
}

Bloc<SepetEvent, List<String>> — iki generic parametre: gelen event tipi (SepetEvent, sealed class) ve state tipi (List<String>). on<UrunEklendi>((event, emit) { ... }), "bu tür bir event geldiğinde, şu işlemi yap" demenin yolu — Dart Bölüm 13 Konu 59'da öğrendiğimiz sealed class ile exhaustive kontrolün, bir event-driven mimaride nasıl doğal bir şekilde kullanılabileceğini gösteriyor.

emit([...state, event.urunAdi]) — Dart Bölüm 4 Konu 20'de öğrendiğimiz spread operatörü! Var olan state listesini kopyalayıp (immutability korunuyor — yeni bir liste oluşturuluyor, var olan liste değiştirilmiyor), yeni ürünü ekliyoruz.

Kullanım:

context.read<SepetBloc>().add(UrunEklendi('Kalem'));

#Cubit mi, Tam BLoC mi?

Pratik tavsiye: flutter_bloc paketini kullanan projelerin çoğu, aslında Cubit ile başlar — tam BLoC pattern'in event-driven karmaşıklığı, genelde büyük, kurumsal projelerde (birden fazla geliştiricinin, "bu state neden değişti" sorusunu kod okumadan anlaması gerektiğinde) değerli hale gelir.

#Üç Aracı Karşılaştıralım — Bölüm 6'nın Özeti

#🎯 Bu Dersten Çıkarılması Gerekenler

• Cubit<T>, BLoC ekosisteminin basitleştirilmiş hali — emit(...) ile yeni state yayınlanır.
• BlocProvider/BlocBuilder, Provider'ın ChangeNotifierProvider/context.watch'ına yapısal olarak benzer; flutter_bloc arka planda provider paketini kullanır.
• Tam BLoC pattern, state değişikliklerini event class'ları (genelde sealed class ile) aracılığıyla tetikler — her değişikliğin "nedenini" açıkça izlenebilir kılar.
• Cubit, hızlı geliştirme için; tam BLoC, büyük takımlarda denetlenebilirlik gerektiğinde tercih edilir.
• Provider, Riverpod ve BLoC, hepsi temelde InheritedWidget mekanizmasına dayanır — farklı "arayüzler" sunan, ortak bir temele sahip araçlardır.

#📝 Ödevler

• [ ] Cubit<int> ile basit bir sayaç yaz, BlocProvider/BlocBuilder ile ekrana bağla.
• [ ] Sealed class ile event'ler tanımlayan tam bir Bloc yaz (en az 2 farklı event tipiyle), on<EventTipi> ile her birini işle.
• [ ] context.read<T>().add(Event()) ile bir event tetikle, state'in doğru güncellendiğini gözlemle.
• [ ] Aynı basit sepet uygulamasını (önceki derslerdeki), bu sefer Cubit ile yeniden yaz.
• [ ] Kendi cümlelerinle, Provider/Riverpod/Cubit arasındaki temel felsefe farkını (basit bildirim vs event-driven) özetleyen bir tablo/not hazırla.

Sıradaki konu: Bölüm 6 — Konu 27: GetX (Tartışmalı Ama Yaygın)

#GetX Nedir?

GetX, sadece bir state management çözümü değil — state management + navigasyon + dependency injection'ı tek bir pakette birleştiren, "hepsi bir arada" (all-in-one) bir framework'tür. Bu ders başlığındaki "tartışmalı" ifadesi bilinçli — GetX, Flutter topluluğunda hem çok sevilen hem de eleştirilen bir araçtır. Bu dersi, dengeli bir bakış açısıyla işleyeceğiz.

#Paketi Ekleme

flutter pub add get

#Temel Kullanım — GetxController

import 'package:get/get.dart';

class SepetController extends GetxController {
  var sepetSayisi = 0.obs; // '.obs' — GetX'e özgü "observable" yapma

  void ekle() {
    sepetSayisi++; // reaktif — otomatik olarak dinleyicileri günceller
  }
}

.obs — bu, GetX'in en dikkat çekici özelliklerinden biri. Dart Bölüm 6'da öğrendiğimiz normal bir değişken (var sepetSayisi = 0), .obs eklendiğinde "reaktif" (observable) bir değişkene dönüşür — arka planda, GetX bu değeri özel bir wrapper class'a (RxInt) sarmalar. sepetSayisi++ yazdığında, bu otomatik olarak dinleyicilere haber verir — Bölüm 6 Konu 24'te öğrendiğimiz notifyListeners()'ı elle çağırmana bile gerek kalmıyor.

#Widget İçinde Kullanım — Obx

final controller = Get.put(SepetController());

class SepetIkonu extends StatelessWidget {
  const SepetIkonu({super.key});

  @override
  Widget build(BuildContext context) {
    return Obx(() => Badge(
      label: Text('${controller.sepetSayisi}'),
      child: Icon(Icons.shopping_cart),
    ));
  }
}

Get.put(SepetController()) — bu, Bölüm 6 Konu 23-26'da öğrendiğimiz Provider/ChangeNotifierProvider gibi bir "enjeksiyon" mekanizmasının çok daha basit bir versiyonudur — BuildContext'e hiç ihtiyaç duymadan, controller'ı bir global registry'e (kayıt defterine) ekler.

Obx(() => ...) — Dart Bölüm 5'te öğrendiğimiz anonim fonksiyon parametre alıyor (tıpkı builder pattern'lerinde olduğu gibi). Obx, içindeki widget ağacının hangi .obs değişkenlere bağımlı olduğunu otomatik olarak tespit eder ve sadece onlar değiştiğinde yeniden çizer — sen BlocBuilder<T, S> veya context.watch<T>() gibi açıkça hangi tipi izleyeceğini belirtmene bile gerek yok.

#context Olmadan Her Şey — GetX'in İddiası

// Navigasyon - context OLMADAN!
Get.to(DetayEkrani());

// SnackBar - context OLMADAN!
Get.snackbar('Başlık', 'Mesaj');

// Controller'a HERHANGİ bir yerden erişim - context OLMADAN!
Get.find<SepetController>().ekle();

Bu, GetX'in en çok tartışılan özelliğidir — Bölüm 3 Konu 14'te öğrendiğimiz Navigator.push(context, ...)'u hatırlarsan, GetX bunu tamamen context'siz hale getiriyor. Bu, hem bir kolaylık hem de bir eleştiri kaynağıdır — şimdi her iki tarafı da görelim.

#Neden Bazı Geliştiriciler GetX'i Seviyor?

1. Çok az "boilerplate" (tekrarlayan kod) — Bölüm 6 Konu 24-26'da gördüğümüz Provider/Riverpod/BLoC'un BlocBuilder, ConsumerWidget, StateNotifierProvider gibi yapısal gerekliliklerine kıyasla, GetX çok daha az kod ile aynı işi yapar.
2. Öğrenme eğrisi düşük — .obs ve Obx mantığı, sezgisel ve hızlı öğrenilir.
3. Hepsi bir arada — navigasyon, state management, dependency injection, hatta yerelleştirme (localization) tek pakette.
4. context bağımsızlığı — Bölüm 6 Konu 25'te Riverpod'un bu avantajını övmüştük; GetX bunu daha da ileri götürür.

#Neden Bazı Geliştiriciler GetX'e Eleştiri Getiriyor?

1. Flutter'ın "resmi" felsefesinden sapma — Bölüm 1 Konu 1'de öğrendiğimiz Widget/Element/RenderObject mimarisi, BuildContext'i merkezi bir kavram olarak tasarlamıştır (Bölüm 6 Konu 23'te öğrendiğimiz InheritedWidget de context'e dayanır). GetX'in context'i tamamen atlaması, bazı Flutter'a özgü mekanizmalarla (tema, lokalizasyon context'e bağlı çalışan sistemler) sürtüşme yaratabilir.
2. Global state riski — Get.put()/Get.find(), aslında global, erişilebilir her yerden bir kayıt defteri oluşturur. Bu, Dart Bölüm 6'da öğrendiğimiz encapsulation (kapsülleme) prensibini zayıflatabilir — herhangi bir widget, uygulamanın herhangi bir controller'ına, hiçbir kısıtlama olmadan erişebilir, bu da büyük projelerde kodun akışını takip etmeyi zorlaştırabilir.
3. "Sihirli" davranış — Obx'in hangi değişkenlere bağımlı olduğunu otomatik tespit etmesi, Bölüm 6 Konu 24'te öğrendiğimiz context.select<T, R>()'in açık (explicit) yaklaşımına kıyasla, bazen beklenmedik rebuild davranışlarına yol açabilir — çünkü ne zaman, neyin tetiklediği her zaman net olmayabilir.
4. Test edilebilirlik — Get.find() gibi global erişimler, Riverpod'un (Bölüm 6 Konu 25) övdüğümüz "kolay test edilebilirlik" avantajına göre daha zor test edilebilir bir yapı oluşturabilir (bağımlılıkları "mock"lamak/sahtelemek daha karmaşık hale gelir).

#Dengeli Bir Sonuç

Bu, kesin bir "doğru" veya "yanlış" cevabı olmayan bir tartışma — Flutter topluluğu bu konuda bölünmüştür. Bazı büyük, başarılı uygulamalar GetX ile yazılmıştır; bazı büyük takımlar ise bilinçli olarak GetX'ten kaçınır, Provider/Riverpod/BLoC'u tercih eder.

Pratik gözlem noktaları:

• Küçük-orta projeler, hızlı prototipleme: GetX'in hızı ve azlığı avantaj olabilir.
• Büyük, uzun soluklu, çok geliştiricili projeler: GetX'in "her şeye her yerden erişim" esnekliği, disiplin gerektirebilir — bazı takımlar bunu riskli bulur.
• Flutter'ın kendi ekosistemiyle (resmi paketler, dokümantasyon) uyum: Provider/Riverpod, Flutter ekibinin kendi önerdiği desenlere (InheritedWidget tabanlı) daha yakındır.

#🎯 Bu Dersten Çıkarılması Gerekenler

• GetX, state management + navigasyon + dependency injection'ı tek pakette birleştiren, "hepsi bir arada" bir framework'tür.
• .obs, bir değişkeni reaktif (observable) yapar; Obx, hangi değişkenlere bağımlı olduğunu otomatik tespit eden bir widget'tır.
• Get.put()/Get.find(), BuildContext'e hiç ihtiyaç duymadan, global bir kayıt defteri üzerinden state'e erişim sağlar.
• GetX, hızı ve azlığı (boilerplate azlığı) nedeniyle sevilirken; global state riski, Flutter'ın context-merkezli felsefesinden sapması ve test edilebilirlik zorlukları nedeniyle eleştirilir.
• Bu, topluluğun bölündüğü bir konudur — kesin bir doğru cevap yoktur, proje büyüklüğüne ve takım tercihine göre değişir.

#📝 Ödevler

• [ ] .obs ve Obx kullanarak basit bir sayaç yaz, Get.put()/Get.find() ile controller'a farklı widget'lardan eriş.
• [ ] Get.to() ile context kullanmadan bir ekran geçişi yap, Navigator.push(context, ...) ile karşılaştır.
• [ ] Kendi cümlelerinle, GetX'in "context bağımsızlığının" hem avantajını hem potansiyel riskini (encapsulation zayıflığı bağlamında) açıkla.
• [ ] Provider, Riverpod, BLoC ve GetX'i, "ne zaman hangisini seçerdim" perspektifiyle karşılaştıran kısa bir kişisel not yaz.
• [ ] Flutter topluluğunda GetX hakkındaki tartışmayı (güncel görüşleri) kısaca araştır, kendi görüşünü oluştur.

Sıradaki konu: Bölüm 6 — Konu 28: Karşılaştırma — Hangi Projede Hangisi? (Bölüm 6'nın Son Konusu)

Bölüm 6'nın son konusundayız. Bu ders, yeni bir kavram öğretmiyor — Konu 23-27'de öğrendiğin her şeyi birleştirip, gerçek bir karar verme çerçevesi sunuyor.

#Hepsinin Ortak Temeli — Kısa Bir Hatırlatma

Bölüm 6 Konu 23'te öğrendiğimiz gibi, hepsi aynı temel mekanizmaya dayanıyor: InheritedWidget. Fark, bu mekanizmanın **üzerine hangi "arayüzün" (API) inşa edildiğidir:

InheritedWidget (Flutter'ın çekirdek mekanizması)
     │
     ├── Provider (elle InheritedWidget yazmanın kolaylaştırılmış hali)
     │      │
     │      └── flutter_bloc (Provider'ı arka planda kullanır)
     │
     ├── Riverpod (context bağımsız, daha tip güvenli bir yeniden tasarım)
     │
     └── GetX (kendi global registry sistemi, context'i tamamen atlar)

#Karşılaştırma Tablosu — Tüm Kriterler Bir Arada

#Proje Büyüklüğüne Göre Karar Rehberi

#Küçük Proje / Öğrenme Amaçlı / Hızlı Prototip

Öneri: Provider veya GetX

Bölüm 6 Konu 24'te öğrendiğimiz Provider, az kavramla (watch/read/select) hızlı sonuç verir. GetX (Konu 27), daha da az kod ile benzer bir hız sunar. Bu aşamada, mimari kaygılardan çok, öğrenmeye ve hızlı iterasyona odaklanmak mantıklıdır.

#Orta Ölçekli Proje / Bireysel Geliştirici / Küçük Takım

Öneri: Riverpod

Bölüm 6 Konu 25'te öğrendiğimiz gibi, Riverpod'un context bağımsızlığı ve derleme zamanı güvenliği, projenin büyümesiyle birlikte daha az hata anlamına gelir. Provider'a çok benzer bir zihniyetle çalıştığı için, geçiş kolaydır.

#Büyük Ölçekli Proje / Çok Geliştiricili Takım / Kurumsal Uygulama

Öneri: Riverpod veya Tam BLoC

Bölüm 6 Konu 26'da öğrendiğimiz tam BLoC pattern'in event-driven yapısı, birden fazla geliştiricinin "bu state neden değişti" sorusunu, kod tabanının herhangi bir yerinden anlayabilmesini sağlar — bu, büyük takım koordinasyonu için değerlidir. Riverpod da, tip güvenliği ve test edilebilirliği sayesinde bu ölçekte gayet iyi çalışır.

#GetX Ne Zaman Mantıklı?

Bölüm 6 Konu 27'de dengeli bir şekilde işlediğimiz gibi, GetX'in hız avantajı, küçük-orta ölçekli, tek geliştiricili veya küçük takımlı projelerde değerlidir. Büyük, uzun soluklu projelerde, disiplinli kullanılmazsa (global state'in kontrolsüz büyümesi), bakım zorlaşabilir — bu yüzden büyük kurumsal projelerde daha az tercih edilir.

#Karar Verirken Sorman Gereken Sorular

1. Kaç kişi bu kod üzerinde çalışacak? Tek başınaysan, esneklik önceliklidir. Takım büyüdükçe, yapı ve öngörülebilirlik daha değerli hale gelir.
2. Proje ne kadar uzun soluklu? Kısa ömürlü bir MVP/prototip için, hız öncelikli. Yıllarca sürecek bir uygulama için, sürdürülebilirlik öncelikli.
3. Test yazmayı ne kadar önemsiyorsun? Dart Bölüm 12 Konu 55'te öğrendiğimiz unit test kültürü güçlüyse, Riverpod/BLoC'un test edilebilirlik avantajı öne çıkar.
4. Ekibin önceden bir deneyimi var mı? Zaten bir ekip Provider veya BLoC biliyorsa, tutarlılık için aynı aracı kullanmak genelde en mantıklısıdır — "en iyi" araç yerine "ekibin bildiği" araç, pratikte genelde kazanır.

#Bu Tutorial'da Bundan Sonra Ne Kullanacağız?

Flutter tutorial'ının ilerleyen bölümlerinde (özellikle Bölüm 7'de mimari konularında, ve daha ileri projelerde), genellikle Provider veya Riverpod örnekleri kullanacağız — çünkü bunlar, Flutter ekibinin resmi dokümantasyonunda en çok referans verilen, ve Bölüm 6 Konu 23'te öğrendiğimiz temel InheritedWidget mekanizmasına en yakın duran araçlardır. Ama artık hepsinin temel mantığını bildiğin için, hangi projede hangisiyle karşılaşırsan karşılaş, hızlıca adapte olabileceksin.

#Değişmeyen Gerçek — Hangisini Seçersen Seç

Bölüm 6'nın tamamında öğrendiğimiz en önemli ders, aslında araçların kendisinden bağımsız:

• Dart Bölüm 6'da öğrendiğimiz encapsulation (state'i private tutup, kontrollü metodlarla değiştirme) her zaman önemlidir — hangi aracı kullanırsan kullan.
• Dart Bölüm 4'te öğrendiğimiz immutable koleksiyonlar (List.unmodifiable gibi), state'in dışarıdan kontrolsüzce değiştirilmesini önlemede her zaman değerlidir.
• Bölüm 2 Konu 6'da öğrendiğimiz setState()'in temel rebuild mekanizması, hangi state management aracını kullanırsan kullan, arka planda hâlâ çalışıyor — bu araçlar, setState()'in yerini almaz, onu daha organize bir şekilde tetiklemenin yollarını sunar.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Provider, Riverpod, BLoC ve GetX, hepsi temelde InheritedWidget'a dayanır, farklı "arayüzler" sunarlar.
• Küçük/prototip projeler için Provider veya GetX; orta ölçek için Riverpod; büyük, çok geliştiricili projeler için Riverpod veya tam BLoC genelde tercih edilir.
• Karar verirken: takım büyüklüğü, projenin ömrü, test kültürü ve ekibin önceki deneyimi göz önünde bulundurulmalıdır.
• Hangi aracı seçersen seç, temel prensipler (encapsulation, immutability, setState()'in arka planda çalışan rebuild mekanizması) değişmez.

#📝 Ödevler

• [ ] Kendi hayalindeki bir proje fikri düşün (örn. bir not alma uygulaması), yukarıdaki karar rehberine göre hangi state management aracını seçeceğine karar ver ve gerekçelendir.
• [ ] Aynı basit uygulamayı (örn. sayaç), Bölüm 6'da öğrendiğin 4 araçtan (Provider, Riverpod, Cubit, GetX) en az ikisiyle yazıp, kod miktarı ve okunabilirlik açısından karşılaştır.
• [ ] Kendi cümlelerinle, "state management aracı seçmek, setState()'in yerini almak değil, onu organize etmenin bir yoludur" cümlesini açıkla.
• [ ] Bir arkadaşına (ya da kendine), hangi durumda hangi aracı önereceğini anlatan kısa bir "karar ağacı" (flowchart tarzı, metin olarak da olabilir) yaz.

#🏁 Bölüm 6 Tamamlandı!

State management'ın temellerini (InheritedWidget) ve dört büyük çözümünü (Provider, Riverpod, BLoC/Cubit, GetX) öğrendin — artık hem neden bu araçlara ihtiyaç duyulduğunu hem de her birinin nasıl çalıştığını biliyorsun, ve projene göre bilinçli bir seçim yapabiliyorsun.

Sıradaki durak Bölüm 7 — İleri Navigasyon & Mimari: Navigator 2.0, go_router, deep linking, repository pattern, dependency injection ve Clean Architecture ile, büyük, sürdürülebilir uygulamalar kurmayı öğreneceğiz.

Bölüm 7'ye hoş geldin. Bu ders, Flutter'ın en karmaşık konularından birine giriyor — dürüst olmak gerekirse, bu dersten sonra öğreneceğin go_router paketi, günlük geliştirmede çok daha sık kullanacağın araç olacak. Ama Navigator 2.0'ın temel mantığını anlamak, go_router'ın neden var olduğunu ve nasıl çalıştığını kavraman için değerli.

#Navigator 1.0'ın Sınırlaması — Neden Navigator 2.0 Var?

Bölüm 3 Konu 14'te öğrendiğimiz Navigator.push()/pop() (buna "Navigator 1.0" denir), zorunlu (imperative) bir yaklaşımdır — sen adım adım, "şimdi şu ekrana git" diyorsun. Bu, basit uygulamalarda gayet iyi çalışır, ama şu senaryolarda zayıf kalır:

1. Web'de URL senkronizasyonu — Bir web tarayıcısında, kullanıcı geri/ileri tuşlarını kullandığında, ya da doğrudan bir URL'ye giriş yaptığında, uygulamanın doğru ekranı göstermesi gerekir. Navigator 1.0'ın "adım adım push/pop" mantığı, bunu doğal olarak desteklemez.
2. Deep linking — Bir bildirime tıklandığında, uygulamayı doğrudan belirli bir ekrana (örneğin bir ürün detayına) açmak, Navigator 1.0'da karmaşık, elle yönetilen bir süreç gerektirir.

Navigator 2.0, bunun yerine bildirimsel (declarative) bir yaklaşım sunar — Dart Bölüm 13 Konu 59'da öğrendiğimiz pattern matching'in felsefesine benzer bir mantık: "şu anki durum bu, Flutter sen anla nasıl gösterileceğini."

#Üç Ana Bileşen

Navigator 2.0, üç ana parçadan oluşur — bunları kavramsal olarak anlayalım (elle tam bir implementasyon yazmak, gerçekten nadiren gerekir, go_router bunu senin için yapar).

#1. RouteInformationParser — URL'yi "Anlamlı Veriye" Çevirme

class UygulamaRotaAyristirici extends RouteInformationParser<UygulamaRotaKonfigurasyonu> {
  @override
  Future<UygulamaRotaKonfigurasyonu> parseRouteInformation(RouteInformation routeInformation) async {
    final uri = routeInformation.uri;
    if (uri.pathSegments.isEmpty) {
      return UygulamaRotaKonfigurasyonu.anaSayfa();
    }
    if (uri.pathSegments[0] == 'urun') {
      final id = uri.pathSegments[1];
      return UygulamaRotaKonfigurasyonu.urunDetay(id);
    }
    return UygulamaRotaKonfigurasyonu.bilinmeyen();
  }
}

Bu, Dart Bölüm 7'de öğrendiğimiz extends ile Flutter'ın kendi soyut sınıfından (Bölüm 7 Konu 34'ü hatırla — soyut sınıflar bir "sözleşme" tanımlar) türetilmiş bir class. Görevi, bir URL string'ini (/urun/123 gibi), uygulamanın anlayacağı bir Dart nesnesine (UygulamaRotaKonfigurasyonu) çevirmek — tıpkı Bölüm 5 Konu 21'de öğrendiğimiz fromJson()'un, JSON'u bir Dart nesnesine çevirmesi gibi bir dönüşüm işlemi.

#2. RouterDelegate — "Şu Anki Duruma Göre Hangi Ekranları Göstermeli?"

class UygulamaRouterDelegate extends RouterDelegate<UygulamaRotaKonfigurasyonu>
    with ChangeNotifier { // Dart Bölüm 7'de öğrendiğimiz MIXIN, Bölüm 6'da gördüğümüz ChangeNotifier!

  UygulamaRotaKonfigurasyonu _konfigurasyon = UygulamaRotaKonfigurasyonu.anaSayfa();

  @override
  Widget build(BuildContext context) {
    return Navigator(
      pages: [
        MaterialPage(child: AnaEkran()),
        if (_konfigurasyon.urunId != null)
          MaterialPage(child: UrunDetayEkrani(id: _konfigurasyon.urunId!)),
      ],
      onDidRemovePage: (page) {
        _konfigurasyon = UygulamaRotaKonfigurasyonu.anaSayfa();
        notifyListeners();
      },
    );
  }
  // ... diğer zorunlu metodlar
}

Çok önemli bir gözlem: with ChangeNotifier — Bölüm 6 Konu 24'te öğrendiğimiz ChangeNotifier, burada state management dışında, navigasyon durumunu yönetmek için de kullanılıyor! Bu, Bölüm 7 Konu 36'da (Dart) öğrendiğimiz mixin'in gerçek bir Flutter kullanımı.

pages: [...] — Bu, Navigator 1.0'ın "push/pop" mantığından temel bir sapma: burada sen, "o anki state'e göre hangi sayfaların yığında (stack) olması gerektiğini" bir liste olarak bildiriyorsun — Dart Bölüm 4'te öğrendiğimiz List<Widget> (burada List<Page>) mantığı. Flutter, bu listeyi önceki listeyle karşılaştırıp (Bölüm 1 Konu 1'de öğrendiğimiz diffing mekanizmasına benzer), hangi sayfaların eklenip/çıkarılacağına kendisi karar verir.

#3. MaterialApp.router — Hepsini Birleştirme

MaterialApp.router(
  routerDelegate: UygulamaRouterDelegate(),
  routeInformationParser: UygulamaRotaAyristirici(),
)

Bölüm 3 Konu 10'da öğrendiğimiz MaterialApp(home: ...) yerine, MaterialApp.router(...) — Dart Bölüm 6 Konu 27'de öğrendiğimiz named constructor kalıbının, Flutter'ın kendi framework'ünde gerçek bir kullanımı! MaterialApp.router, MaterialApp'in navigasyonu Navigator 2.0'a devreden alternatif bir oluşturma yoludur.

#Neden Bu Kadar Karmaşık Görünüyor?

Bu üç bileşeni elle yazmak, dürüst olmak gerekirse, çok fazla "boilerplate" (tekrarlayan, zorunlu) kod gerektirir — zorunlu metodları implemente etmek, state senkronizasyonunu elle yönetmek gibi. Bu tam olarak Bölüm 7 Konu 30'da öğreneceğin go_router'ın var olma sebebidir — go_router, Navigator 2.0'ın gücünü (bildirimsel navigasyon, web URL desteği, deep linking) korurken, bu karmaşıklığı büyük ölçüde gizler.

#Navigator 1.0 vs Navigator 2.0 — Ne Zaman Hangisi?

Pratik gerçek: Bugün, Navigator 2.0'ı tamamen elle yazan geliştirici nadirdir — bunun yerine, hemen herkes go_router (veya benzer bir paket) kullanır. Bu dersin amacı, go_router'ı kullanırken "arka planda ne oluyor" sorusuna cevap verebilmen ve karşılaştığın hataları (özellikle web/deep linking ile ilgili) daha derinlemesine anlayabilmendir.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Navigator 1.0, zorunlu (imperative) "adım adım" navigasyon sunar; web URL senkronizasyonu ve deep linking'de zayıf kalır.
• Navigator 2.0, bildirimsel (declarative) bir yaklaşımla, "o anki state'e göre hangi sayfalar gösterilmeli" mantığıyla çalışır.
• RouteInformationParser, bir URL'yi anlamlı bir Dart nesnesine çevirir; RouterDelegate, bu nesneye göre hangi sayfaların gösterileceğine karar verir ve ChangeNotifier mixin'ini kullanır.
• MaterialApp.router, bu ikisini birleştiren named constructor'dır.
• Navigator 2.0'ı elle yazmak yoğun boilerplate gerektirir — pratikte neredeyse herkes go_router gibi bir paket kullanır (bir sonraki dersimiz).

#📝 Ödevler

• [ ] Kendi cümlelerinle, "Navigator 1.0'ın push/pop mantığı ile Navigator 2.0'ın bildirimsel yaklaşımı arasındaki temel felsefe farkını" açıkla.
• [ ] RouteInformationParser'ın görevini, Dart'ta öğrendiğimiz fromJson() kalıbıyla karşılaştırarak açıkla.
• [ ] RouterDelegate'in neden ChangeNotifier kullandığını, Bölüm 6'da öğrendiğin state management bilgisiyle ilişkilendir.
• [ ] Basit bir RouteInformationParser taslağı yaz (en az 2 farklı URL yolu ayrıştıran), çalıştırmana gerek yok, sadece mantığı pratik et.
• [ ] Kendi cümlelerinle, "neden pratikte çoğu geliştirici Navigator 2.0'ı elle yazmak yerine go_router kullanıyor" sorusuna cevap ver.

Sıradaki konu: Bölüm 7 — Konu 30: go_router Paketi (Pratik ve Modern Çözüm)

Bir önceki derste Navigator 2.0'ın ham gücünü ve karmaşıklığını gördük. go_router, bu gücü çok daha basit bir API arkasına gizleyen, Flutter ekibinin resmi olarak önerdiği bir pakettir (flutter.dev paketleri arasında "Flutter Favorite" işaretlidir).

#Paketi Ekleme

flutter pub add go_router

#Temel Kurulum — Bildirimsel Rota Tanımlama

import 'package:go_router/go_router.dart';

final _router = GoRouter(
  routes: [
    GoRoute(
      path: '/',
      builder: (context, state) => AnaEkran(),
    ),
    GoRoute(
      path: '/urun/:id',
      builder: (context, state) {
        final id = state.pathParameters['id']!;
        return UrunDetayEkrani(urunId: id);
      },
    ),
  ],
);

void main() {
  runApp(MaterialApp.router(
    routerConfig: _router,
  ));
}

Dikkat et — bu ne kadar tanıdık! routes: [...], Dart Bölüm 4'te öğrendiğimiz List yapısı; her GoRoute, Bölüm 3 Konu 14'te öğrendiğimiz Named Routes'daki Map<String, WidgetBuilder> mantığına çok benzer, ama çok daha güçlü özelliklerle (dinamik parametreler, iç içe rotalar) genişletilmiş.

builder: (context, state) => ... — Bölüm 3 Konu 11'de öğrendiğimiz builder pattern'in bir başka örneği. state, o anki rota hakkında bilgi taşır (URL parametreleri, sorgu parametreleri gibi).

#Dinamik Parametreler — :id Sözdizimi

GoRoute(
  path: '/urun/:id',
  builder: (context, state) {
    final id = state.pathParameters['id']!;
    return UrunDetayEkrani(urunId: id);
  },
)

:id, URL'nin değişken bir parçası olduğunu belirtir — /urun/123 veya /urun/abc gibi, herhangi bir değer bu yolla eşleşir. state.pathParameters['id'], Dart Bölüm 4'te öğrendiğimiz Map<String, String> erişimidir (Bölüm 3 Konu 14'te arguments'ı as String ile cast etmek zorunda kaldığımızı hatırlarsan — burada pathParameters, zaten String tipinde geliyor, bu daha temiz bir tip güvenliği).

#Ekranlar Arası Geçiş — context.go() ve context.push()

ElevatedButton(
  onPressed: () {
    context.go('/urun/123'); // mevcut yığını DEĞİŞTİRİR
  },
  child: Text('Ürüne Git'),
)

ElevatedButton(
  onPressed: () {
    context.push('/urun/123'); // yığına EKLER (Navigator.push'a benzer)
  },
  child: Text('Ürüne Git'),
)

go() ile push() arasındaki fark: go(), Bölüm 3 Konu 14'te öğrendiğimiz stack (yığın) kavramını hatırlarsan, mevcut yığını tamamen yeni bir rotayla değiştirir (web'de "adres çubuğuna URL yazmak" gibi düşün). push(), geleneksel Navigator 1.0'ın push'una daha yakın davranır — yığına ekler, geri tuşuyla önceki ekrana dönülebilir.

#Sorgu Parametreleri (Query Parameters)

context.go('/arama?q=laptop&kategori=elektronik');

GoRoute(
  path: '/arama',
  builder: (context, state) {
    final sorgu = state.uri.queryParameters['q'];
    final kategori = state.uri.queryParameters['kategori'];
    return AramaSonuclari(sorgu: sorgu, kategori: kategori);
  },
)

state.uri.queryParameters, yine Map<String, String> — web tarayıcılarında gördüğün ?q=laptop&kategori=elektronik tarzı URL'lerin doğal Flutter karşılığı.

#İç İçe Rotalar (Nested Routes) — Alt Navigasyon

GoRoute(
  path: '/urunler',
  builder: (context, state) => UrunlerEkrani(),
  routes: [ // İÇ İÇE rotalar
    GoRoute(
      path: ':id', // tam yolu: /urunler/:id
      builder: (context, state) {
        final id = state.pathParameters['id']!;
        return UrunDetayEkrani(urunId: id);
      },
    ),
  ],
)

Bu, Dart Bölüm 4'te öğrendiğimiz iç içe koleksiyon yapılarına benzer bir hiyerarşi — routes: içinde başka routes: tanımlayarak, URL yapısını ağaç şeklinde organize edebilirsin (/urunler/:id, /urunler/:id/yorumlar gibi).

#Named Routes — go_router'da Daha Güvenli Bir Versiyon

GoRoute(
  path: '/urun/:id',
  name: 'urun-detay', // bir İSİM veriyoruz
  builder: (context, state) => UrunDetayEkrani(urunId: state.pathParameters['id']!),
)

context.goNamed('urun-detay', pathParameters: {'id': '123'});

Bu, Bölüm 3 Konu 14'te öğrendiğimiz Named Routes'un go_router versiyonudur — URL string'ini elle yazmak yerine (yazım hatası riski), isimle ve tip güvenli parametrelerle rotaya gidiyorsun.

#Yönlendirme (Redirect) — Giriş Kontrolü Örneği

final _router = GoRouter(
  redirect: (context, state) {
    final girisYapildiMi = false; // gerçek uygulamada bir state'ten gelir (Bölüm 6'yı hatırla)
    final girisSayfasindaMi = state.matchedLocation == '/giris';

    if (!girisYapildiMi && !girisSayfasindaMi) {
      return '/giris'; // giriş yapılmamışsa, giriş ekranına yönlendir
    }
    return null; // null = yönlendirme yok, olduğu gibi devam
  },
  routes: [...],
);

redirect, Dart Bölüm 5'te öğrendiğimiz anonim fonksiyondur — her navigasyon denemesinde çalışır ve null (yönlendirme yok) veya bir String (yeni hedef yol) döndürür. Bu, gerçek uygulamalarda "giriş yapılmadan belirli ekranlara erişilemez" gibi kuralları merkezi bir yerde uygulamanın standart yoludur.

#go_router, Bölüm 7 Konu 29'daki Karmaşıklığı Nasıl Gizliyor?

go_router, arka planda tam olarak bir önceki derste öğrendiğimiz RouteInformationParser ve RouterDelegate'i kendi içinde implemente eder — sen bunları görmüyorsun bile, sadece GoRoute listesi tanımlıyorsun. Bu, Bölüm 5 Konu 20'de dio'nun http'nin üzerine, veya Bölüm 6 Konu 24'te Provider'ın InheritedWidget'ın üzerine inşa edilmesiyle aynı mühendislik deseni — karmaşık, güçlü bir temeli, basit bir arayüz arkasında sunmak.

#🎯 Bu Dersten Çıkarılması Gerekenler

• go_router, Navigator 2.0'ın gücünü, GoRoute listesi ile bildirimsel ve basit bir API arkasında sunar.
• :parametre sözdizimi, dinamik URL parçalarını yakalar; state.pathParameters/state.uri.queryParameters, tip güvenli erişim sağlar.
• context.go(), yığını değiştirir; context.push(), yığına ekler (Navigator 1.0'a benzer).
• İç içe routes:, URL yapısını ağaç şeklinde organize etmeyi sağlar.
• redirect, merkezi navigasyon kurallarını (örn. giriş kontrolü) uygulamanın standart yoludur.

#📝 Ödevler

• [ ] go_router ile en az 3 route'lu (ana sayfa, liste, detay) bir navigasyon yapısı kur.
• [ ] Dinamik bir parametre (:id) içeren bir route yaz, context.go() ile farklı ID'lerle test et.
• [ ] Bir arama ekranı için sorgu parametreleri (?q=...) kullan, state.uri.queryParameters ile oku.
• [ ] İç içe route'lar (nested routes) kullanarak, en az 2 seviyeli bir URL yapısı (/urunler/:id) kur.
• [ ] redirect kullanarak basit bir "giriş yapılmadan erişilemez" kontrolü ekle (sabit bir bool değişkenle test edebilirsin).

#🎮 Mini Uygulama — Deep-Linkable Ürün Kataloğu

Bölüm 7'de öğrendiğin navigasyon bilgisini pekiştiren bir mini proje:

Gereksinimler:

• go_router ile en az 4 route: ana sayfa, ürün listesi, ürün detayı (:id ile), ve bir "hakkında" sayfası.
• Ürün listesinden bir ürüne tıklandığında, context.go() ile detay sayfasına geç.
• Detay sayfasında bir "geri" butonu ile ana listeye dön.
• Bir arama kutusu ekle, context.go('/urunler?q=...') ile sorgu parametresiyle listeyi filtrele (gerçek filtreleme mantığı basit olabilir — örn. sadece parametreyi ekranda gösterebilirsin).
• Bonus: redirect ile, sahte bir "bakım modu" bayrağı true olduğunda tüm rotaları bir "bakımdayız" ekranına yönlendir.

Sıradaki konu: Bölüm 7 — Konu 31: Deep Linking

#Deep Linking Nedir?

Deep linking, uygulamanın dışından (bir web sitesi, bir push bildirimi, başka bir uygulama) gelen bir bağlantının, uygulamayı doğrudan belirli bir ekrana açmasıdır. Bölüm 7 Konu 29-30'da öğrendiğimiz bildirimsel navigasyon (go_router), bu özelliği temelde destekleyecek şekilde tasarlanmıştır — şimdi bunu gerçekten etkinleştirmeyi öğreneceğiz.

Somut örnekler:

• Bir e-posta bildiriminde "Siparişini Görüntüle" bağlantısına tıklandığında, uygulama doğrudan o siparişin detay ekranını açar.
• Bir arkadaşın paylaştığı bir ürün linkine tıklandığında, uygulama o ürünün sayfasında açılır.
• Bir web sayfasında "Uygulamada Aç" butonuna basıldığında, cihazda kurulu olan uygulama doğrudan ilgili içerikle açılır.

#İki Temel Deep Link Türü

#1. Custom URL Scheme (Özel URL Şeması)

myapp://urun/123

Bu, https:// yerine kendi tanımladığın bir "şema" (myapp://) kullanır. Basit ve eski bir yöntemdir, ama sınırlamaları vardır — eğer uygulama kurulu değilse, tarayıcı genelde hata verir (çünkü myapp:// diye bir protokolü tanımaz).

#2. Universal Links (iOS) / App Links (Android)

https://benimuygulamam.com/urun/123

Bu, gerçek bir HTTPS URL'sidir — eğer uygulama kuruluysa, işletim sistemi bunu otomatik olarak uygulamada açar; kurulu değilse, normal bir web sayfası olarak tarayıcıda açılır (bu web sayfası, App Store/Play Store'a yönlendirebilir). Bu, modern ve önerilen yaklaşımdır.

#Flutter'da Kurulum — Kavramsal Bakış

Deep linking'in platform tarafı kurulumu (Android/iOS native yapılandırması), Bölüm 1 Konu 3'te öğrendiğimiz android/ ve ios/ klasörlerinde yapılır — bunlar, günlük geliştirmede nadiren dokunduğumuz ama var olduğunu bildiğimiz klasörlerdi, hatırlarsan.

Android tarafında (android/app/src/main/AndroidManifest.xml):

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="https" android:host="benimuygulamam.com" />
</intent-filter>

iOS tarafında (ios/Runner/Info.plist ve Apple Developer hesabı ayarları):

• Associated Domains yapılandırması gerekir.

Bu native yapılandırmaların detaylarına girmiyoruz (bu, platform-spesifik bir konu ve resmi Flutter dokümantasyonunda güncel adımlarla takip edilmelidir) — önemli olan kavramsal olarak ne yaptıklarını anlamak: işletim sistemine, "bu domain'den gelen linkleri, benim uygulamamla aç" diye bildiriyorsun.

#go_router ile Deep Link'i Karşılama

Bölüm 7 Konu 30'da kurduğumuz GoRoute yapısı, aslında deep linking için zaten hazırdır:

final _router = GoRouter(
  routes: [
    GoRoute(path: '/', builder: (context, state) => AnaEkran()),
    GoRoute(
      path: '/urun/:id',
      builder: (context, state) => UrunDetayEkrani(urunId: state.pathParameters['id']!),
    ),
  ],
);

Eğer bir kullanıcı, https://benimuygulamam.com/urun/123 linkine tıklarsa (native yapılandırma doğru yapıldığında), işletim sistemi uygulamayı bu URL bilgisiyle başlatır, ve go_router, Bölüm 7 Konu 29'da öğrendiğimiz RouteInformationParser mekanizmasını (arka planda, senin görmeden) kullanarak, bu URL'yi doğrudan /urun/:id rotasıyla eşleştirip, UrunDetayEkrani'ni açar. Sen hiçbir ek kod yazmadan, sadece rotanı tanımlayarak, deep linking desteğine sahip oluyorsun — bu, go_router'ın en büyük pratik avantajlarından biridir.

#Uygulama Çalışırken Gelen Bir Deep Link — Dinleme

Uygulama zaten açıkken bir deep link tetiklenirse (örneğin başka bir uygulamadan paylaşılan bir link), bunu dinlemek için app_links gibi bir paket kullanılabilir:

flutter pub add app_links

import 'package:app_links/app_links.dart';

class DeepLinkDinleyici {
  final _appLinks = AppLinks();

  void dinlemeyeBasla(GoRouter router) {
    _appLinks.uriLinkStream.listen((uri) { // Dart Bölüm 10'u hatırla — Stream!
      router.go(uri.path);
    });
  }
}

uriLinkStream — Dart Bölüm 10 Konu 47'de öğrendiğimiz Stream kavramının gerçek bir kullanım alanı! Uygulama açıkken gelen her yeni deep link, bu stream'e bir "olay" olarak akar — .listen() ile (Dart Bölüm 10'u hatırla), her yeni link geldiğinde router.go(uri.path) ile anlık olarak o ekrana geçiş yapılır.

#Deep Linking + State Management — Bölüm 6'ya Bağlantı

Gerçek bir uygulamada, deep link ile açılan bir ekran, genelde belirli bir veriye ihtiyaç duyar (örneğin ürün detayı için, o ürünün bilgisini bir API'den çekmek gerekir — Bölüm 5'i hatırla). Bu, Bölüm 6'da öğrendiğimiz state management araçlarıyla doğal olarak birleşir:

GoRoute(
  path: '/urun/:id',
  builder: (context, state) {
    final id = state.pathParameters['id']!;
    return UrunDetayEkrani(urunId: id); // bu widget içinde, Bölüm 5'teki FutureBuilder ile veri çekilir
  },
)

UrunDetayEkrani, Bölüm 5 Konu 20-21'de öğrendiğimiz gibi, initState() içinde id'yi kullanarak API'den veri çeker — deep link ile açılmış olması, bu akışı hiç değiştirmez, çünkü go_router, sadece doğru widget'ı doğru parametrelerle oluşturmaktan sorumludur.

#URL Stratejisi — Web'de "#" (Hash) mi, Yoksa "Path" mi?

Flutter Web'de, varsayılan olarak URL'ler # (hash) içerir:

https://benimuygulamam.com/#/urun/123

Bunu, daha temiz bir URL'ye çevirmek istersen:

void main() {
  usePathUrlStrategy(); // go_router'dan gelen bir fonksiyon
  runApp(MyApp());
}

https://benimuygulamam.com/urun/123

usePathUrlStrategy(), tarayıcının native History API'sini kullanarak, # olmadan temiz URL'ler üretir. Bu, özellikle SEO (arama motoru optimizasyonu) ve paylaşılabilirlik açısından önemlidir — ama sunucu tarafında ek bir yapılandırma (tüm yolları index.html'e yönlendirmek) gerektirir, çünkü artık sunucunun /urun/123 gibi bir yolu doğrudan tanıması beklenir.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Deep linking, uygulama dışından gelen bir bağlantının, doğrudan belirli bir ekranı açmasıdır.
• Universal Links/App Links (gerçek HTTPS URL'leri), eski Custom URL Scheme'lere göre daha modern ve güvenilir bir yaklaşımdır.
• go_router'ın GoRoute yapısı, ek kod yazmadan deep linking'i doğal olarak destekler — arka planda RouteInformationParser'ı kullanır.
• Uygulama çalışırken gelen deep link'ler, Stream tabanlı bir dinleyici (örn. app_links paketi) ile yakalanabilir.
• usePathUrlStrategy(), Flutter Web'de #'siz, temiz URL'ler üretir (sunucu tarafı ek yapılandırma gerektirir).

#📝 Ödevler

• [ ] Kendi cümlelerinle, Custom URL Scheme ile Universal/App Links arasındaki farkı ve neden ikincisinin tercih edildiğini açıkla.
• [ ] Bölüm 7 Konu 30'da kurduğun go_router yapısının, ek kod yazmadan neden deep linking'e "hazır" olduğunu açıkla.
• [ ] app_links paketiyle (veya kavramsal olarak, Stream mantığını kullanarak), uygulama açıkken gelen bir deep link'i dinleyen bir kod taslağı yaz.
• [ ] usePathUrlStrategy()'nin ne işe yaradığını ve neden sunucu tarafında ek yapılandırma gerektirdiğini kendi cümlelerinle açıkla.
• [ ] Kendi uygulaman için (hayali bir senaryo), hangi ekranların deep link ile açılabilir olması gerektiğini listele (örn. ürün detayı, profil, bir kampanya sayfası).

Sıradaki konu: Bölüm 7 — Konu 32: Repository Pattern, Katmanlı Mimari (Data/Domain/Presentation)

#Sorun: Her Şey Karışık Olunca Ne Olur?

Bölüm 5'te öğrendiğimiz HTTP istekleri, JSON serialization ve yerel depolamayı hatırlarsan — eğer bir widget'ın build() metodu içinde, doğrudan http.get(...) çağırıp, jsonDecode yapıp, Hive'a kaydediyorsan, bu kod hızla karmaşıklaşır ve test edilmesi, değiştirilmesi zorlaşır. Bu ders, bu karmaşıklığı düzenli katmanlara ayırmayı öğretiyor.

#Katmanlı Mimari — Üç Temel Katman

Presentation (Sunum) → Domain (İş Mantığı) → Data (Veri)
     Widget'lar         İş kuralları          API/DB erişimi

Her katmanın tek bir sorumluluğu vardır — bu, Bölüm 3 Konu 13'te öğrendiğimiz "tek sorumluluk" prensibinin, tüm uygulama mimarisine uygulanmış hali.

#Data Katmanı — Ham Veriye Erişim

// data/urun_veri_kaynagi.dart
class UrunVeriKaynagi {
  final http.Client _client;
  UrunVeriKaynagi(this._client);

  Future<List<Map<String, dynamic>>> urunleriGetir() async {
    final response = await _client.get(Uri.parse('https://api.ornek.com/urunler'));
    return List<Map<String, dynamic>>.from(jsonDecode(response.body));
  }
}

Bu katman, Bölüm 5 Konu 20'de öğrendiğimiz http paketi kullanımını doğrudan barındırır — sadece "veriyi nereden alıyoruz" sorusuyla ilgilenir, hiçbir iş mantığı içermez.

#Repository — Data Katmanının "Soyutlanmış Arayüzü"

// domain/urun_repository.dart
abstract class UrunRepository { // Dart Bölüm 7 Konu 34'ü hatırla — soyut sınıf!
  Future<List<Urun>> urunleriGetir();
}

// data/urun_repository_impl.dart
class UrunRepositoryImpl implements UrunRepository { // Dart Bölüm 7 Konu 35'i hatırla — implements!
  final UrunVeriKaynagi _veriKaynagi;
  UrunRepositoryImpl(this._veriKaynagi);

  @override
  Future<List<Urun>> urunleriGetir() async {
    final hamVeri = await _veriKaynagi.urunleriGetir();
    return hamVeri.map((json) => Urun.fromJson(json)).toList(); // Bölüm 5 Konu 21'i hatırla!
  }
}

Bu, Dart Bölüm 7'de öğrendiğimiz abstract class + implements kavramının en klasik gerçek dünya kullanımıdır! UrunRepository, bir "sözleşme" tanımlıyor ("bir yerden ürün listesi getirebilmeliyim"), UrunRepositoryImpl ise bunu HTTP API'den getirerek implemente ediyor.

Neden bu ayrım değerli? Dart Bölüm 8'de (Flutter müfredatı, test yazımı konusunda) göreceğimiz gibi, UrunRepository soyut olduğu için, testlerde sahte (mock/fake) bir implementasyon kullanabilirsin — gerçek bir API çağrısı yapmadan, UrunRepository'nin sözleşmesine uyan herhangi bir sahte class'ı test amaçlı kullanabilirsin. Bu, Bölüm 7 Konu 35'te (Dart) öğrendiğimiz "implements, sadece sözleşmeyi devralır" prensibinin, test edilebilirlik açısından pratik değerini gösteriyor.

#Domain Katmanı — İş Mantığı (Use Case'ler)

// domain/indirimli_urunleri_getir_usecase.dart
class IndirimliUrunleriGetirUseCase {
  final UrunRepository _repository;
  IndirimliUrunleriGetirUseCase(this._repository);

  Future<List<Urun>> call() async {
    final tumUrunler = await _repository.urunleriGetir();
    return tumUrunler.where((urun) => urun.indirimdeMi).toList(); // Dart Bölüm 11'i hatırla!
  }
}

"Use Case" (kullanım senaryosu), tek bir iş mantığı işlemini temsil eden bir class'tır — burada "indirimli ürünleri getir" gibi. Dart Bölüm 11'de öğrendiğimiz .where() metodu, burada iş mantığının (hangi ürünler "indirimli" sayılır) repository'den (veri erişiminden) ayrı tutulduğunu gösteriyor — repository, "tüm ürünleri getir" diyor; use case, "bunlardan hangileri indirimli" kararını veriyor.

#Presentation Katmanı — Widget'lar + State Management

// presentation/urun_listesi_ekrani.dart
class UrunListesiEkrani extends ConsumerWidget { // Bölüm 6 Konu 25'i hatırla — Riverpod!
  const UrunListesiEkrani({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final urunlerAsync = ref.watch(indirimliUrunlerProvider);

    return Scaffold(
      appBar: AppBar(title: Text('İndirimli Ürünler')),
      body: urunlerAsync.when(
        data: (urunler) => ListView.builder(
          itemCount: urunler.length,
          itemBuilder: (context, index) => ListTile(title: Text(urunler[index].ad)),
        ),
        loading: () => CircularProgressIndicator(),
        error: (err, stack) => Text('Hata: $err'),
      ),
    );
  }
}

Bu katman, sadece görüntüleme ile ilgilenir — Bölüm 3'te öğrendiğimiz ListView.builder, Bölüm 6'da öğrendiğimiz Riverpod entegrasyonu burada bir araya geliyor, ama hiçbir HTTP çağrısı veya iş mantığı içermiyor — bunlar alt katmanlara devredilmiş durumda.

#Neden Bu Kadar Katman? — Somut Faydalar

1. Test edilebilirlik: Her katman bağımsız olarak test edilebilir. Use case'i test etmek için, gerçek bir API'ye ihtiyacın yok — sahte bir UrunRepository (Dart Bölüm 7'de öğrendiğimiz implements ile) yeterli.

2. Değişime dayanıklılık: Yarın, veri kaynağını API'den Hive'a (Bölüm 5 Konu 22'yi hatırla) değiştirmen gerekirse, sadece UrunRepositoryImpl'i değiştirirsin — Domain ve Presentation katmanları hiç etkilenmez, çünkü onlar sadece soyut UrunRepository sözleşmesiyle çalışıyor.

3. Paralel geliştirme: Bir takım üyesi UI (Presentation) üzerinde çalışırken, başka biri API entegrasyonu (Data) üzerinde çalışabilir — aradaki soyut sözleşme (Repository), bu iki çalışmanın birbirini beklemeden ilerlemesini sağlar.

#Klasör Yapısı — Gerçek Bir Proje Organizasyonu

lib/
  data/
    urun_veri_kaynagi.dart
    urun_repository_impl.dart
  domain/
    urun.dart                    (model)
    urun_repository.dart         (soyut sözleşme)
    indirimli_urunleri_getir_usecase.dart
  presentation/
    urun_listesi_ekrani.dart
    urun_karti_widget.dart

Bu, Bölüm 1 Konu 3'te ve Bölüm 3 Konu 13'te öğrendiğimiz proje organizasyonu prensiplerinin, gerçek, ölçeklenebilir bir mimariye dönüşmüş halidir.

#Küçük Projelerde Gerekli mi?

Dürüst bir not: Bu kadar katmanlı bir yapı, küçük bir prototip veya öğrenme projesi için fazla mühendislik (over-engineering) olabilir. Bölüm 5'te yazdığımız basit örnekler (widget içinde doğrudan http.get çağırmak), küçük ölçekte tamamen makuldür. Bu mimari, uygulaman büyüdükçe, birden fazla ekran aynı veriyi kullandıkça, veya test yazma ihtiyacı arttıkça değer kazanır.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Katmanlı mimari, uygulamayı Data (veri erişimi), Domain (iş mantığı) ve Presentation (görüntüleme) olmak üzere ayırır.
• Repository pattern, abstract class + implements (Dart Bölüm 7) kullanarak, veri kaynağının soyut bir sözleşmesini tanımlar — gerçek implementasyon değiştirilebilir.
• Use Case'ler, tek bir iş mantığı işlemini kapsüller, repository'den bağımsız olarak iş kurallarını uygular.
• Bu ayrım, test edilebilirlik, değişime dayanıklılık ve paralel geliştirme açısından değer sağlar.
• Küçük projelerde bu kadar katman gereksiz karmaşıklık olabilir — büyüklüğe göre karar verilmelidir.

#📝 Ödevler

• [ ] Bölüm 5'te yazdığın bir API entegrasyonunu, data/domain/presentation katmanlarına ayırarak yeniden düzenle.
• [ ] abstract class ile bir Repository sözleşmesi tanımla, gerçek (HTTP) ve sahte (test amaçlı, sabit veri döndüren) iki farklı implementasyon yaz.
• [ ] Basit bir Use Case class'ı yaz (örn. "aktif kullanıcıları filtrele"), repository'den bağımsız bir iş kuralı uygula.
• [ ] Kendi cümlelerinle, "neden Repository'yi abstract class olarak tanımlıyoruz, doğrudan somut bir class yazmıyoruz" sorusunu, test edilebilirlik bağlamında açıkla.
• [ ] Küçük bir projede bu mimariyi kullanmanın ne zaman gerekli, ne zaman "aşırı mühendislik" olacağına dair kendi kriterlerini yaz.

Sıradaki konu: Bölüm 7 — Konu 33: Dependency Injection (get_it, injectable)

#Sorun: Nesneleri Nasıl "Bağlarız"?

Bir önceki derste, UrunRepositoryImpl'in bir UrunVeriKaynagi'na, IndirimliUrunleriGetirUseCase'in de bir UrunRepository'ye ihtiyaç duyduğunu gördük. Bunları kim, nerede, nasıl oluşturup birbirine bağlayacak?

// ❌ Her widget'ta elle oluşturmak — kod tekrarı, esneklik yok
class UrunListesiEkrani extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final veriKaynagi = UrunVeriKaynagi(http.Client());
    final repository = UrunRepositoryImpl(veriKaynagi);
    final useCase = IndirimliUrunleriGetirUseCase(repository);
    // ...
  }
}

Bu, her widget'ta tekrarlanan bir kurulum sürecidir — Bölüm 3 Konu 13'te öğrendiğimiz kod tekrarını önleme prensibini ihlal ediyor. Dependency Injection (bağımlılık enjeksiyonu), bu nesnelerin oluşturulmasını merkezi bir yerde yönetmenin ve ihtiyaç duyan yerlere "enjekte etmenin" yoludur.

#get_it — Basit Bir Servis Konumlandırıcı (Service Locator)

flutter pub add get_it

import 'package:get_it/get_it.dart';

final getIt = GetIt.instance; // Bölüm 6 Konu 27'de gördüğümüz singleton kalıbına benzer

void bagimliliklariKur() {
  getIt.registerLazySingleton<http.Client>(() => http.Client());
  getIt.registerLazySingleton<UrunVeriKaynagi>(() => UrunVeriKaynagi(getIt<http.Client>()));
  getIt.registerLazySingleton<UrunRepository>(() => UrunRepositoryImpl(getIt<UrunVeriKaynagi>()));
  getIt.registerFactory<IndirimliUrunleriGetirUseCase>(() => IndirimliUrunleriGetirUseCase(getIt<UrunRepository>()));
}

void main() {
  bagimliliklariKur();
  runApp(MyApp());
}

GetIt.instance — Dart Bölüm 6 Konu 27'de öğrendiğimiz static getter/singleton kalıbının gerçek bir kullanımı — uygulama boyunca tek bir GetIt deposu vardır.

registerLazySingleton<T>(...) — Dart Bölüm 9'da öğrendiğimiz generic tip parametresi (<T>) ile, "bu tipte bir nesne istendiğinde, şu fonksiyonu çalıştırarak oluştur, ve bir daha oluşturma, aynı örneği (instance) tekrar kullan" diyoruz. "Lazy" kelimesi, Dart Bölüm 11 Konu 51'de öğrendiğimiz lazy evaluation kavramına birebir bağlanıyor — nesne, ilk gerçekten istendiğinde oluşturulur, uygulama başlarken değil.

registerFactory<T>(...) — registerLazySingleton'dan farklı olarak, her getIt<T>() çağrısında yeni bir örnek oluşturur — Dart Bölüm 6 Konu 27'de öğrendiğimiz factory constructor kavramına isim ve mantık olarak paralel.

#Kullanım — Widget İçinde

class UrunListesiEkrani extends StatelessWidget {
  const UrunListesiEkrani({super.key});

  @override
  Widget build(BuildContext context) {
    final useCase = getIt<IndirimliUrunleriGetirUseCase>(); // TEK SATIR!
    // ...
  }
}

Artık, karmaşık kurulum zincirini (Client → VeriKaynagi → Repository → UseCase) her widget'ta tekrarlamak yerine, sadece getIt<T>() çağırarak hazır, bağlanmış bir nesne alıyorsun.

#getIt<T>() ile Provider/Riverpod Arasındaki Fark

Bu, kafa karıştırıcı olabilir — Bölüm 6'da öğrendiğimiz Provider/Riverpod da bir tür "nesne sağlama" mekanizmasıydı. Kritik fark:

Pratik olarak birlikte kullanılırlar: get_it, repository ve use case gibi "servisleri" enjekte eder; Provider/Riverpod, bu servisleri kullanan state'i (örneğin "şu an yüklenen ürün listesi") yönetir. Bölüm 7 Konu 32'deki UrunListesiEkrani örneğinde, ref.watch(indirimliUrunlerProvider) çağrısının arkasında, o provider'ın kendisi muhtemelen getIt<IndirimliUrunleriGetirUseCase>() ile use case'e erişiyor olurdu.

#injectable — Kod Üretimi ile Otomatikleştirme

Bölüm 5 Konu 21 ve Bölüm 13'te (Dart) öğrendiğimiz kod üretimi (code generation) kavramını hatırlarsan — injectable, get_it'in kayıt sürecini (yukarıdaki bagimliliklariKur() fonksiyonunu elle yazma zahmetini), annotation'lar kullanarak otomatikleştirir.

flutter pub add injectable
flutter pub add --dev injectable_generator build_runner

import 'package:injectable/injectable.dart';

@lazySingleton // annotation ile işaretliyoruz
class UrunRepositoryImpl implements UrunRepository {
  final UrunVeriKaynagi _veriKaynagi;
  UrunRepositoryImpl(this._veriKaynagi); // injectable, bu parametreyi OTOMATİK ÇÖZER

  @override
  Future<List<Urun>> urunleriGetir() async {
    // ...
  }
}

dart run build_runner build

Bu, bagimliliklariKur() içindeki elle yazılan getIt.registerLazySingleton<...>(...) satırlarının hepsini otomatik üretir — @lazySingleton annotation'ı gördüğünde, injectable, bu class'ın constructor'ındaki parametrelerine bakarak, gerekli bağımlılıkları otomatik olarak nasıl çözeceğini kendisi çıkarır (Dart Bölüm 6'da öğrendiğimiz constructor parametrelerinin statik analizi).

#Neden Dependency Injection Bu Kadar Değerli? — Bölüm 7 Konu 32'ye Bağlantı

Bir önceki derste, Repository pattern'in test edilebilirlik sağladığını öğrenmiştik — "gerçek yerine sahte bir implementasyon kullanabilirsin" demiştik. Dependency Injection, bunu pratikte mümkün kılan mekanizmadır:

// Test ortamında
void testOrtamiKur() {
  getIt.registerLazySingleton<UrunRepository>(() => SahteUrunRepository()); // GERÇEK yerine SAHTE
}

Testler çalışırken, getIt<UrunRepository>() çağrıldığında, gerçek API'ye bağlanan UrunRepositoryImpl yerine, sabit, kontrollü veri döndüren SahteUrunRepository (Dart Bölüm 7'de öğrendiğimiz implements ile, aynı sözleşmeye uyan bir başka class) kullanılır — kodun geri kalanı hiç değişmeden, sadece "hangi implementasyonun enjekte edildiği" değişiyor.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Dependency Injection, nesnelerin oluşturulma ve birbirine bağlanma sürecini merkezi bir yerde yönetir, kod tekrarını önler.
• get_it, basit bir "servis konumlandırıcı" (service locator) — registerLazySingleton/registerFactory ile kayıt yapılır, getIt<T>() ile erişilir.
• get_it, Provider/Riverpod'dan farklı olarak, widget ağacından bağımsızdır ve state değişince rebuild tetiklemez — genelde servisler/repository'ler için kullanılır.
• injectable, annotation'lar ve kod üretimi (build_runner) ile, get_it kayıt sürecini otomatikleştirir.
• Dependency Injection, Repository pattern'in test edilebilirlik avantajını pratikte mümkün kılan mekanizmadır — gerçek implementasyonları testlerde sahte olanlarla kolayca değiştirebilirsin.

#📝 Ödevler

• [ ] get_it ile bir servis sınıfını (örn. UrunVeriKaynagi) kaydet, getIt<T>() ile eriş, doğrudan new ile oluşturmaktan kaçın.
• [ ] registerLazySingleton ile registerFactory arasındaki farkı, aynı sınıfı ikisiyle de kaydedip, birden fazla getIt<T>() çağrısıyla (identical() kullanarak, Dart Bölüm 13'ü hatırla) test et.
• [ ] Bir Repository sözleşmesi (abstract class) için, hem gerçek hem sahte (test amaçlı) implementasyon yaz, get_it ile ikisi arasında geçiş yap.
• [ ] injectable kurup, @lazySingleton annotation'ı ile basit bir class'ı otomatik kayıt ettir, üretilen kodu incele.
• [ ] Kendi cümlelerinle, "get_it ile Provider/Riverpod'u ne zaman birlikte, ne için ayrı ayrı kullanırım" sorusunu açıkla.

Sıradaki konu: Bölüm 7 — Konu 34: Clean Architecture Uyarlaması, SOLID Prensipleri

Bölüm 7'nin son konusuna geldik. Şimdiye kadar Repository Pattern (Konu 32) ve Dependency Injection (Konu 33) ile parçaları öğrendik — bu derste bu parçaları tek bir tutarlı mimari altında birleştireceğiz ve bu mimarinin arkasındaki prensipleri (SOLID) netleştireceğiz.

#Neden Bir "Mimari"ye İhtiyacın Var?

Küçük bir uygulamada, tüm kodu tek bir dosyaya (main.dart) yazsan bile çalışır. Ama uygulaman büyüdükçe (10, 50, 200 ekran), şu sorular ortaya çıkar:

• Bir API çağrısını değiştirmek istediğimde, kaç dosyaya dokunmam gerekiyor?
• Bir widget testini yazarken, gerçek bir ağ isteği yapmadan test edebiliyor muyum?
• Yeni bir geliştirici projeye katıldığında, "kullanıcı girişi nerede yapılıyor?" sorusunun cevabını ne kadar hızlı bulabiliyor?

Clean Architecture (Robert C. Martin tarafından popülerleştirilen bir kavram), bu sorulara "kodu, değişme sıklığına ve sorumluluğuna göre katmanlara ayırarak" cevap verir.

#Üç Katman

lib/
├── data/            # DIŞ DÜNYA ile konuşan katman
│   ├── models/      # JSON <-> Dart nesnesi dönüşümü (Bölüm 5 Konu 21)
│   ├── datasources/ # API, veritabanı çağrıları (http/dio, sqflite/Hive)
│   └── repositories/ # Repository'lerin GERÇEK implementasyonu
├── domain/          # İŞ KURALLARI — Flutter'dan bile habersiz olmalı
│   ├── entities/    # Saf Dart sınıfları (JSON bilgisi yok)
│   ├── repositories/ # Repository'lerin SOYUT tanımı (interface)
│   └── usecases/    # Tek bir iş kuralını temsil eden sınıflar
└── presentation/    # KULLANICI ARAYÜZÜ
    ├── screens/     # Widget'lar (Scaffold içeren ekranlar)
    ├── widgets/     # Küçük, yeniden kullanılabilir widget'lar
    └── state/       # Riverpod/BLoC/Provider state yönetimi (Bölüm 6)

Akışı bir örnekle takip edelim — "Kullanıcı profilini göster" senaryosu:

1. presentation/screens/profil_ekrani.dart — ekran açılır, state yönetimine (ProfilNotifier gibi) "profili getir" der.
2. domain/usecases/profil_getir.dart — bu, tek bir iş kuralını temsil eden bir sınıf; ProfilRepository (soyut) üzerinden veri ister.
3. domain/repositories/profil_repository.dart — bu sadece bir arayüz (interface), Dart Bölüm 7'de öğrendiğimiz abstract class kavramı. Nasıl veri getirileceğini bilmiyor, sadece "getirilebilir" sözünü veriyor.
4. data/repositories/profil_repository_impl.dart — arayüzün gerçek implementasyonu; data/datasources üzerinden API'ye gidiyor.
5. data/datasources/profil_api.dart — asıl HTTP isteğini yapan kod (Bölüm 5 Konu 20'yi hatırla).

#domain Katmanı Neden Flutter'ı Bilmemeli?

Bu, Clean Architecture'ın en çarpıcı kuralıdır: domain/ klasöründeki hiçbir dosya import 'package:flutter/...' içermemelidir — sadece saf Dart. Neden?

• Test edilebilirlik: İş kurallarını (örn. "bir siparişin toplam tutarını hesapla") test etmek için widget ağacı kurmana, WidgetTester kullanmana gerek kalmaz — sıradan bir Dart testi yeterlidir (Dart Bölüm 8'de öğrendiğimiz test paketini hatırla).
• Platform bağımsızlığı: Aynı iş mantığını, yarın bir Flutter web uygulamasında, bir komut satırı aracında ya da (teoride) tamamen farklı bir arayüz katmanında değiştirmeden kullanabilirsin.
• Değişim izolasyonu: UI'ı tamamen yeniden tasarlasan bile (yeni widget'lar, yeni state management paketi), iş kuralların dokunulmadan kalır.

#SOLID Prensipleri — Flutter Bağlamında

SOLID, nesne yönelimli tasarımın 5 temel prensibinin kısaltmasıdır. Dart Bölüm 7'de OOP'yi öğrendik — şimdi bu prensipleri gerçek Flutter kararlarına bağlayalım.

#S — Single Responsibility (Tek Sorumluluk)

"Bir sınıfın değişmesi için tek bir sebep olmalı."

// ❌ Kötü — bu widget hem UI çiziyor hem API çağrısı yapıyor hem veri dönüştürüyor
class ProfilEkrani extends StatefulWidget {
  // ... build() içinde doğrudan http.get() çağrısı, JSON parse etme, hata yönetimi hepsi bir arada
}

// ✅ İyi — sorumluluklar ayrılmış
class ProfilEkrani extends StatelessWidget { /* sadece UI */ }
class ProfilGetirUseCase { /* sadece iş kuralı */ }
class ProfilRepositoryImpl { /* sadece veri erişimi */ }

Bölüm 6 Konu 24'te Provider ile, Bölüm 3 Konu 13'te custom widget'larla zaten kompozisyon yaparak bu prensibi uyguluyorduk — burada sadece isimlendirip bilinçli hale getiriyoruz.

#O — Open/Closed (Açık/Kapalı)

"Sınıflar genişletmeye açık, değiştirmeye kapalı olmalı."

abstract class OdemeYontemi {
  Future<bool> ode(double tutar);
}

class KrediKartiOdeme implements OdemeYontemi {
  @override
  Future<bool> ode(double tutar) async { /* ... */ return true; }
}

class HavaleOdeme implements OdemeYontemi {
  @override
  Future<bool> ode(double tutar) async { /* ... */ return true; }
}

Dart Bölüm 7'de öğrendiğimiz implements ile interface kavramını hatırla — yeni bir ödeme yöntemi (KriptoOdeme gibi) eklemek istediğinde, var olan kodu değiştirmene gerek yok, sadece OdemeYontemi'ni implemente eden yeni bir sınıf ekliyorsun. Bu, switch ile her ödeme türünü tek tek kontrol eden bir yapıya göre çok daha sürdürülebilir.

#L — Liskov Substitution (Liskov Yerine Geçme)

"Bir alt sınıf, üst sınıfının yerine sorunsuz geçebilmeli."

// ❌ Kötü — MockRepository, gerçek repository'nin davranışını BOZUYOR
class ProfilRepositoryImpl implements ProfilRepository {
  @override
  Future<Profil> getir(String id) async => /* gerçek API çağrısı */;
}

class BozukMockRepository implements ProfilRepository {
  @override
  Future<Profil> getir(String id) async {
    throw UnimplementedError(); // ❌ Sözleşmeyi ihlal ediyor!
  }
}

Bir ProfilRepository sözü (Dart Bölüm 7'de abstract class'ın bir "sözleşme" olduğunu öğrenmiştik), her implementasyonda tutulmalı. Test için yazdığın bir FakeProfilRepository, gerçek implementasyonun yerine sorunsuzca geçebilmeli — bu, testlerin neden repository arayüzü üzerinden yazılabildiğinin temelidir.

#I — Interface Segregation (Arayüz Ayrımı)

"Bir sınıf, kullanmadığı metodlara bağımlı olmaya zorlanmamalı."

// ❌ Kötü — dev bir "her şeyi yapan" interface
abstract class KullaniciServisi {
  Future<Kullanici> girisYap(String email, String sifre);
  Future<void> cikisYap();
  Future<void> profilGuncelle(Profil profil);
  Future<void> bildirimGonder(String mesaj); // profil ekranının umurunda bile değil!
}

// ✅ İyi — küçük, odaklı arayüzler
abstract class KimlikDogrulama {
  Future<Kullanici> girisYap(String email, String sifre);
  Future<void> cikisYap();
}

abstract class ProfilYonetimi {
  Future<void> profilGuncelle(Profil profil);
}

Bir sınıf sadece giriş/çıkış işlemleriyle ilgileniyorsa, bildirimGonder gibi alakasız bir metoda bağımlı olmaya zorlanmamalı. Küçük arayüzler, Bölüm 7 Konu 33'te öğrendiğimiz dependency injection ile birleştiğinde, her sınıfın gerçekten ihtiyaç duyduğu bağımlılığı almasını sağlar.

#D — Dependency Inversion (Bağımlılığın Tersine Çevrilmesi)

"Üst seviye modüller, alt seviye modüllere değil, soyutlamalara bağımlı olmalı."

Bu, aslında Bölüm 7 Konu 33'te (Dependency Injection) ve bu dersin başında gördüğümüz domain/data ayrımının temel gerekçesidir:

// domain/usecases/profil_getir.dart — SOYUT ProfilRepository'ye bağımlı
class ProfilGetirUseCase {
  final ProfilRepository _repository; // interface, implementasyon DEĞİL
  ProfilGetirUseCase(this._repository);

  Future<Profil> call(String id) => _repository.getir(id);
}

ProfilGetirUseCase, ProfilRepositoryImpl'i (somut sınıfı) hiç bilmiyor — sadece ProfilRepository (soyut) arayüzünü biliyor. Hangi gerçek implementasyonun kullanılacağına, Bölüm 7 Konu 33'te öğrendiğimiz get_it/injectable gibi bir DI aracı, uygulamanın başlangıcında karar verir:

void kurulumYap() {
  getIt.registerLazySingleton<ProfilRepository>(
    () => ProfilRepositoryImpl(getIt<ProfilApi>()), // somut sınıf BURADA "bağlanıyor"
  );
}

Bu sayede, testte ProfilRepositoryImpl yerine sahte bir FakeProfilRepository kaydedebilirsin — ProfilGetirUseCase'in kodunu hiç değiştirmeden.

#Hepsi Bir Arada — Küçük Bir Uçtan Uca Örnek

// domain/entities/profil.dart — saf Dart, Flutter'dan habersiz
class Profil {
  final String id;
  final String isim;
  Profil({required this.id, required this.isim});
}

// domain/repositories/profil_repository.dart — soyut sözleşme
abstract class ProfilRepository {
  Future<Profil> getir(String id);
}

// domain/usecases/profil_getir_usecase.dart — tek bir iş kuralı
class ProfilGetirUseCase {
  final ProfilRepository _repository;
  ProfilGetirUseCase(this._repository);
  Future<Profil> call(String id) => _repository.getir(id);
}

// data/repositories/profil_repository_impl.dart — gerçek implementasyon
class ProfilRepositoryImpl implements ProfilRepository {
  final Dio _dio; // Bölüm 5 Konu 20
  ProfilRepositoryImpl(this._dio);

  @override
  Future<Profil> getir(String id) async {
    final yanit = await _dio.get('/profil/$id');
    return Profil(id: yanit.data['id'], isim: yanit.data['isim']); // Bölüm 5 Konu 21
  }
}

// presentation/state/profil_notifier.dart — Riverpod ile (Bölüm 6 Konu 25)
class ProfilNotifier extends AsyncNotifier<Profil?> {
  @override
  Future<Profil?> build() => null;

  Future<void> getir(String id) async {
    state = const AsyncLoading();
    final useCase = ref.read(profilGetirUseCaseProvider); // DI ile enjekte edilmiş
    state = await AsyncValue.guard(() => useCase(id));
  }
}

Bu akışta, presentation katmanı sadece ProfilGetirUseCase'i çağırıyor; domain katmanı Flutter'dan tamamen habersiz; data katmanı ise dış dünyayla (Dio) konuşan tek yer. Her katman, sadece kendi işine odaklanıyor — tam da Single Responsibility'nin istediği gibi.

#Bu Kadar Katman Her Projede Gerekli mi?

Dürüst bir uyarı: Küçük bir uygulamada (5-10 ekranlık bir MVP, bir hackathon projesi), bu kadar katmanlandırma gereksiz karmaşıklık yaratabilir — "aşırı mühendislik" (over-engineering) riski gerçektir. Pratik yaklaşım:

• Küçük/hızlı proje: presentation + tek bir services/repositories klasörü yeterli olabilir, domain katmanını tamamen atlayabilirsin.
• Büyüyen/uzun soluklu proje: Test yazmaya başladığında, birden fazla geliştirici katıldığında, ya da bir API sağlayıcısını değiştirmen gerektiğinde, katmanlı mimarinin faydası hızla kendini gösterir.

Bölüm 7 boyunca öğrendiğin repository pattern, DI ve şimdi bu mimari, hepsi birbirine bağlı araçlar — hangisini ne zaman kullanacağına, projenin büyüklüğüne göre sen karar vereceksin.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Clean Architecture, kodu presentation (UI), domain (iş kuralları) ve data (dış dünya erişimi) olmak üzere üç katmana ayırır.
• domain katmanı Flutter'dan habersiz olmalı — bu, test edilebilirlik ve platform bağımsızlığı sağlar.
• SOLID: Single Responsibility (her sınıf tek iş yapar), Open/Closed (yeni davranış = yeni sınıf, eski kodu değiştirme), Liskov Substitution (alt sınıflar üst sınıfın sözleşmesini bozmaz), Interface Segregation (küçük, odaklı arayüzler), Dependency Inversion (somut sınıflara değil, soyutlamalara bağımlı ol).
• Dependency Inversion, Bölüm 7 Konu 33'teki DI araçlarının (get_it/injectable) neden var olduğunun temel gerekçesidir.
• Bu mimari her projede gerekli değildir — küçük projelerde basit tutmak, büyüyen projelerde katmanlamak mantıklıdır.

#📝 Ödevler

• [ ] Kendi cümlelerinle, "neden domain katmanı Flutter'ı import etmemeli" sorusunu, test edilebilirlik açısından açıkla.
• [ ] SOLID prensiplerinden birini (Open/Closed önerilir) ihlal eden bir kod örneği yaz, sonra aynı kodu prensibe uygun hale getir.
• [ ] Basit bir Entity + soyut Repository + UseCase üçlüsü tasarla (örneğin bir "Not Alma" uygulaması için Not, NotRepository, NotEkleUseCase).
• [ ] Bir data/repositories implementasyonu yaz (gerçek bir API çağrısı yapmasına gerek yok, sabit/mock veri döndürebilir), get_it ile kaydet.

#🎮 Mini Uygulama — Bölüm 7 Checkpoint: Katmanlı Görev Yöneticisi

Bölüm 7'yi (Navigasyon + Mimari) kapatan bir uçtan uca mini proje:

Gereksinimler:

• domain: Gorev entity'si (id, başlık, tamamlandı mı), soyut GorevRepository (listele/ekle/tamamla metodları), en az 2 use case (GorevleriGetirUseCase, GorevEkleUseCase).
• data: GorevRepository'nin bellek-içi (in-memory) bir implementasyonu — gerçek bir API'ye bağlanmana gerek yok, bir List<Gorev> yeterli.
• presentation: go_router (Bölüm 7 Konu 30) ile en az 2 rota (görev listesi, görev ekleme formu); state yönetimi için Riverpod veya BLoC (Bölüm 6) kullan.
• DI: get_it ile GorevRepository'yi ve use case'leri kaydet (Bölüm 7 Konu 33).
• Bonus: FakeGorevRepository adında ikinci bir implementasyon yaz (sabit, önceden doldurulmuş bir liste döndürsün) ve testte/geliştirmede gerçek implementasyon yerine bunu kaydet — Dependency Inversion'ın pratikteki faydasını birebir gözlemlemiş olursun.

Sıradaki konu: Bölüm 8 — Konu 35: Implicit Animasyonlar (AnimatedContainer, AnimatedOpacity ve benzerleri)

Bölüm 7'de mimariyi sağlamlaştırdık — Bölüm 8'de işin görsel tarafına, animasyonlara giriyoruz. Bu bölümü iki gruba ayıracağız: implicit (örtük, bu derste) ve explicit (açık, Konu 36'da) animasyonlar. Aradaki farkı baştan netleştirelim çünkü bu, bölümün tamamının zihinsel çerçevesi.

#Implicit vs Explicit — Temel Ayrım

Implicit animasyon: Sadece hedef değeri değiştirirsin (width: 100 → width: 200), widget kendi kendine aradaki geçişi animasyonlu şekilde yapar. Sen bir AnimationController, bir Tween yönetmezsin — Flutter senin için hallediyor.

Explicit animasyon: Animasyonun her aşamasını (süre, eğri, ne zaman başlayıp durduğu) sen kontrol edersin — bir AnimationController ile (Konu 36'da göreceğiz).

Analoji: Implicit animasyon, Dart Bölüm 5'te öğrendiğimiz yüksek seviye koleksiyon metodlarına (.map(), .where()) benzer — "ne istediğini" söylersin, "nasıl yapılacağını" Flutter halleder. Explicit animasyon ise, aynı işi elle bir for döngüsüyle yazmak gibidir — daha fazla kontrol, daha fazla kod.

#AnimatedContainer — En Sık Kullanılan Implicit Widget

class AnimasyonluKutu extends StatefulWidget {
  const AnimasyonluKutu({super.key});

  @override
  State<AnimasyonluKutu> createState() => _AnimasyonluKutuState();
}

class _AnimasyonluKutuState extends State<AnimasyonluKutu> {
  bool _buyukMu = false;

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () {
        setState(() {
          _buyukMu = !_buyukMu; // Bölüm 2 Konu 6 — setState ile rebuild tetikleme
        });
      },
      child: AnimatedContainer(
        duration: const Duration(milliseconds: 300),
        curve: Curves.easeInOut,
        width: _buyukMu ? 200 : 100,
        height: _buyukMu ? 200 : 100,
        decoration: BoxDecoration(
          color: _buyukMu ? Colors.indigo : Colors.blue,
          borderRadius: BorderRadius.circular(_buyukMu ? 40 : 8),
        ),
      ),
    );
  }
}

Nasıl çalıştığını parça parça açalım:

• duration: const Duration(milliseconds: 300) — bu, geçişin ne kadar süreceğini belirtir (Dart Bölüm 1'de öğrendiğimiz Duration sınıfı).
• curve: Curves.easeInOut — animasyonun hızlanma/yavaşlama karakteri. Curves, Flutter'ın hazır sunduğu bir dizi matematiksel eğridir (linear sabit hız, easeIn yavaş başlar hızlanır, bounceOut sekerek biter, vb.). Bunu birazdan detaylandıracağız.
• width/height/decoration — normal bir Container'daki (Bölüm 2 Konu 7) parametrelerin aynısı! Fark şu: AnimatedContainer, bu değerlerden biri değiştiğinde (burada _buyukMu setState ile değiştiğinde), yeni değere anında zıplamak yerine, duration boyunca kademeli olarak geçiş yapar.

Kritik zihinsel model: Sen setState() içinde hedef değeri değiştiriyorsun (_buyukMu = !_buyukMu), AnimatedContainer ise eski değerden yeni değere giden ara kareleri kendisi hesaplayıp çiziyor. Bu, Bölüm 2'de öğrendiğimiz "anında yeniden çizim" modelinden farklı — burada widget, birden fazla frame boyunca kendi kendini günceller.

#Diğer Yaygın Animated* Widget'lar

// Görünürlük/saydamlık
AnimatedOpacity(
  duration: const Duration(milliseconds: 200),
  opacity: _gorunurMu ? 1.0 : 0.0,
  child: const Icon(Icons.star),
)

// Konumlandırma (bir Stack içinde)
AnimatedPositioned(
  duration: const Duration(milliseconds: 400),
  left: _solaMi ? 0 : 200,
  top: 50,
  child: const FlutterLogo(),
)

// Metin stili
AnimatedDefaultTextStyle(
  duration: const Duration(milliseconds: 300),
  style: TextStyle(
    fontSize: _buyukMu ? 32 : 16,
    color: _buyukMu ? Colors.red : Colors.black,
  ),
  child: const Text('Merhaba'),
)

// İçerik değişimi (fade + boyut geçişi ile)
AnimatedSwitcher(
  duration: const Duration(milliseconds: 250),
  child: Text(
    '$_sayac',
    key: ValueKey<int>(_sayac), // ÖNEMLİ — birazdan açıklayacağız
    style: const TextStyle(fontSize: 48),
  ),
)

Deseni fark ettin mi? *Her `Animatedwidget, normal bir widget'ın (Container,Opacity,Positioned,DefaultTextStyle`) "değer değiştiğinde otomatik geçiş yapan" versiyonudur. Bu, Bölüm 3 Konu 13'te öğrendiğimiz kompozisyon prensibinin** Flutter'ın kendi API tasarımında tutarlı şekilde uygulandığını gösteriyor — aynı kalıp, düzinelerce widget için tekrarlanıyor.

#AnimatedSwitcher ve key — Neden Gerekli?

AnimatedSwitcher'daki key: ValueKey<int>(_sayac) satırı, ilk bakışta gizemli görünebilir. Şunu anlaman gerekiyor: Flutter, bir widget'ın "aynı widget mı yoksa yeni bir widget mı" olduğuna, büyük ölçüde tipine ve key'ine bakarak karar verir (Bölüm 1'de değindiğimiz widget ağacı diffing mekanizmasının bir parçası). AnimatedSwitcher, çocuğu değiştiğinde (eski widget'tan farklı bir widget geldiğinde) geçiş animasyonu oynatır — ama sadece Text('$_sayac') yazarsan, Flutter bunu "aynı Text widget'ı, sadece içeriği değişti" olarak görür, yeni bir widget olarak algılamaz, ve animasyon tetiklenmez. ValueKey<int>(_sayac) vererek, Flutter'a "sayaç değeri değiştiğinde, bu artık farklı bir widget'tır" demiş oluyoruz — bu da AnimatedSwitcher'ın geçiş animasyonunu tetiklemesini sağlıyor.

#TweenAnimationBuilder — Implicit Dünyanın "Joker Kartı"

Bazen ihtiyacın olan animasyon, hazır bir Animated* widget'ıyla karşılanmaz (örneğin bir sayının 0'dan 100'e animasyonlu şekilde sayması). TweenAnimationBuilder, implicit animasyon mantığını herhangi bir değere uygulamanı sağlar:

TweenAnimationBuilder<double>(
  tween: Tween<double>(begin: 0, end: 100),
  duration: const Duration(seconds: 2),
  builder: (context, deger, child) {
    return Text('${deger.toInt()}'); // 0'dan 100'e animasyonlu sayma
  },
)

Tween<double>(begin: 0, end: 100) — Dart Bölüm 9'da öğrendiğimiz generic (<double>), burada hangi tip arasında geçiş yapılacağını belirtiyor. Tween ("between" kelimesinden), iki değer arasında ara değerleri hesaplayan bir sınıftır — Konu 36'da explicit animasyonlarda da aynı Tween sınıfını göreceğiz, çünkü implicit ve explicit animasyonlar aynı temel altyapıyı (Konu 36'da tam işleyeceğimiz Animation/AnimationController) paylaşır; TweenAnimationBuilder, bu altyapıyı senin için gizleyen bir implicit sarmalayıcıdır.

builder: (context, deger, child) — Bölüm 3 Konu 11'de öğrendiğimiz builder pattern'in bir başka örneği; her animasyon karesinde, o anki ara değerle (deger) yeniden çağrılır.

#Curves — Animasyonun "Kişiliği"

Curves.linear      // sabit hız — robotik, doğal hissettirmez
Curves.easeIn      // yavaş başlar, hızlanarak biter
Curves.easeOut     // hızlı başlar, yavaşlayarak biter
Curves.easeInOut   // yavaş başlar, ortada hızlanır, yavaş biter (EN yaygın kullanılan)
Curves.bounceOut   // sona doğru seker (sekme efekti)
Curves.elasticOut  // esnek/yaylı bir aşırı-gitme efekti

Gerçek dünyada hiçbir hareket sabit hızda (linear) olmaz — bir araba durmadan önce yavaşlar, bir top zıplarken sekerek durur. curve, animasyonuna bu doğal hissi kazandırır. Pratik tavsiye: emin değilsen Curves.easeInOut ile başla, çoğu UI animasyonu için doğal ve nötr bir seçimdir.

#Ne Zaman Implicit, Ne Zaman Explicit?

Pratik gerçek: implicit animasyonlar, günlük UI işlerinin çoğunu (%80'e yakınını) karşılar — basit, az kod, okunabilir. Explicit animasyonlara, gerçekten ince kontrol gerektiğinde geçersin.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Implicit animasyonlarda sadece hedef değeri değiştirirsin, widget geçişi kendisi yönetir; explicit animasyonlarda (Konu 36) süreci sen kontrol edersin.
• AnimatedContainer/AnimatedOpacity/AnimatedPositioned/AnimatedDefaultTextStyle, normal widget'ların "otomatik geçişli" versiyonlarıdır — hepsi aynı kalıbı (duration + curve + hedef değerler) paylaşır.
• AnimatedSwitcher, çocuk widget değiştiğinde geçiş animasyonu oynatır — Flutter'ın "bu farklı bir widget" diye anlayabilmesi için genelde bir key (örn. ValueKey) vermen gerekir.
• TweenAnimationBuilder, implicit animasyon mantığını herhangi bir değere (sadece widget parametrelerine değil) uygulamanı sağlar; Tween, explicit animasyonlarla paylaşılan temel bir kavramdır.
• Curves, animasyona doğal bir hız karakteri kazandırır; easeInOut güvenli bir varsayılandır.

#📝 Ödevler

• [ ] AnimatedContainer ile, tıklandığında boyutu, rengi VE köşe yuvarlaklığını aynı anda değiştiren bir kutu yap.
• [ ] AnimatedOpacity ile, bir butona basıldığında yavaşça kaybolup tekrar beliren bir widget yap.
• [ ] AnimatedSwitcher kullanarak bir sayaç değerini, key vermeden ve vererek iki şekilde dene — aradaki görsel farkı gözlemle ve nedenini açıkla.
• [ ] TweenAnimationBuilder ile 0'dan istediğin bir sayıya, 2 saniyede animasyonlu şekilde sayan bir "istatistik" widget'ı yap.
• [ ] Aynı AnimatedContainer örneğini, sırasıyla Curves.linear, Curves.bounceOut ve Curves.elasticOut ile dene, aralarındaki "his" farkını kendi cümlelerinle tarif et.

Sıradaki konu: Bölüm 8 — Konu 36: Explicit Animasyonlar (AnimationController, Tween, Curve — Tam Kontrol)

Konu 35'te implicit animasyonların "ne istediğini söyle, Flutter halletsin" felsefesini gördük. Bu derste, "nasıl olacağını sen yönet" dünyasına giriyoruz — implicit animasyonların arkasında gerçekte ne olduğunu da bu sayede öğreneceğiz.

#Neden Explicit Animasyona İhtiyaç Duyarsın?

AnimatedContainer gibi widget'lar harika ama şu senaryolarda yetersiz kalır:

• Animasyonu duraklatmak, tersine çevirmek, ya da tekrar tekrar (loop) oynatmak istiyorsun.
• Birden fazla animasyonu birbirine bağlı (biri bitince diğeri başlasın gibi) yönetmen gerekiyor.
• Animasyonun hangi aşamada olduğunu (başladı mı, bitti mi) koda göre tepki vermen gerekiyor.

#AnimationController — Animasyonun "Motoru"

class DonenIkon extends StatefulWidget {
  const DonenIkon({super.key});

  @override
  State<DonenIkon> createState() => _DonenIkonState();
}

class _DonenIkonState extends State<DonenIkon> with SingleTickerProviderStateMixin {
  late final AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      duration: const Duration(seconds: 2),
      vsync: this, // birazdan açıklayacağız
    )..repeat(); // sonsuz döngüde oynat
  }

  @override
  void dispose() {
    _controller.dispose(); // ÇOK ÖNEMLİ — bellek sızıntısını önler
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return RotationTransition(
      turns: _controller,
      child: const Icon(Icons.refresh, size: 48),
    );
  }
}

Parça parça inceleyelim:

with SingleTickerProviderStateMixin — Dart Bölüm 7'de öğrendiğimiz mixin kavramının, Flutter'da kritik bir kullanımı. Bir animasyonun "her karede" (saniyede ~60 kez) güncellenmesi gerekir — bu düzenli "tık"ları üreten mekanizmaya Ticker denir. SingleTickerProviderStateMixin, State sınıfına, bir tane Ticker üretebilme yeteneği ekler (birden fazla AnimationController yönetmen gerekiyorsa TickerProviderStateMixin kullanılır — çoğul).

vsync: this — vsync ("vertical sync"), AnimationController'a hangi Ticker sağlayıcısını kullanacağını söyler. this, yukarıdaki mixin sayesinde artık bir TickerProvider'dır. Neden gerekli? Ekranda görünmeyen bir widget'ın (örneğin başka bir sekmeye geçtin) arka planda gereksiz yere animasyon karesi üretip pil tüketmesini önlemek için — vsync, Flutter'a "bu widget görünür değilken animasyonu duraklat" demenin yoludur.

late final AnimationController _controller — Dart Bölüm 2'de öğrendiğimiz late anahtar kelimesi burada zorunlu, çünkü _controller, initState() içinde (constructor'da değil) oluşturuluyor — late, "bu alana hemen değil, ilk kullanılmadan önce bir değer atanacak" demektir.

..repeat() — Dart Bölüm 6'da öğrendiğimiz cascade operatörü (..) — AnimationController'ı oluşturduktan hemen sonra, aynı ifade içinde repeat() metodunu çağırıyoruz (animasyonu sürekli tekrar ettir).

dispose() içinde _controller.dispose() — Bölüm 2 Konu 6'da State sınıfının yaşam döngüsünü öğrenmiştik; dispose(), widget kalıcı olarak kaldırıldığında çağrılır. AnimationController'ı burada serbest bırakmazsan, widget ekrandan kalksa bile animasyon arka planda çalışmaya devam eder — bu, gerçek uygulamalarda çok yaygın bir bellek sızıntısı kaynağıdır.

#AnimationController Aslında Ne Üretiyor?

AnimationController, kendisi bir Animation<double>'dır — 0.0'dan 1.0'a (varsayılan olarak), duration boyunca doğrusal olarak ilerleyen bir değer üretir. RotationTransition'ın turns: parametresi, bu 0.0→1.0 değerini "kaç tam tur" olarak yorumluyor (1.0 = 360°).

_controller.forward();   // 0.0'dan 1.0'a ilerlet
_controller.reverse();   // 1.0'dan 0.0'a geri sar
_controller.repeat();    // sürekli 0.0 → 1.0 → 0.0 → 1.0 ... tekrarla
_controller.stop();      // olduğu yerde durdur

#Tween — Ham Değeri "Anlamlı" Bir Aralığa Dönüştürme

AnimationController'ın ürettiği 0.0–1.0 aralığı çoğu zaman doğrudan işine yaramaz — bir rengi, bir boyutu, bir konumu animasyonlamak istiyorsun. Tween (Konu 35'te implicit animasyonlarda da gördüğümüz sınıf), bu ham 0.0–1.0 değerini, istediğin aralığa dönüştürür:

class BuyuyenKutu extends StatefulWidget {
  const BuyuyenKutu({super.key});

  @override
  State<BuyuyenKutu> createState() => _BuyuyenKutuState();
}

class _BuyuyenKutuState extends State<BuyuyenKutu> with SingleTickerProviderStateMixin {
  late final AnimationController _controller;
  late final Animation<double> _boyutAnimasyonu;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      duration: const Duration(seconds: 1),
      vsync: this,
    );

    _boyutAnimasyonu = Tween<double>(begin: 50, end: 200).animate(
      CurvedAnimation(parent: _controller, curve: Curves.easeInOut),
    );

    _controller.forward();
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return AnimatedBuilder(
      animation: _boyutAnimasyonu,
      builder: (context, child) {
        return Container(
          width: _boyutAnimasyonu.value,
          height: _boyutAnimasyonu.value,
          color: Colors.indigo,
        );
      },
    );
  }
}

Tween<double>(begin: 50, end: 200).animate(...) — Tween'in .animate() metodu, kendisine bir Animation<double> (genelde CurvedAnimation üzerinden _controller'ın kendisi) bağlar ve sonuç olarak, _controller 0.0'dan 1.0'a ilerlerken, 50'den 200'e ilerleyen yeni bir Animation<double> üretir.

CurvedAnimation(parent: _controller, curve: Curves.easeInOut) — _controller'ın doğrusal (linear) ilerlemesine, Konu 35'te gördüğümüz Curves mantığını uygular. Bu, Tween ile AnimationController arasına giren bir "ara katman" olarak düşünebilirsin.

AnimatedBuilder — Bölüm 3 Konu 11'de öğrendiğimiz builder pattern'in burada kritik bir kullanımı. animation: _boyutAnimasyonu verildiğinde, _boyutAnimasyonu her değiştiğinde (saniyede ~60 kez), builder yeniden çağrılır — sen setState() çağırmana hiç gerek kalmadan. _boyutAnimasyonu.value, o anki ara değeri (örn. 127.3) verir.

Neden setState() değil de AnimatedBuilder? Performans. setState() çağırmak, tüm build() metodunu yeniden çalıştırır. AnimatedBuilder, sadece kendi builder'ını (genelde küçük bir widget alt ağacını) yeniden çizer — geri kalan widget ağacın etkilenmez.

#Animation<T>'in Tipi double Olmak Zorunda Değil

final Animation<Color?> _renkAnimasyonu = ColorTween(
  begin: Colors.blue,
  end: Colors.red,
).animate(_controller);

final Animation<Offset> _konumAnimasyonu = Tween<Offset>(
  begin: Offset.zero,
  end: const Offset(1.5, 0),
).animate(_controller);

Dart Bölüm 9'da öğrendiğimiz generic tip parametreleri, burada tam güçle çalışıyor — ColorTween, iki renk arasında (Flutter'ın renk enterpolasyon mantığıyla) geçiş üretir; Offset ile ise widget'ın konumunu animasyonlayabilirsin (SlideTransition ile birlikte kullanılır).

#AnimatedBuilder'ın child Parametresi — Performans İnceliği

AnimatedBuilder(
  animation: _controller,
  child: const FlutterLogo(size: 100), // SADECE BİR KERE oluşturulur
  builder: (context, child) {
    return Transform.rotate(
      angle: _controller.value * 6.28, // 2*pi
      child: child, // her karede YENİDEN OLUŞTURULMUYOR, sadece döndürülüyor
    );
  },
)

Eğer builder içinde her karede yeniden oluşturulmasına gerek olmayan bir alt widget varsa (burada FlutterLogo, sadece döndürülüyor, kendisi değişmiyor), bunu AnimatedBuilder'ın child: parametresine taşırsın. Flutter, bu child'ı bir kere oluşturur ve her builder çağrısında aynı örneği sana geri verir — Bölüm 9'da (performans) derinlemesine göreceğimiz bir optimizasyon deseninin ilk örneği.

#Durum Dinleme — addStatusListener

_controller.addStatusListener((status) {
  if (status == AnimationStatus.completed) {
    _controller.reverse(); // bitince otomatik geri sar — "yo-yo" efekti
  } else if (status == AnimationStatus.dismissed) {
    _controller.forward(); // baştan başlat
  }
});

AnimationStatus, Dart Bölüm 7'de öğrendiğimiz bir enum'dur (dismissed, forward, reverse, completed). Bu dinleyici sayesinde, animasyon bittiğinde koda göre tepki verebilirsin — implicit animasyonlarda bu seviyede kontrol mümkün değildi.

#Hazır Geçiş Widget'ları — *Transition Ailesi

AnimatedBuilder ile her şeyi elle yazabilirsin, ama Flutter, en sık ihtiyaç duyulan geçişler için hazır widget'lar sunar:

FadeTransition(opacity: _animasyon, child: ...)       // saydamlık
ScaleTransition(scale: _animasyon, child: ...)         // boyut
RotationTransition(turns: _animasyon, child: ...)      // döndürme
SlideTransition(position: _konumAnimasyonu, child: ...) // konum
SizeTransition(sizeFactor: _animasyon, child: ...)     // boyut açılma/kapanma

Bunlar, AnimatedBuilder + ilgili Transform/Opacity widget'ının hazır, isimlendirilmiş kombinasyonlarıdır — kendi AnimatedBuilder'ını yazmadan önce, ihtiyacının bunlardan biriyle karşılanıp karşılanmadığını kontrol etmek iyi bir alışkanlıktır.

#Implicit'e Geri Dönüş — Artık "Sihir" Değil

Konu 35'te AnimatedContainer'ın arkasında ne olduğunu merak etmiştin belki — şimdi cevabı biliyorsun: AnimatedContainer, kendi iç AnimationController'ını yönetir, değer değiştiğinde otomatik olarak .forward() çağırır ve bir Tween oluşturup animasyonu senin için oynatır. Konu 35'teki her implicit widget, bu dersteki parçaların Flutter tarafından senin için birleştirilmiş halidir — tıpkı Provider'ın arka planda InheritedWidget kullanması gibi (Bölüm 6 Konu 23'ü hatırla).

#🎯 Bu Dersten Çıkarılması Gerekenler

• AnimationController, 0.0–1.0 arası doğrusal ilerleyen bir Animation<double> üretir; vsync (Ticker sağlayıcı) ile senkronize çalışır ve mutlaka dispose() edilmelidir.
• Tween<T>.animate(...), ham 0.0–1.0 değerini istediğin aralığa/tipe (double, Color, Offset vb.) dönüştürür; CurvedAnimation, buna bir Curve uygular.
• AnimatedBuilder, bir Animation değiştiğinde setState() çağırmadan, sadece kendi builder'ını yeniden çizer — performans için child: parametresiyle değişmeyen alt widget'ları izole edebilirsin.
• addStatusListener, animasyonun aşamasına (completed, dismissed vb.) göre koda tepki vermeni sağlar.
• FadeTransition/ScaleTransition/RotationTransition/SlideTransition, en sık ihtiyaç duyulan geçişlerin hazır widget'larıdır.
• Implicit animasyonlar (Konu 35), bu dersteki mekanizmaların Flutter tarafından senin için sarmalanmış halidir.

#📝 Ödevler

• [ ] AnimationController + RotationTransition ile sürekli dönen bir ikon yap, .stop()/.forward() bağlı iki butonla kontrol et.
• [ ] Tween<double> + CurvedAnimation + AnimatedBuilder ile, bir kutunun boyutunu Curves.bounceOut eğrisiyle büyüten bir animasyon yaz.
• [ ] addStatusListener kullanarak, bir animasyon bittiğinde otomatik olarak tersine (reverse) başlayan bir "yo-yo" efekti oluştur.
• [ ] AnimatedBuilder'ın child: parametresini kullanarak, sabit kalan bir widget'ı (örn. bir resim) her karede yeniden oluşturmadan döndür.
• [ ] Aynı görsel efekti önce elle AnimatedBuilder ile, sonra hazır FadeTransition/ScaleTransition widget'larıyla yap, kod miktarını karşılaştır.

Sıradaki konu: Bölüm 8 — Konu 37: Hero Animasyonları

Konu 35-36'da tek bir ekran içindeki animasyonları öğrendik. Bu ders, iki ekran arasındaki en tanıdık geçiş animasyonuna odaklanıyor: bir listedeki küçük bir resmin, detay ekranında büyük haline sorunsuzca dönüşmesi. Bunu muhtemelen Instagram, e-ticaret uygulamaları gibi pek çok yerde görmüşsündür.

#Sorunu Tanımlayalım

Bölüm 3 Konu 14'te öğrendiğimiz Navigator.push()'u hatırla — bir ekrandan diğerine geçerken, yeni ekran genelde sağdan kayarak ya da belirir. Ama bir ürün resmi gibi ortak bir öğe varsa, kullanıcı deneyimi açısından o öğenin aniden kaybolup başka bir yerde aniden belirmesi yerine, akıcı bir şekilde büyüyerek/hareket ederek yeni konumuna gitmesi çok daha doğal hissettirir. İşte "Hero animasyonu" tam olarak bunu yapar.

#Hero Widget'ı — Tek Bir Kural: Aynı tag

// Liste ekranı
class UrunListesi extends StatelessWidget {
  const UrunListesi({super.key});

  @override
  Widget build(BuildContext context) {
    return ListView(
      children: [
        GestureDetector(
          onTap: () {
            Navigator.push(
              context,
              MaterialPageRoute(builder: (context) => const UrunDetayEkrani()),
            );
          },
          child: Hero(
            tag: 'urun-resmi-1', // ANAHTAR — iki ekranda da AYNI olmalı
            child: Image.asset('assets/urun1.png', width: 80, height: 80),
          ),
        ),
      ],
    );
  }
}

// Detay ekranı
class UrunDetayEkrani extends StatelessWidget {
  const UrunDetayEkrani({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Hero(
          tag: 'urun-resmi-1', // AYNI tag!
          child: Image.asset('assets/urun1.png', width: 300, height: 300),
        ),
      ),
    );
  }
}

Bütün mekanizma, tek bir kurala dayanır: Aynı tag değerine sahip iki Hero widget'ı, farklı ekranlarda (route'larda) bulunuyorsa, Flutter, geçiş sırasında otomatik olarak ilkinin konumundan/boyutundan ikincisinin konumuna/boyutuna animasyonlu bir geçiş oluşturur. Sen width: 80 → width: 300 değişimini elle animasyonlamıyorsun — Flutter, Konu 36'da öğrendiğimiz AnimationController/Tween altyapısını arka planda kendisi kurup çalıştırıyor.

tag neden String yerine Object tipinde de olabilir? Gerçek uygulamalarda genelde 'urun-resmi-1' gibi sabit bir string yerine, ürünün kendi ID'sini kullanırsın (tag: urun.id) — bu sayede her ürün için otomatik olarak benzersiz bir tag üretmiş olursun, elle her birine farklı string yazmana gerek kalmaz.

Hero(
  tag: urun.id, // dinamik, her ürün için otomatik benzersiz
  child: Image.network(urun.resimUrl),
)

#Neden Sadece "Konum ve Boyut"? İçerik de Değişebilir mi?

Hero(
  tag: 'profil-resmi',
  child: CircleAvatar(radius: 30, backgroundImage: AssetImage('assets/profil.png')),
)
// ... diğer ekranda
Hero(
  tag: 'profil-resmi',
  child: Container(
    decoration: BoxDecoration(shape: BoxShape.circle, border: Border.all(width: 4)),
    child: CircleAvatar(radius: 100, backgroundImage: AssetImage('assets/profil.png')),
  ),
)

Hero widget'ının içeriği (child) iki ekranda birebir aynı olmak zorunda değil — burada ikinci ekranda bir border eklendi. Flutter, geçiş sırasında iki child'ı da kullanarak (varsayılan olarak hedef ekranın child'ına geçiş yaparak) bir animasyon oluşturur. Ama pratik tavsiye: en akıcı sonuç için, iki taraftaki içeriği mümkün olduğunca benzer tutmak (örn. ikisi de aynı resim, sadece boyutu farklı) en doğal görüneni verir — çok farklı iki widget arasında Hero denemek garip sonuçlar üretebilir.

#flightShuttleBuilder — Geçiş Sırasındaki Görünümü Özelleştirme

Hero(
  tag: 'urun-resmi-1',
  flightShuttleBuilder: (
    flightContext,
    animation,
    flightDirection,
    fromHeroContext,
    toHeroContext,
  ) {
    return Material(
      color: Colors.transparent,
      child: toHeroContext.widget, // geçiş sırasında hedef widget'ı göster
    );
  },
  child: Image.asset('assets/urun1.png'),
)

Varsayılan davranış çoğu zaman yeterlidir, ama ileri bir özelleştirme olarak, geçiş sırasında (iki ekran arası "uçuş" anında) tam olarak neyin görüneceğini flightShuttleBuilder ile kontrol edebilirsin. animation parametresi, Konu 36'da öğrendiğimiz Animation<double> tipinde — geçişin o anki ilerleme durumunu (0.0–1.0) verir.

#Hero, Neyle Birlikte Çalışır?

Hero animasyonu, sadece Navigator.push()/pop() gibi bir route geçişi sırasında tetiklenir — aynı ekran içinde, setState() ile bir widget'ı büyütmek istiyorsan, bu Hero'nun işi değil, Konu 35-36'da öğrendiğimiz implicit/explicit animasyonların işidir. Bölüm 7'de öğrendiğimiz go_router ile de sorunsuz çalışır — GoRoute'un builder'ı ile açılan her ekran, standart bir MaterialPageRoute gibi davranır, dolayısıyla Hero mekanizması aynen çalışmaya devam eder.

#Yaygın Bir Hata — Aynı Ekranda İki Aynı tag

// ❌ HATA — aynı ekranda AYNI tag'e sahip iki Hero
ListView(
  children: [
    Hero(tag: 'urun', child: Image.asset('assets/a.png')),
    Hero(tag: 'urun', child: Image.asset('assets/b.png')), // ÇAKIŞMA!
  ],
)

Bir ListView.builder ile ürün listesi oluşturuyorsan ve her satıra sabit bir tag ('urun') verirsen, Flutter hangi Hero'nun hangisiyle eşleşeceğini bilemez ve çalışma zamanında hata verir. Bu yüzden yukarıda vurguladığımız gibi, her öğe için benzersiz bir tag (genelde ürünün ID'si) kullanmak zorunludur — sabit bir string sadece tek bir Hero'nun olduğu ekranlarda güvenlidir.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Hero, iki farklı ekran (route) arasında, aynı tag'e sahip widget'lar arasında otomatik bir geçiş animasyonu oluşturur.
• Mekanizma sadece Navigator.push()/pop() (veya go_router gibi bunun üzerine kurulu araçlar) sırasında tetiklenir — aynı ekran içi büyütme/küçültme için implicit/explicit animasyonlar kullanılır.
• tag, listelerde genelde dinamik olmalıdır (örn. urun.id) — sabit bir tag, aynı ekranda birden fazla Hero varsa çakışma hatası verir.
• İki taraftaki child birebir aynı olmak zorunda değil, ama en akıcı sonuç için benzer tutulması önerilir.
• flightShuttleBuilder, geçiş anındaki görünümü özelleştirmek için kullanılan ileri bir seçenektir.

#📝 Ödevler

• [ ] Bir ListView.builder ile en az 5 ürünlük bir liste yap, her ürüne benzersiz bir Hero tag'i (ürün ID'si) ver, tıklandığında detay ekranına Hero animasyonuyla geç.
• [ ] Bilerek iki farklı öğeye aynı sabit tag'i ver, Flutter'ın verdiği hatayı gözlemle ve nedenini kendi cümlelerinle açıkla.
• [ ] Detay ekranındaki Hero'nun child'ını, liste ekranındakinden görsel olarak biraz farklı yap (örn. bir border ekle), geçişin nasıl göründüğünü gözlemle.
• [ ] go_router (Bölüm 7 Konu 30) kullanan bir navigasyon yapısında Hero animasyonunun sorunsuz çalıştığını doğrula.

Sıradaki konu: Bölüm 8 — Konu 38: CustomPainter / Canvas

Şimdiye kadar hep hazır widget'ları (Container, Icon, Image) birleştirerek arayüz kurduk. Bu ders, Flutter'ın kendi çizim motoruna doğrudan erişmeni sağlıyor — bir dairesel ilerleme çubuğu, özel bir grafik, ya da hazır widget'larla yapamayacağın herhangi bir şekli çizebilmeni.

#Neden CustomPainter? Hazır Widget'lar Yetmiyor mu?

Container, BoxDecoration, ClipPath gibi widget'larla çoğu basit şekli (dikdörtgen, daire, kenarlık) çizebilirsin. Ama şu durumlarda CustomPainter'a ihtiyaç duyarsın:

• Veriye dayalı özel grafikler (bir çizgi grafiği, bir pasta grafiği, bir dalga formu).
• Piksel seviyesinde kontrol gerektiren, hazır widget'larla ifade edilemeyen şekiller.
• Performans kritik çizimler — yüzlerce küçük şekli tek tek widget olarak oluşturmak yerine, hepsini tek bir Canvas'a çizmek çok daha hızlıdır.

#Widget → Element → RenderObject Hatırlatması

Bölüm 1 Konu 1'de öğrendiğimiz üç katmanlı mimariyi (Widget → Element → RenderObject) hatırlarsan — her widget, sonunda bir RenderObject'e dönüşür ve gerçek çizim, RenderObject.paint() metodunda, bir Canvas üzerinde gerçekleşir. CustomPainter, bu düşük seviye çizim katmanına, kendi RenderObject'ini yazmak zorunda kalmadan doğrudan erişmeni sağlayan bir kolaylık katmanıdır (Bölüm 12'de, RenderObject'i tamamen elle yazmayı göreceğiz — CustomPainter, o işin %90'ını basitleştirilmiş bir arayüzle sunar).

#Temel Yapı

class DaireCizici extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    final boya = Paint()
      ..color = Colors.indigo
      ..style = PaintingStyle.fill;

    final merkez = Offset(size.width / 2, size.height / 2);
    final yaricap = size.width / 2;

    canvas.drawCircle(merkez, yaricap, boya);
  }

  @override
  bool shouldRepaint(covariant DaireCizici oldDelegate) {
    return false; // statik bir çizim, hiç yeniden çizilmesine gerek yok
  }
}

CustomPaint(
  size: const Size(200, 200),
  painter: DaireCizici(),
)

Parça parça inceleyelim:

extends CustomPainter — Dart Bölüm 7'de öğrendiğimiz extends; CustomPainter, Flutter'ın soyut bir sınıfıdır (Bölüm 7'de öğrendiğimiz gibi, paint/shouldRepaint zorunlu override edilecek metodlardır).

paint(Canvas canvas, Size size) — bu metod, her çizim gerektiğinde çağrılır. canvas, üzerine çizim yapacağın tuvaldir; size, CustomPaint widget'ının sana ayırdığı alanın boyutudur (Bölüm 2 Konu 8'de öğrendiğimiz constraint sistemini hatırla — CustomPaint, kendisine verilen constraint'lere göre bir boyut alır, paint() bu boyutu size parametresiyle sana bildirir).

Paint nesnesi — Dart Bölüm 6'da öğrendiğimiz class + cascade operatörü (..) kombinasyonu; Paint, nasıl çizeceğini (renk, dolgu mu çizgi mi, çizgi kalınlığı) tanımlar — kalemi/fırçayı seçmek gibi düşün.

canvas.drawCircle(merkez, yaricap, boya) — asıl çizim komutu. Canvas sınıfı, drawCircle, drawRect, drawLine, drawPath, drawArc gibi düzinelerce çizim metodu sunar.

shouldRepaint(covariant DaireCizici oldDelegate) — Bölüm 6 Konu 23'te InheritedWidget'ın updateShouldNotify'ını öğrenmiştik; bu, kavramsal olarak birebir aynı fikir. false döndürürsen, Flutter bu çizimi bir kere yapar ve bir daha (veri değişmediği sürece) tekrar çizmez — performans için kritik. covariant anahtar kelimesi, Dart Bölüm 7'de değinmediğimiz ama burada karşına çıkan bir detay: üst sınıftaki (CustomPainter) parametre tipi CustomPainter'dır, ama biz burada daha spesifik bir tip (DaireCizici) kullanmak istiyoruz — covariant, Dart'a "bu daraltmayı bilerek yapıyorum, tip güvenliğini burada gevşet" demenin yoludur.

#Dinamik Bir Örnek — Dairesel İlerleme Çubuğu

class IlerlemeCizici extends CustomPainter {
  final double ilerleme; // 0.0 - 1.0 arası (Konu 36'daki Animation.value gibi düşünebilirsin)

  IlerlemeCizici({required this.ilerleme});

  @override
  void paint(Canvas canvas, Size size) {
    final merkez = Offset(size.width / 2, size.height / 2);
    final yaricap = size.width / 2;

    // Arka plan halkası (gri, tam daire)
    final arkaPlanBoyasi = Paint()
      ..color = Colors.grey[300]!
      ..style = PaintingStyle.stroke
      ..strokeWidth = 12;
    canvas.drawCircle(merkez, yaricap, arkaPlanBoyasi);

    // İlerleme yayı (mavi, sadece 'ilerleme' kadar)
    final ilerlemeBoyasi = Paint()
      ..color = Colors.indigo
      ..style = PaintingStyle.stroke
      ..strokeWidth = 12
      ..strokeCap = StrokeCap.round;

    final rect = Rect.fromCircle(center: merkez, radius: yaricap);
    const baslangicAcisi = -3.14159 / 2; // saat 12 yönünden başla
    final taramaAcisi = 2 * 3.14159 * ilerleme; // Dart Bölüm 3 — matematik operatörleri

    canvas.drawArc(rect, baslangicAcisi, taramaAcisi, false, ilerlemeBoyasi);
  }

  @override
  bool shouldRepaint(covariant IlerlemeCizici oldDelegate) {
    return oldDelegate.ilerleme != ilerleme; // sadece değer değiştiğinde yeniden çiz
  }
}

Dikkat et: ilerleme, Dart Bölüm 6'da öğrendiğimiz constructor parametresi olarak veriliyor — bu, CustomPainter'ı her ilerleme değeri için yeniden oluşturarak kullanacağın anlamına gelir (tıpkı bir widget'ı yeniden build() etmek gibi). shouldRepaint, eski ve yeni ilerleme'yi karşılaştırarak, gereksiz yeniden çizimleri önlüyor.

#AnimatedBuilder ile Birleştirme — Animasyonlu Bir Çizim

Konu 36'da öğrendiğimiz AnimatedBuilder'ı, CustomPainter ile birleştirmek çok yaygın bir kalıptır:

class DaireselIlerlemeCubugu extends StatefulWidget {
  const DaireselIlerlemeCubugu({super.key});

  @override
  State<DaireselIlerlemeCubugu> createState() => _DaireselIlerlemeCubuguState();
}

class _DaireselIlerlemeCubuguState extends State<DaireselIlerlemeCubugu>
    with SingleTickerProviderStateMixin {
  late final AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      duration: const Duration(seconds: 2),
      vsync: this,
    )..forward();
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return AnimatedBuilder(
      animation: _controller,
      builder: (context, child) {
        return CustomPaint(
          size: const Size(150, 150),
          painter: IlerlemeCizici(ilerleme: _controller.value),
        );
      },
    );
  }
}

Burada, _controller.value (Konu 36'da öğrendiğimiz 0.0–1.0 arası ilerleme), her karede IlerlemeCizici'ye yeni bir ilerleme değeri olarak geçiliyor — bu da shouldRepaint'in true dönmesine ve ekranın her karede yeniden çizilmesine yol açıyor. Bu, tam olarak CustomPainter + AnimationController'ın birlikte çalışma deseni.

#CustomPaint'in child Parametresi

CustomPaint(
  size: const Size(200, 200),
  painter: DaireCizici(),
  child: const Center(child: Text('50%')), // çizimin ÜZERİNE bir widget koy
)

CustomPaint, sadece çizim yapmakla kalmaz — child: parametresiyle, çizimin üzerine normal widget'lar (metin, ikon) da koyabilirsin. Bu, örneğin bir dairesel ilerleme çubuğunun ortasına yüzde metni yazmak için çok kullanışlıdır.

#Metin Çizmek — TextPainter

Canvas'a doğrudan Text widget'ı koyamazsın (widget değil, düşük seviye bir çizim yüzeyi) — metin çizmek için TextPainter kullanılır:

void _metinCiz(Canvas canvas, Size size) {
  final textPainter = TextPainter(
    text: const TextSpan(
      text: 'Merhaba',
      style: TextStyle(color: Colors.black, fontSize: 16),
    ),
    textDirection: TextDirection.ltr,
  );
  textPainter.layout(); // önce boyutunu hesapla
  textPainter.paint(canvas, Offset(size.width / 2 - textPainter.width / 2, 10));
}

layout() çağrısı, Bölüm 2 Konu 8'de öğrendiğimiz "constraints go down, sizes go up" ilkesinin düşük seviyede bir yansımasıdır — metnin ne kadar yer kaplayacağını önce hesaplaman (layout()), sonra çizmen (paint()) gerekir.

#🎯 Bu Dersten Çıkarılması Gerekenler

• CustomPainter, RenderObject'in paint() katmanına doğrudan erişim sağlar — hazır widget'larla ifade edilemeyen özel çizimler için kullanılır.
• paint(Canvas canvas, Size size), asıl çizimin yapıldığı metoddur; Paint nesnesi rengi/stili, Canvas metodları (drawCircle, drawArc, drawPath vb.) şekli belirler.
• shouldRepaint, InheritedWidget'ın updateShouldNotify'ına benzer — gereksiz yeniden çizimleri önler.
• CustomPainter + AnimationController + AnimatedBuilder, animasyonlu özel çizimlerin standart birleşimidir.
• CustomPaint'in child: parametresi, çizimin üzerine normal widget koymanı sağlar.
• Metin çizmek için Text widget'ı değil, TextPainter (layout() + paint()) kullanılır.

#📝 Ödevler

• [ ] CustomPainter ile basit bir üçgen çiz (Path + drawPath kullanarak — moveTo/lineTo/close metodlarını araştır).
• [ ] Dairesel ilerleme çubuğu örneğini, AnimationController ile 0'dan 1'e animasyonlu şekilde dolduracak hale getir.
• [ ] CustomPaint'in child: parametresiyle, ilerleme çubuğunun ortasına o anki yüzdeyi gösteren bir Text koy.
• [ ] TextPainter kullanarak, bir Canvas üzerine ortalanmış bir başlık metni çiz.
• [ ] Kendi cümlelerinle, "shouldRepaint'i her zaman true döndürseydik ne olurdu" sorusunu, performans açısından açıkla.

Sıradaki konu: Bölüm 8 — Konu 39: Rive / Lottie Entegrasyonu (Bölüm 8'in Son Konusu)

Bölüm 8'in son konusuna geldik. Konu 35-38'de Flutter'ın kendi animasyon araçlarını (implicit, explicit, Hero, Canvas) öğrendik — bu son derste, tasarımcılar tarafından ayrı bir araçla üretilip Flutter'a hazır dosya olarak aktarılan animasyonları nasıl kullanacağını göreceğiz.

#Neden Hazır Animasyon Dosyaları?

Konu 38'de CustomPainter ile elle bir şekil çizmenin ne kadar ayrıntılı olduğunu gördün. Şimdi düşün: bir maskot karakterin zıplayarak selam vermesi, karmaşık bir yüklenme animasyonu, ya da bir onay işaretinin çiziliyormuş gibi belirmesi gibi tasarımcı-üretimi animasyonları Canvas ile elle kodlamak günler sürer. Bunun yerine, tasarımcılar bu animasyonları özel araçlarla (Adobe After Effects, Rive Editor) hazırlar, bir dosya olarak dışa aktarır, sen de bu dosyayı Flutter'da birkaç satır kodla oynatırsın.

İki popüler format var: Lottie (After Effects animasyonlarını JSON'a çeviren, Airbnb'nin açık kaynak formatı) ve Rive (kendi editörüyle gelen, etkileşimli animasyonlara daha uygun daha yeni bir format).

#Lottie — After Effects Animasyonlarını Oynatma

flutter pub add lottie

import 'package:lottie/lottie.dart';

Lottie.asset('assets/animasyonlar/yukleniyor.json')

Bu kadar basit — assets/ klasörüne (Bölüm 3 Konu 12'de öğrendiğimiz asset yönetimini hatırla) bir .json animasyon dosyası koyup pubspec.yaml'da tanımladıktan sonra, Lottie.asset(...), animasyonu otomatik olarak oynatmaya başlar (varsayılan olarak bir kere oynar).

Lottie.asset(
  'assets/animasyonlar/yukleniyor.json',
  repeat: true,        // sürekli tekrar oynat
  animate: true,        // otomatik başlasın
  width: 200,
  height: 200,
  fit: BoxFit.contain,  // Bölüm 3 Konu 12'deki BoxFit kavramını hatırla
)

Ağdan da yükleyebilirsin:

Lottie.network('https://ornek.com/animasyon.json')

Bölüm 3 Konu 12'de Image.asset ile Image.network arasındaki paralel isimlendirmeyi hatırlarsan — Lottie.asset/Lottie.network, aynı tasarım kalıbını takip ediyor.

#LottieBuilder + Kontrol — Konu 36'daki AnimationController ile Birleşim

Lottie animasyonunu, Konu 36'da öğrendiğimiz AnimationController ile elle kontrol edebilirsin — örneğin bir "beğen" butonuna basıldığında animasyonu bir kere oynatmak istiyorsan:

class BegenButonu extends StatefulWidget {
  const BegenButonu({super.key});

  @override
  State<BegenButonu> createState() => _BegenButonuState();
}

class _BegenButonuState extends State<BegenButonu> with SingleTickerProviderStateMixin {
  late final AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(vsync: this); // duration, Lottie dosyasından otomatik alınır
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () => _controller.forward(from: 0), // baştan bir kere oynat
      child: Lottie.asset(
        'assets/animasyonlar/kalp.json',
        controller: _controller,
        onLoaded: (composition) {
          _controller.duration = composition.duration; // animasyonun gerçek süresini al
        },
      ),
    );
  }
}

Dikkat et: AnimationController'ı burada kendi duration'ını elle belirtmeden oluşturduk — onLoaded callback'i, Lottie dosyası yüklendiğinde çağrılır ve dosyanın kendi doğal süresini (composition.duration) sana verir; bunu _controller.duration'a atayarak, kontrolcünün animasyon dosyasıyla tam senkronize çalışmasını sağlıyoruz.

#Rive — Etkileşimli, Durum Tabanlı Animasyonlar

flutter pub add rive

import 'package:rive/rive.dart';

RiveAnimation.asset('assets/animasyonlar/karakter.riv')

Rive'ın Lottie'den temel farkı: Rive dosyaları, kendi içinde bir State Machine (durum makinesi) taşıyabilir — yani animasyon, tek bir doğrusal oynatım değil, girdilere göre farklı davranan bir sistem olabilir (örneğin bir karakterin "bekleme", "yürüme", "zıplama" durumları arasında, senin kontrolünle geçiş yapması).

class EtkilesimliKarakter extends StatefulWidget {
  const EtkilesimliKarakter({super.key});

  @override
  State<EtkilesimliKarakter> createState() => _EtkilesimliKarakterState();
}

class _EtkilesimliKarakterState extends State<EtkilesimliKarakter> {
  StateMachineController? _controller;
  SMIBool? _tiklandiGirdisi; // State Machine'e bağlı bir boolean girdi

  void _onRiveInit(Artboard artboard) {
    final controller = StateMachineController.fromArtboard(artboard, 'Durum Makinesi');
    if (controller != null) {
      artboard.addController(controller);
      _controller = controller;
      _tiklandiGirdisi = controller.findInput<bool>('tiklandi') as SMIBool?;
    }
  }

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () {
        _tiklandiGirdisi?.value = true; // Rive editöründe tanımlı animasyonu tetikle
      },
      child: RiveAnimation.asset(
        'assets/animasyonlar/karakter.riv',
        onInit: _onRiveInit,
      ),
    );
  }
}

Buradaki SMIBool (State Machine Input — Boolean), Dart Bölüm 9'da öğrendiğimiz tip sistemine bir örnek: Rive, State Machine'e bool, double, "trigger" gibi farklı girdi tipleri tanımlamana izin verir; findInput<bool>('tiklandi'), generic bir arama yapıp, Rive editöründe tasarımcının tanımladığı tiklandi adlı girdiye koddan erişim sağlıyor.

Pratik gerçek: Rive dosyalarını kendin tasarlamazsın (Rive Editor ayrı bir araçtır) — genelde bir tasarımcıdan .riv dosyasını State Machine girdi isimleriyle birlikte alırsın (örn. "bu girdinin adı tiklandi, bool tipinde") ve koddan bu isimlere göre bağlarsın.

#Lottie mi, Rive mı?

#Bölüm 8'i Kapatırken — Hangi Aracı Ne Zaman Kullanırsın?

Basit bir değer değişimi (boyut, renk, opaklık)     → Implicit animasyon (Konu 35)
İnce kontrol, birden fazla bağlı animasyon           → Explicit animasyon (Konu 36)
İki ekran arasında ortak bir görselin geçişi         → Hero (Konu 37)
Veriye dayalı özel bir şekil/grafik                  → CustomPainter (Konu 38)
Tasarımcı tarafından hazırlanmış karmaşık animasyon  → Lottie / Rive (Konu 39)

Gerçek bir uygulamada, bu beş aracın hepsini bir arada kullanman gayet normaldir — örneğin bir splash screen'de Rive, kartlar arası geçişte Hero, bir yükleme göstergesinde CustomPainter, ve butonlarda implicit animasyonlar.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Lottie, After Effects kökenli .json animasyonlarını oynatır — Lottie.asset/Lottie.network, Image.asset/Image.network ile aynı tasarım kalıbını takip eder.
• Lottie animasyonları, Konu 36'daki AnimationController ile elle kontrol edilebilir; onLoaded callback'i, dosyanın gerçek süresini vermeni sağlar.
• Rive, .riv dosyaları ve State Machine ile, girdilere göre davranışı değişen etkileşimli animasyonlar sunar — Lottie'nin sunmadığı bir özellik.
• Rive'da StateMachineController + findInput<T>(), koddan tasarımcının tanımladığı girdilere (bool/double/trigger) bağlanmanı sağlar.
• Basit, tek seferlik animasyonlarda Lottie; etkileşimli/durum tabanlı animasyonlarda Rive tercih edilir.
• Bölüm 8'de öğrendiğin beş araç (implicit, explicit, Hero, CustomPainter, Lottie/Rive), gerçek bir uygulamada genelde bir arada kullanılır.

#📝 Ödevler

• [ ] LottieFiles.com'dan ücretsiz bir animasyon (örn. bir "yükleniyor" animasyonu) indir, Lottie.asset ile bir splash screen'de göster.
• [ ] İndirdiğin bir Lottie animasyonunu, AnimationController ile bir butona basıldığında bir kere oynatacak şekilde bağla (onLoaded ile süresini al).
• [ ] Rive'ın örnek dosyalarından (rive.app üzerindeki topluluk dosyaları) birini indir, RiveAnimation.asset ile ekranda göster.
• [ ] Kendi cümlelerinle, "Lottie ile Rive arasındaki temel farkın, State Machine kavramıyla nasıl ilişkili olduğunu" açıkla.

#🎮 Mini Uygulama — Bölüm 8 Checkpoint: Animasyonlu Ürün Vitrini

Bölüm 8'in tamamını (implicit, explicit, Hero, CustomPainter, Lottie/Rive) bir araya getiren bir mini proje:

Gereksinimler:

• Splash screen: Uygulama açılışında 1-2 saniye gösterilen, bir Lottie animasyonu içeren bir ekran (Future.delayed ile Bölüm 5 Konu 18'i hatırlayarak, sonra ana ekrana geç).
• Ürün listesi: ListView.builder ile bir ürün listesi; her ürün kartı, dokunulduğunda AnimatedContainer (Konu 35) ile hafifçe büyüsün (basılı tutma efekti — GestureDetector'ın onTapDown/onTapUp ile).
• Ürün detay geçişi: Listedeki ürün resminden detay ekranına Hero (Konu 37) ile geçiş.
• Yüklenme göstergesi: Detay ekranında, sahte bir yükleme süresi boyunca CustomPainter (Konu 38) ile çizilmiş dairesel bir ilerleme göstergesi.
• Bonus: "Sepete Ekle" butonuna basıldığında, AnimationController (Konu 36) ile bir "başarı" ikonu (veya bir Lottie onay animasyonu) kısaca belirip kaybolsun.

Sıradaki konu: Bölüm 9 — Konu 40: Platform Channels (Native Android/iOS Koduyla Konuşma)

Bölüm 9'a ("Platform & Native") hoş geldin. Şimdiye kadar öğrendiğimiz her şey Dart/Flutter dünyasının içindeydi. Ama bazen, cihazın pil seviyesini okumak, native bir SDK'yı (örneğin bir ödeme kütüphanesini) kullanmak, ya da Flutter'ın henüz sarmalamadığı bir platform özelliğine erişmek gerekir. Bu derste, Dart kodunun Android'in Kotlin/Java'sıyla ya da iOS'un Swift/Objective-C'siyle nasıl "konuştuğunu" öğreneceğiz.

#Flutter'ın Native ile İlişkisi — Kısa Hatırlatma

Bölüm 1 Konu 1'de öğrendiğimiz mimariyi hatırla: Flutter, kendi widget'larını Skia/Impeller ile doğrudan ekrana çizer — yani native UI bileşenlerini kullanmaz (bir Android Button'ı ya da iOS UIButton'ı değildir, Flutter'ın kendi çizdiği bir dikdörtgendir). Ama Flutter uygulaması, sonuçta gerçek bir Android/iOS uygulamasının içinde çalışır — ve bazen, o native ortamın kendi API'lerine (kamera, konum, dosya sistemi, üçüncü parti SDK'lar) erişmek gerekir. Platform Channel, bu ihtiyacı karşılayan köprüdür.

#Temel Fikir — İki Taraf, Bir "Kanal İsmi"

┌─────────────────────┐         Platform Channel          ┌──────────────────────┐
│   Dart tarafı        │  ── 'com.ornek.app/pil' ──────►  │  Native taraf          │
│  (MethodChannel)     │  ◄── sonuç/hata ────────────────  │ (Kotlin veya Swift)    │
└─────────────────────┘                                    └──────────────────────┘

İki taraf da aynı string ismindeki bir kanalı kullanarak birbirini bulur — tıpkı Bölüm 7 Konu 30'da go_router'da bir rota ismiyle (path) eşleşme yapmamız gibi, burada da kanal ismi ('com.ornek.app/pil' gibi) eşleşme anahtarı.

#MethodChannel — Dart Tarafı

import 'package:flutter/services.dart';

class PilServisi {
  static const _kanal = MethodChannel('com.ornek.app/pil');

  static Future<int> pilSeviyesiniAl() async {
    try {
      final int seviye = await _kanal.invokeMethod('pilSeviyesiAl');
      return seviye;
    } on PlatformException catch (hata) {
      print('Pil seviyesi alınamadı: ${hata.message}');
      return -1;
    }
  }
}

Parça parça inceleyelim:

MethodChannel('com.ornek.app/pil') — kanalın adı, genelde paket.adi/ozellik formatında (çakışmayı önlemek için). Bu isim, native tarafta birebir aynı yazılmalı.

await _kanal.invokeMethod('pilSeviyesiAl') — Bölüm 5 Konu 18'de öğrendiğimiz async/await'i hatırla; native tarafa bir çağrı yapmak asenkron bir işlemdir (native kod çalışıp bir sonuç dönene kadar Dart bekler) — bu yüzden Future<int> döner.

on PlatformException catch (hata) — Dart Bölüm 8'de öğrendiğimiz özel exception yakalama; native taraftan bir hata gelirse (kod bulunamadı, native tarafta bir exception fırlatıldı vb.), bu PlatformException olarak Dart'a taşınır.

#Native Taraf — Android (Kotlin)

// android/app/src/main/kotlin/.../MainActivity.kt
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.MethodChannel

class MainActivity: FlutterActivity() {
    private val KANAL = "com.ornek.app/pil"

    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)
        MethodChannel(flutterEngine.dartExecutor.binaryMessenger, KANAL).setMethodCallHandler { call, result ->
            if (call.method == "pilSeviyesiAl") {
                val seviye = pilSeviyesiniGetir()
                if (seviye != -1) {
                    result.success(seviye)
                } else {
                    result.error("KULLANILAMIYOR", "Pil seviyesi alınamadı", null)
                }
            } else {
                result.notImplemented()
            }
        }
    }

    private fun pilSeviyesiniGetir(): Int {
        // gerçek Android API çağrısı burada olurdu
        return 85
    }
}

Kotlin bilmene gerek yok (bu tutorial'ın kapsamı dışında) — ama yapıyı tanıman önemli: call.method, Dart tarafındaki invokeMethod('pilSeviyesiAl') çağrısındaki string ile eşleşiyor (Bölüm 3 Konu 12'de öğrendiğimiz switch/if mantığına benzer bir yönlendirme). result.success(seviye), Dart tarafındaki await'in döndüreceği değeri belirliyor; result.error(...), Dart tarafında PlatformException olarak yakalanacak hatayı oluşturuyor.

#Native Taraf — iOS (Swift)

// ios/Runner/AppDelegate.swift
import Flutter
import UIKit

@main
@objc class AppDelegate: FlutterAppDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    let controller = window?.rootViewController as! FlutterViewController
    let kanal = FlutterMethodChannel(name: "com.ornek.app/pil", binaryMessenger: controller.binaryMessenger)

    kanal.setMethodCallHandler { (call, result) in
      if call.method == "pilSeviyesiAl" {
        result(85) // gerçek iOS API çağrısı burada olurdu
      } else {
        result(FlutterMethodNotImplemented)
      }
    }

    GeneratedPluginRegistrant.register(with: self)
    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }
}

Kritik gözlem: Aynı kanal ismi ("com.ornek.app/pil") ve aynı metod ismi ("pilSeviyesiAl"), hem Android hem iOS tarafında birebir aynı yazılmalı — Dart tarafındaki MethodChannel kodu, hangi platformda çalıştığını bilmez, sadece kanal ismiyle "doğru tarafı" bulur. Bu, Bölüm 7'de öğrendiğimiz interface/implementasyon ayrımına (bir Repository arayüzünün farklı implementasyonları gibi) kavramsal olarak benzer — Dart tarafı, hangi native implementasyonun çalıştığından habersiz, sadece sözleşmeye (kanal ismi + metod isimleri) güveniyor.

#EventChannel — Sürekli Veri Akışı İçin

MethodChannel, tek seferlik bir istek-cevap içindir (bir soru sor, bir cevap al). Native taraftan sürekli veri akması gerekiyorsa (örneğin bir sensörden gelen sürekli okuma), EventChannel kullanılır — Bölüm 5 Konu 19'da öğrendiğimiz Stream kavramının native köprü karşılığıdır:

class SensorServisi {
  static const _kanal = EventChannel('com.ornek.app/ivmeolcer');

  static Stream<double> ivmeVerisiAl() {
    return _kanal.receiveBroadcastStream().map((veri) => veri as double);
  }
}

StreamBuilder<double>( // Bölüm 5 Konu 19'u hatırla
  stream: SensorServisi.ivmeVerisiAl(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) return const CircularProgressIndicator();
    return Text('İvme: ${snapshot.data}');
  },
)

Native taraf, EventChannel'a bir EventSink üzerinden sürekli değer gönderir (sink.success(deger)), Dart tarafında bu, tanıdık bir Stream<double>'a dönüşür — Bölüm 5 Konu 19'daki StreamBuilder ile aynı şekilde tüketilir.

#Pratik Gerçek — Genelde Elle Yazmana Gerek Kalmaz

Önemli bir uyarı: Gerçek geliştirmede, çoğu zaman platform channel'ı elle yazman gerekmez — camera, geolocator, battery_plus, local_auth gibi hazır paketler, bu native köprüyü senin için zaten kurmuş durumda, sen sadece Dart tarafındaki basit API'yi çağırırsın (Bölüm 9 Konu 42'de kamera/konum paketlerini göreceğiz). Platform channel'ı elle yazmak, genelde şu durumlarda gerekir:

• Çok niş bir native SDK'ya erişim gerekiyor ve hazır bir Flutter paketi yok.
• Kendi bir Flutter paketini (plugin) yazıp yayınlıyorsun (Bölüm 12 Konu 58'de göreceğiz).
• Var olan bir native uygulamaya Flutter'ı entegre ediyorsun (add-to-app senaryosu).

#Pigeon — Daha Tip Güvenli Bir Alternatif

Yukarıdaki MethodChannel kodunda dikkat ettiysen, call.method bir string, dönüş değeri dinamik (Any/Object) — yazım hatası riski var, derleme zamanında yakalanmaz. Flutter ekibinin resmi olarak sunduğu pigeon paketi, bir arayüz tanımından (Dart'ta yazılan bir "şema" dosyasından) hem Dart hem Kotlin hem Swift tarafı için tip güvenli kod üretir (Dart Bölüm 13'te öğrendiğimiz build_runner code generation mantığına benzer). Büyük/uzun soluklu platform channel ihtiyaçlarında pigeon, elle MethodChannel yazmaktan daha sağlam bir tercihtir — bu tutorial kapsamında sadece var olduğunu bilmen yeterli.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Platform Channel, Dart kodu ile native (Kotlin/Swift) kod arasında, ortak bir kanal ismi üzerinden çalışan bir köprüdür.
• MethodChannel, tek seferlik istek-cevap iletişimi için kullanılır; invokeMethod() asenkron çalışır (Future döner), native taraftaki hatalar PlatformException olarak yakalanır.
• Native tarafta (Android: Kotlin, iOS: Swift), setMethodCallHandler ile gelen çağrılar call.method string'ine göre yönlendirilir, result.success()/result.error() ile cevap verilir.
• EventChannel, native taraftan sürekli veri akışı gerektiğinde kullanılır — Dart tarafında tanıdık bir Stream olarak tüketilir.
• Pratikte, çoğu native ihtiyaç zaten hazır paketlerle (camera, geolocator vb.) karşılanır — elle platform channel yazmak niş durumlar içindir.
• pigeon, elle yazılan MethodChannel koduna göre daha tip güvenli, code-generation tabanlı bir alternatiftir.

#📝 Ödevler

• [ ] Basit bir MethodChannel kur (Android veya iOS tarafında, hangisini geliştiriyorsan), sabit bir değer (örn. 42) döndüren bir native metod yaz ve Dart tarafından çağır.
• [ ] Native tarafta bilerek bir result.error(...) (Android) / hata durumu (iOS) tetikle, Dart tarafında PlatformException'ı yakalayıp ekranda göster.
• [ ] Kendi cümlelerinle, "MethodChannel ile EventChannel arasındaki farkın, Dart Bölüm 5'te öğrendiğimiz Future ile Stream arasındaki farka nasıl karşılık geldiğini" açıkla.
• [ ] battery_plus gibi hazır bir paketin kaynak koduna (pub.dev üzerinden GitHub'a) göz at, kendi native tarafında MethodChannel kullanıp kullanmadığını doğrula.

Sıradaki konu: Bölüm 9 — Konu 41: Permission Yönetimi (permission_handler)

Konu 40'ta native kodla elle nasıl konuşulacağını gördük. Bu derste, o mekanizmayı elle kurmana gerek bırakmayan, hazır ve çok yaygın kullanılan bir paketle — kullanıcıdan izin istemeyi (konum, kamera, bildirim vb.) öğreneceğiz. Bu, Konu 40'ın sonunda bahsettiğimiz "çoğu native ihtiyaç hazır paketlerle karşılanır" ilkesinin ilk somut örneği.

#Neden İzin Sistemi Var?

Hem Android hem iOS, kullanıcının mahremiyetini korumak için, bir uygulamanın hassas kaynaklara (konum, kamera, mikrofon, kişiler, bildirimler) erişmeden önce açıkça izin istemesini zorunlu kılar. Bu izinler çalışma zamanında (runtime) istenir — yani kullanıcı, uygulamayı kullanırken, tam da o özelliğe ihtiyaç duyulduğu anda bir izin diyaloğu görür (App Store/Play Store kurulumu sırasında değil).

#Paketi Ekleme ve Platform Ayarları

flutter pub add permission_handler

Paketi eklemek yeterli değildir — her platformun kendi manifest/plist dosyasında da hangi izinleri kullanacağını beyan etmen gerekir:

<!-- android/app/src/main/AndroidManifest.xml -->
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
<uses-permission android:name="android.permission.CAMERA"/>

<!-- ios/Runner/Info.plist -->
<key>NSLocationWhenInUseUsageDescription</key>
<string>Yakınındaki mağazaları gösterebilmek için konumuna ihtiyacımız var.</string>
<key>NSCameraUsageDescription</key>
<string>Profil fotoğrafı çekebilmen için kameraya ihtiyacımız var.</string>

Dikkat et — iOS'taki fark önemli: iOS'ta her izin için neden istediğini açıklayan bir metin (...UsageDescription) zorunludur — bu metin, kullanıcıya gösterilen izin diyaloğunda görünür. Bunu unutursan, uygulaman çalışma zamanında çökebilir (App Store, bu açıklama olmadan uygulamanı reddedebilir de).

#İzin İsteme — Temel Akış

import 'package:permission_handler/permission_handler.dart';

Future<void> konumIzniIste() async {
  final durum = await Permission.location.request();

  if (durum.isGranted) {
    print('İzin verildi, konum alınabilir');
  } else if (durum.isDenied) {
    print('Kullanıcı izni reddetti (tekrar sorulabilir)');
  } else if (durum.isPermanentlyDenied) {
    print('Kullanıcı kalıcı olarak reddetti — ayarlara yönlendirmemiz lazım');
    openAppSettings(); // paketin sunduğu hazır fonksiyon
  }
}

Permission.location — Dart Bölüm 7'de öğrendiğimiz enum benzeri sabit değerler kalıbı (Permission, paketin tanımladığı bir dizi sabit: .camera, .microphone, .contacts, .notification vb.).