Unidirectional Data Flow — τι είναι, UDF σε Android και iOS

Τι είναι το Unidirectional Data Flow;

Unidirectional Data Flow (UDF) — ένα αρχιτεκτονικό μοτίβο στο οποίο τα δεδομένα κινούνται προς μία κατεύθυνση κατά μήκος ενός κλειστού κύκλου, αποκλείοντας την ανατροφοδότηση μεταξύ View και Model. Σε αντίθεση με το Two-Way Binding, όπου μια αλλαγή στο UI ενημερώνει αμέσως το μοντέλο, το UDF απαιτεί μια ρητή ενέργεια (Intent, Event, Action) για κάθε αλλαγή κατάστασης. Αυτό καθιστά τη ροή δεδομένων πλήρως προβλέψιμη: ανά πάσα στιγμή μπορεί να προσδιοριστεί ποια ενέργεια οδήγησε στην τρέχουσα κατάσταση.

Η έννοια του UDF προέρχεται από διαδικτυακά πλαίσια — Redux (JavaScript, 2015) και Elm (2012) — και προσαρμόστηκε για κινητή ανάπτυξη. Σύμφωνα με το Google I/O 2024, το UDF έχει γίνει η συνιστώμενη αρχιτεκτονική για το Jetpack Compose, αντικαθιστώντας το κλασικό MVVM με LiveData. Στο iOS μια παρόμοια προσέγγιση υλοποιείται στο The Composable Architecture (TCA) από την Point-Free, το οποίο χρησιμοποιείται από πάνω από 15% των προγραμματιστών iOS σύμφωνα με την έρευνα Swift Community (2024).

Το κύριο πλεονέκτημα του UDF — Single Source of Truth (SSOT): ολόκληρη η κατάσταση της εφαρμογής αποθηκεύεται σε ένα μέρος και αλλάζει μέσω αυστηρά καθορισμένων λειτουργιών. Αυτό απλοποιεί τον εντοπισμό σφαλμάτων, τη δοκιμή και την αναπαραγωγή σφαλμάτων, καθώς κάθε αλλαγή κατάστασης καταγράφεται και μπορεί να αναπαραχθεί με εκ νέου αποστολή των ίδιων Intent.

Πώς λειτουργεί το UDF: κύκλος State → View → Intent → Reducer

Ο βασικός κύκλος UDF αποτελείται από τέσσερα βήματα: State (τρέχουσα κατάσταση) εμφανίζεται στο View· ο χρήστης εκτελεί μια ενέργεια που μετατρέπεται σε Intent (πρόθεση)· το Intent υποβάλλεται σε επεξεργασία στο Reducer (μια καθαρή συνάρτηση), η οποία δημιουργεί μια νέα State· η νέα κατάσταση μεταδίδεται στο View για ανασχεδιασμό. Αυτός ο κύκλος επαναλαμβάνεται σε κάθε συμβάν χρήστη ή συστήματος.

Κάθε στοιχείο του κύκλου έχει αυστηρή ευθύνη: State — ένα αμετάβλητο (immutable) αντικείμενο που περιγράφει την κατάσταση της οθόνης σε μια συγκεκριμένη στιγμή· View — μια συνάρτηση που εμφανίζει το State· Intent — μια τιμή που περιγράφει την πρόθεση του χρήστη (π.χ. LoginIntent.Submit)· Reducer — μια καθαρή συνάρτηση χωρίς παρενέργειες, που δέχεται το τρέχον State και Intent και επιστρέφει ένα νέο State. Οι παρενέργειες (αιτήματα δικτύου, βάση δεδομένων) μεταφέρονται σε ξεχωριστό επίπεδο Middleware ή Effect.

Σύμφωνα με το άρθρο Google Android Architecture (2024), η καθαρότητα του Reducer είναι βασική απαίτηση: εάν το Reducer περιέχει κλήση δικτύου ή εγγραφή στη βάση δεδομένων, η δοκιμή και ο εντοπισμός σφαλμάτων της ροής δεδομένων καθίσταται αδύνατη. Όλες οι παρενέργειες πρέπει να εκτελούνται στο coroutine του ViewModel ή στο Swift Task πριν από την κλήση του Reducer και το αποτέλεσμα να αποστέλλεται ως νέο Intent.

UDF στο Android: ViewModel + StateFlow + Intent

Στο Android η υλοποίηση του UDF βασίζεται σε τρία στοιχεία Jetpack: ViewModel διαχειρίζεται τον κύκλο ζωής, StateFlow παρέχει μια αντιδραστική ροή καταστάσεων, Intent (sealed class) περιγράφει όλες τις πιθανές ενέργειες του χρήστη. Το View εγγράφεται στο StateFlow μέσω collectAsState() στο Compose ή observe() στο σύστημα View.

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) }
    )
}

Το παράδειγμα δείχνει τον πλήρη κύκλο UDF στο Android: LoginIntent περιγράφει όλες τις πιθανές ενέργειες (αλλαγή email, κωδικού πρόσβασης, υποβολή φόρμας), LoginState — την αμετάβλητη κατάσταση, LoginViewModel επεξεργάζεται τα Intent και ενημερώνει το StateFlow, και η οθόνη Compose εγγράφεται στην κατάσταση μέσω collectAsState(). Κάθε αλλαγή κατάστασης είναι αποτέλεσμα επεξεργασίας ενός συγκεκριμένου Intent, καθιστώντας τη ροή δεδομένων πλήρως διαφανή.

UDF στο iOS: TCA και μοτίβο Observable

Στο iOS το UDF υλοποιείται μέσω The Composable Architecture (TCA) από την Point-Free ή του εγγενούς μοτίβου Observable με iOS 17+. Το TCA παρέχει έναν έτοιμο κύκλο State + Action + Reducer + Store, όπου το Store είναι η μοναδική πηγή αλήθειας και το View εγγράφεται σε αλλαγές μέσω @Observable ή ObservableObject.

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("Σύνδεση") { viewStore.send(.submit) }
            }
        }
    }
}

Ο αναγωγέας loginReducer — μια καθαρή συνάρτηση: δεν εκτελεί άμεσα αιτήματα δικτύου, αλλά επιστρέφει ένα Effect που θα εκτελεστεί από το περιβάλλον TCA. Αυτό επιτρέπει τη δοκιμή του αναγωγέα απομονωμένα, αντικαθιστώντας τα εφέ στις δοκιμές. Το View μέσω του WithViewStore εγγράφεται στις αλλαγές του Store και στέλνει Action μέσω send(). Το TCA διαχειρίζεται αυτόματα την ακύρωση εφέ κατά την καταστροφή του Store, αποτρέποντας διαρροές μνήμης.

UDF εναντίον MVVM: ποια είναι η διαφορά;

MVVM και UDF συχνά συγχέονται, αλλά υπάρχει θεμελιώδης διαφορά μεταξύ τους. Το MVVM είναι ένα δομικό μοτίβο που χωρίζει τον κώδικα σε τρία επίπεδα (Model, View, ViewModel), αλλά δεν καθορίζει την κατεύθυνση της ροής δεδομένων. Το UDF είναι ένα μοτίβο συμπεριφοράς που περιγράφει πώς κινούνται τα δεδομένα εντός αυτής της δομής. Στο MVVM με LiveData μπορεί να υπάρχει τόσο αμφίδρομη σύνδεση όσο και μονόδρομη ροή — το UDF προσθέτει αυστηρούς κανόνες επεξεργασίας Intent στο MVVM.

Σύμφωνα με την τεκμηρίωση Android Developers (2024), η συνιστώμενη αρχιτεκτονική για το Compose είναι UDF εντός MVVM: το ViewModel αποθηκεύει το State και επεξεργάζεται τα Intent, το View εγγράφεται στο State και στέλνει Intent. Το κλασικό MVVM με Two-Way Binding μέσω DataBinding συνιστάται από την Google μόνο για απλές οθόνες χωρίς επιχειρηματική λογική. Για το Jetpack Compose το κύριο σενάριο είναι UDF με ρητή επεξεργασία συμβάντων.

Πίνακας σύγκρισης:

Συνήθη λάθη κατά την εφαρμογή του UDF

Το πιο συνηθισμένο λάθος — παρενέργειες εντός του Reducer. Οι προγραμματιστές που έχουν συνηθίσει στο MVVM τοποθετούν αιτήματα δικτύου απευθείας στο χειριστή Intent, καθιστώντας το Reducer μια μη καθαρή συνάρτηση και καταστρέφοντας τη δυνατότητα δοκιμής. Όλα τα εφέ πρέπει να επιστρέφονται ως τιμή (Effect / SideEffect) και να εκτελούνται από την υποδομή του πλαισίου. Στο Android χρησιμοποιούνται coroutine στο ViewModel, στο TCA — Effect.run.

Το δεύτερο λάθος — υπερβολικά λεπτομερή Intent. Κάθε πάτημα πλήκτρου, κίνηση ολισθητήρα και αλλαγή κειμένου δημιουργεί ξεχωριστό Intent. Για πεδία εισόδου αυτό είναι υπερβολικό — σε τέτοιες περιπτώσεις είναι αποδεκτή η χρήση Binding με μονόδρομη ροή εντός της φόρμας (τοπική κατάσταση) και η αποστολή καθολικού Intent μόνο σε σημαντικές ενέργειες (υποβολή, πλοήγηση).

Το τρίτο λάθος — έλλειψη χειρισμού ακύρωσης εφέ. Εάν ο χρήστης εγκαταλείψει την οθόνη και το coroutine ή το Task συνεχίσει να εκτελείται, το αποτέλεσμα μπορεί να εφαρμοστεί σε μια ήδη κατεστραμμένη View. Στο Android χρησιμοποιήστε viewModelScope.cancel() ή takeWhileActive()· στο TCA τα εφέ ακυρώνονται αυτόματα κατά την καταστροφή του Store. Σύμφωνα με το Google Issue Tracker (2024), οι διαρροές από ημιτελή coroutine βρίσκονται στις top-5 αιτίες σφαλμάτων εφαρμογών Compose.