Tek Yönlü Veri Akışı — Nedir, Android ve iOS'ta UDF

Tek Yönlü Veri Akışı Nedir?

Tek Yönlü Veri Akışı (UDF), verilerin kapalı bir döngüde tek yönde hareket ettiği ve View ile Model arasındaki geri bildirim döngülerini ortadan kaldıran bir mimari desendir. UI'daki bir değişikliğin modeli hemen güncellediği İki Yönlü Bağlama'nın aksine, UDF her durum değişikliği için açık bir eylem (Intent, Event, Action) gerektirir. Bu, veri akışını tamamen öngörülebilir kılar: herhangi bir zamanda, hangi eylemin mevcut duruma yol açtığı belirlenebilir.

UDF kavramı web çerçevelerinden — Redux (JavaScript, 2015) ve Elm (2012) — gelmiştir ve mobil geliştirme için uyarlanmıştır. Google I/O 2024'e göre UDF, LiveData ile klasik MVVM'nin yerini alarak Jetpack Compose için önerilen mimari haline gelmiştir. iOS'ta, Point-Free tarafından The Composable Architecture (TCA)'da benzer bir yaklaşım uygulanmıştır ve Swift Community Survey (2024)'e göre iOS geliştiricilerinin %15'inden fazlası tarafından kullanılmaktadır.

UDF'nin ana avantajı Tek Bir Gerçek Kaynağıdır (SSOT): tüm uygulama durumu tek bir yerde depolanır ve kesin olarak tanımlanmış işlemlerle değiştirilir. Bu, hata ayıklamayı, test etmeyi ve hata yeniden üretimini basitleştirir, çünkü her durum değişikliği günlüğe kaydedilir ve aynı Intent'ler yeniden gönderilerek yeniden üretilebilir.

UDF Nasıl Çalışır: State → View → Intent → Reducer Döngüsü

Temel UDF döngüsü dört adımdan oluşur: State (mevcut durum) View'da oluşturulur; kullanıcı bir eylem gerçekleştirir ve bu bir Intent haline gelir; Intent bir Reducer'da (saf fonksiyon) işlenir ve yeni bir State oluşturur; yeni durum yeniden oluşturma için View'a iletilir. Bu döngü her kullanıcı veya sistem olayında tekrarlanır.

Döngünün her bir öğesinin katı bir sorumluluğu vardır: State — belirli bir andaki ekran durumunu tanımlayan değişmez bir nesne; View — State'i oluşturan bir fonksiyon; Intent — kullanıcının niyetini tanımlayan bir değer (örneğin, LoginIntent.Submit); Reducer — yan etkileri olmayan, mevcut State ve Intent'i alan ve yeni bir State döndüren saf bir fonksiyon. Yan etkiler (ağ istekleri, veritabanı işlemleri) ayrı bir Middleware veya Effect katmanına taşınır.

Google Android Architecture makalesine (2024) göre, Reducer'ın saflığı önemli bir gerekliliktir: Bir Reducer bir ağ çağrısı veya veritabanı yazma işlemi içeriyorsa, veri akışını test etmek ve hata ayıklamak imkansız hale gelir. Tüm yan etkiler, Reducer'ı çağırmadan önce bir ViewModel coroutine'i veya Swift Task'ında yürütülmeli ve sonuç yeni bir Intent olarak gönderilmelidir.

Android'de UDF: ViewModel + StateFlow + Intent

Android'de UDF uygulaması üç Jetpack bileşeni üzerine kurulmuştur: ViewModel yaşam döngüsünü yönetir, StateFlow reaktif bir durum akışı sağlar, Intent (sealed class) olası tüm kullanıcı eylemlerini tanımlar. View, Compose'da collectAsState() veya View sisteminde observe() aracılığıyla StateFlow'a abone olur.

sealed class LoginIntent {
    data object Submit : LoginIntent()
    data class UpdateEmail(val value: String) : LoginIntent()
    data class UpdatePassword(val value: String) : LoginIntent()
}

data class LoginState(
    val email: String = "",
    val password: String = "",
    val isLoading: Boolean = false,
    val error: String? = null
)

class LoginViewModel : ViewModel() {
    private val _state = MutableStateFlow(LoginState())
    val state: StateFlow<LoginState> = _state.asStateFlow()

    fun onIntent(intent: LoginIntent) {
        when (intent) {
            is LoginIntent.UpdateEmail -> {
                _state.update { it.copy(email = intent.value) }
            }
            is LoginIntent.UpdatePassword -> {
                _state.update { it.copy(password = intent.value) }
            }
            is LoginIntent.Submit -> {
                _state.update { it.copy(isLoading = true, error = null) }
                loginUseCase(_state.value.email, _state.value.password)
                    .onSuccess {
                        _state.update { it.copy(isLoading = false) }
                    }
                    .onFailure { e ->
                        _state.update { it.copy(isLoading = false, error = e.message) }
                    }
            }
        }
    }
}

@Composable
fun LoginScreen(viewModel: LoginViewModel) {
    val state by viewModel.state.collectAsState()

    LoginForm(
        email = state.email,
        onEmailChange = { viewModel.onIntent(LoginIntent.UpdateEmail(it)) },
        password = state.password,
        onPasswordChange = { viewModel.onIntent(LoginIntent.UpdatePassword(it)) },
        isLoading = state.isLoading,
        onSubmit = { viewModel.onIntent(LoginIntent.Submit) }
    )
}

Örnek, Android'deki tam UDF döngüsünü göstermektedir: LoginIntent olası tüm eylemleri (e-posta değişikliği, şifre değişikliği, form gönderimi) tanımlar, LoginState değişmez durumdur, LoginViewModel Intent'leri işler ve StateFlow'u günceller ve Compose ekranı collectAsState() aracılığıyla duruma abone olur. Her durum değişikliği, belirli bir Intent'in işlenmesinin sonucudur ve bu da veri akışını tamamen şeffaf hale getirir.

iOS'ta UDF: TCA ve Observable Deseni

iOS'ta UDF, The Composable Architecture (TCA) (Point-Free) veya iOS 17+ ile yerel Observable deseni aracılığıyla uygulanır. TCA, State + Action + Reducer + Store'un hazır bir döngüsünü sağlar; burada Store tek gerçek kaynağıdır ve View, @Observable veya ObservableObject aracılığıyla değişikliklere abone olur.

struct LoginState: Equatable {
    var email = ""
    var password = ""
    var isLoading = false
    var error: String?
}

enum LoginAction {
    case emailChanged(String)
    case passwordChanged(String)
    case submit
    case loginResponse(Result<User, Error>)
}

let loginReducer = Reducer<LoginState, LoginAction> { state, action in
    switch action {
    case .emailChanged(let email):
        state.email = email
        return .none
    case .passwordChanged(let password):
        state.password = password
        return .none
    case .submit:
        state.isLoading = true
        state.error = nil
        return .run { send in
            let result = await loginUseCase(state.email, state.password)
            await send(.loginResponse(result))
        }
    case .loginResponse(.success):
        state.isLoading = false
        return .none
    case .loginResponse(.failure(let error)):
        state.isLoading = false
        state.error = error.localizedDescription
        return .none
    }
}

struct LoginView: View {
    let store: StoreOf<LoginReducer>

    var body: some View {
        WithViewStore(store, observe: { $0 }) { viewStore in
            Form {
                TextField("Email", text: viewStore.binding(get: \.email, send: { .emailChanged($0) }))
                SecureField("Password", text: viewStore.binding(get: \.password, send: { .passwordChanged($0) }))
                Button("Giriş Yap") { viewStore.send(.submit) }
            }
        }
    }
}

loginReducer saf bir fonksiyondur: ağ isteklerini doğrudan gerçekleştirmez, bunun yerine TCA çalışma zamanı tarafından yürütülecek bir Effect döndürür. Bu, testlerde efektleri değiştirerek indirgeyicinin izole bir şekilde test edilmesine olanak tanır. View, WithViewStore aracılığıyla Store değişikliklerine abone olur ve send() aracılığıyla Actions gönderir. TCA, Store yok edildiğinde efektlerin iptalini otomatik olarak yöneterek bellek sızıntılarını önler.

UDF ve MVVM: Fark Nedir?

MVVM ve UDF sıklıkla karıştırılır, ancak aralarında temel bir fark vardır. MVVM, kodu üç katmana (Model, View, ViewModel) ayıran yapısal bir desendir ancak veri akışının yönünü tanımlamaz. UDF, verilerin bu yapı içinde nasıl hareket ettiğini tanımlayan bir davranış desenidir. LiveData ile MVVM'de hem iki yönlü bağlama hem de tek yönlü akış mümkündür — UDF, MVVM'ye katı Intent işleme kuralları ekler.

Android Developers belgelerine (2024) göre, Compose için önerilen mimari MVVM içinde UDF'dir: ViewModel State'i depolar ve Intent'leri işler, View State'e abone olur ve Intent'leri gönderir. Google, DataBinding aracılığıyla İki Yönlü Bağlama ile klasik MVVM'yi yalnızca iş mantığı olmayan basit ekranlar için önermektedir. Jetpack Compose için birincil senaryo, açık olay işleme ile UDF'dir.

Karşılaştırma tablosu:

UDF Uygularken Yapılan Yaygın Hatalar

En yaygın hata Reducer içindeki yan etkilerdir. MVVM'ye alışkın geliştiriciler ağ isteklerini doğrudan Intent işleyicisine yerleştirir, bu da Reducer'ı saf olmayan hale getirir ve test edilebilirliği bozar. Tüm efektler bir değer (Effect / SideEffect) olarak döndürülmeli ve çerçeve altyapısı tarafından yürütülmelidir. Android'de bunun için ViewModel'de coroutine'ler kullanılır; TCA'da — Effect.run.

İkinci hata aşırı ayrıntılı Intent'lerdir. Her tuş vuruşu, kaydırıcı hareketi ve metin değişikliği ayrı bir Intent oluşturur. Giriş alanları için bu aşırıdır — bu gibi durumlarda, form içinde tek yönlü akışla Bağlama (yerel durum) kullanmak ve yalnızca önemli eylemler (gönderme, gezinme) için genel bir Intent göndermek kabul edilebilir.

Üçüncü hata efekt iptali işleme eksikliğidir. Kullanıcı ekrandan ayrıldığında bir coroutine veya Task hala yürütülüyorsa, sonuç zaten yok edilmiş bir View'a uygulanabilir. Android'de viewModelScope.cancel() veya takeWhileActive() kullanın; TCA'da efektler Store yok edildiğinde otomatik olarak iptal edilir. Google Issue Tracker (2024)'e göre, tamamlanmamış coroutine'lerden kaynaklanan sızıntılar Compose uygulamalarında ilk 5 çökme nedeni arasındadır.