Eventi UI

Gli eventi di UI sono azioni che devono essere gestite nel livello UI dall'interfaccia utente o dal modello ViewModel. I tipi più comuni di eventi sono gli eventi utente. L'utente genera eventi utente interagendo con l'app, ad esempio toccando lo schermo o generando gesti. La UI consuma quindi questi eventi utilizzando callback come i listener onClick().

Termini chiave:

• Interfaccia utente: codice basato sulle visualizzazioni o Scrivi che gestisce l'interfaccia utente.
• Eventi UI: azioni che devono essere gestite nel livello UI.
• Eventi utente: eventi generati dall'utente durante l'interazione con l'app.

ViewModel è normalmente responsabile della gestione della logica di business di un determinato evento utente, ad esempio l'utente che fa clic su un pulsante per aggiornare alcuni dati. Di solito, ViewModel gestisce questo problema esponendo funzioni che l'interfaccia utente può chiamare. Gli eventi utente potrebbero anche avere una logica di comportamento della UI che la UI può gestire direttamente, ad esempio la navigazione su una schermata diversa o la visualizzazione di un elemento Snackbar.

Sebbene la logica di business rimanga la stessa per la stessa app su piattaforme mobile o fattori di forma diversi, la logica di comportamento dell'interfaccia utente è un dettaglio di implementazione che potrebbe differire tra i due casi. La pagina del livello UI definisce questi tipi di logica come segue:

• La logica di business si riferisce a cosa fare con i cambiamenti di stato, ad esempio, effettuare un pagamento o memorizzare le preferenze utente. I livelli di dominio e dati di solito gestiscono questa logica. In questa guida, la classe ViewModel dei componenti di architettura viene utilizzata come soluzione alternativa per le classi che gestiscono la logica di business.
• La logica del comportamento dell'interfaccia utente o la logica dell'interfaccia utente fa riferimento a come visualizzare le modifiche di stato, ad esempio la logica di navigazione o come mostrare i messaggi all'utente. L'UI gestisce questa logica.

Nota: i consigli e le best practice presenti in questa pagina possono essere applicati a un ampio spettro di app per consentire la scalabilità, il miglioramento della qualità e la solidità e la facilità di test. Tuttavia, dovresti trattarle come linee guida e adattarle alle tue esigenze, se necessario.

Struttura decisionale dell'evento UI

Il seguente diagramma mostra un albero decisionale per trovare l'approccio migliore per la gestione di un particolare caso d'uso di un evento. La parte rimanente di questa guida spiega questi approcci in dettaglio.

Figura 1. Albero decisionale per la gestione degli eventi.

Gestire gli eventi utente

La UI può gestire direttamente gli eventi utente se questi sono correlati alla modifica dello stato di un elemento dell'interfaccia utente, ad esempio lo stato di un elemento espandibile. Se l'evento richiede l'esecuzione di una logica di business, ad esempio l'aggiornamento dei dati sullo schermo, deve essere elaborato dal ViewModel.

L'esempio seguente mostra come vengono utilizzati diversi pulsanti per espandere un elemento dell'interfaccia utente (logica UI) e aggiornare i dati sullo schermo (logica di business):

Visualizzazioni

class LatestNewsActivity : AppCompatActivity() {

    private lateinit var binding: ActivityLatestNewsBinding
    private val viewModel: LatestNewsViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        // The expand details event is processed by the UI that
        // modifies a View's internal state.
        binding.expandButton.setOnClickListener {
            binding.expandedSection.visibility = View.VISIBLE
        }

        // The refresh event is processed by the ViewModel that is in charge
        // of the business logic.
        binding.refreshButton.setOnClickListener {
            viewModel.refreshNews()
        }
    }
}

Scrivi

@Composable
fun LatestNewsScreen(viewModel: LatestNewsViewModel = viewModel()) {

    // State of whether more details should be shown
    var expanded by remember { mutableStateOf(false) }

    Column {
        Text("Some text")
        if (expanded) {
            Text("More details")
        }

        Button(
          // The expand details event is processed by the UI that
          // modifies this composable's internal state.
          onClick = { expanded = !expanded }
        ) {
          val expandText = if (expanded) "Collapse" else "Expand"
          Text("$expandText details")
        }

        // The refresh event is processed by the ViewModel that is in charge
        // of the UI's business logic.
        Button(onClick = { viewModel.refreshNews() }) {
            Text("Refresh data")
        }
    }
}

Eventi utente in RecyclerView

Se l'azione viene prodotta più in basso nella struttura ad albero dell'interfaccia utente, ad esempio in un elemento RecyclerView o in una View personalizzata, ViewModel deve comunque essere quella che gestisce gli eventi utente.

Ad esempio, supponiamo che tutte le notizie di NewsActivity contengano un pulsante segnalibro. ViewModel deve conoscere l'ID della notizia aggiunta ai preferiti. Quando l'utente aggiunge una notizia ai preferiti, l'adattatore RecyclerView non chiama la funzione addBookmark(newsId) esposta da ViewModel, il che richiederebbe una dipendenza da ViewModel. Invece, ViewModel espone un oggetto di stato chiamato NewsItemUiState che contiene l'implementazione per la gestione dell'evento:

data class NewsItemUiState(
    val title: String,
    val body: String,
    val bookmarked: Boolean = false,
    val publicationDate: String,
    val onBookmark: () -> Unit
)

class LatestNewsViewModel(
    private val formatDateUseCase: FormatDateUseCase,
    private val repository: NewsRepository
)
    val newsListUiItems = repository.latestNews.map { news ->
        NewsItemUiState(
            title = news.title,
            body = news.body,
            bookmarked = news.bookmarked,
            publicationDate = formatDateUseCase(news.publicationDate),
            // Business logic is passed as a lambda function that the
            // UI calls on click events.
            onBookmark = {
                repository.addBookmark(news.id)
            }
        )
    }
}

In questo modo, l'adattatore RecyclerView funziona solo con i dati necessari: l'elenco di oggetti NewsItemUiState. L'adattatore non ha accesso all'intero modello ViewModel, il che riduce le probabilità di utilizzare in modo illecito la funzionalità esposta dal modello. Quando si consente solo alla classe attività di lavorare con ViewModel, le responsabilità vengono separate. Ciò garantisce che gli oggetti specifici dell'interfaccia utente come le viste o gli adattatori RecyclerView non interagiscano direttamente con ViewModel.

Avviso: non è consigliabile passare ViewModel all'adattatore RecyclerView perché questo accoppia l'adattatore con la classe ViewModel.

Nota: un altro pattern comune è che l'adattatore RecyclerView abbia un'interfaccia Callback per le azioni utente. In questo caso, l'attività o il frammento possono gestire l'associazione e chiamare le funzioni ViewModel direttamente dall'interfaccia di callback.

Convenzioni di denominazione per le funzioni di eventi utente

In questa guida, alle funzioni ViewModel che gestiscono gli eventi utente viene assegnato un nome con un verbo in base all'azione che gestiscono, ad esempio: addBookmark(id) o logIn(username, password).

Gestire gli eventi ViewModel

Le azioni dell'interfaccia utente che hanno origine dagli eventi ViewModel - ViewModel devono sempre generare un aggiornamento dello stato UI. Questo è conforme ai principi di Unidirectional Data Flow. Rende riproducibili gli eventi dopo le modifiche alla configurazione e garantisce che le azioni della UI non andranno perse. Facoltativamente, puoi anche rendere gli eventi riproducibili dopo l'interruzione del processo se utilizzi il modulo dello stato salvato.

La mappatura delle azioni dell'interfaccia utente allo stato della UI non è sempre un processo semplice, ma porta a una logica più semplice. Ad esempio, il tuo processo mentale non deve finire con la determinazione di come impostare l'interfaccia utente su una schermata specifica. Devi valutare ulteriormente come rappresentare il flusso di utenti nello stato della tua interfaccia utente. In altre parole: non pensare alle azioni che deve compiere la UI, ma a come queste azioni influiscono sullo stato dell'interfaccia utente.

Punto chiave: gli eventi ViewModel devono sempre comportare un aggiornamento dello stato dell'interfaccia utente.

Ad esempio, considera il caso di accedere alla schermata Home quando l'utente ha eseguito l'accesso dalla schermata di accesso. Puoi modellarlo nello stato dell'interfaccia utente nel seguente modo:

data class LoginUiState(
    val isLoading: Boolean = false,
    val errorMessage: String? = null,
    val isUserLoggedIn: Boolean = false
)

Questa UI reagisce alle modifiche allo stato isUserLoggedIn e passa alla destinazione corretta in base alle esigenze:

Visualizzazioni

class LoginViewModel : ViewModel() {
    private val _uiState = MutableStateFlow(LoginUiState())
    val uiState: StateFlow<LoginUiState> = _uiState.asStateFlow()
    /* ... */
}

class LoginActivity : AppCompatActivity() {
    private val viewModel: LoginViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { uiState ->
                    if (uiState.isUserLoggedIn) {
                        // Navigate to the Home screen.
                    }
                    ...
                }
            }
        }
    }
}

Scrivi

class LoginViewModel : ViewModel() {
    var uiState by mutableStateOf(LoginUiState())
        private set
    /* ... */
}

@Composable
fun LoginScreen(
    viewModel: LoginViewModel = viewModel(),
    onUserLogIn: () -> Unit
) {
    val currentOnUserLogIn by rememberUpdatedState(onUserLogIn)

    // Whenever the uiState changes, check if the user is logged in.
    LaunchedEffect(viewModel.uiState)  {
        if (viewModel.uiState.isUserLoggedIn) {
            currentOnUserLogIn()
        }
    }

    // Rest of the UI for the login screen.
}

Nota: gli esempi di codice in questa sezione richiedono una conoscenza delle coroutine e come utilizzarle con componenti sensibili al ciclo di vita.

L'utilizzo di eventi può attivare aggiornamenti dello stato

L'utilizzo di determinati eventi ViewModel nella UI potrebbe comportare aggiornamenti dello stato di altri UI. Ad esempio, quando vengono mostrati messaggi temporanei sullo schermo per comunicare all'utente che è successo qualcosa, l'interfaccia utente deve notificare al ViewModel di attivare un altro aggiornamento dello stato quando il messaggio viene mostrato sullo schermo. L'evento che si verifica quando l'utente ha utilizzato il messaggio (ignorandolo o dopo un timeout) può essere considerato come "input utente" e, come tale, ViewModel deve esserne consapevole. In questa situazione, lo stato dell'interfaccia utente può essere modellato come segue:

// Models the UI state for the Latest news screen.
data class LatestNewsUiState(
    val news: List<News> = emptyList(),
    val isLoading: Boolean = false,
    val userMessage: String? = null
)

ViewModel aggiorna lo stato dell'interfaccia utente come segue quando la logica di business richiede di mostrare un nuovo messaggio temporaneo all'utente:

Visualizzazioni

class LatestNewsViewModel(/* ... */) : ViewModel() {

    private val _uiState = MutableStateFlow(LatestNewsUiState(isLoading = true))
    val uiState: StateFlow<LatestNewsUiState> = _uiState

    fun refreshNews() {
        viewModelScope.launch {
            // If there isn't internet connection, show a new message on the screen.
            if (!internetConnection()) {
                _uiState.update { currentUiState ->
                    currentUiState.copy(userMessage = "No Internet connection")
                }
                return@launch
            }

            // Do something else.
        }
    }

    fun userMessageShown() {
        _uiState.update { currentUiState ->
            currentUiState.copy(userMessage = null)
        }
    }
}

Scrivi

class LatestNewsViewModel(/* ... */) : ViewModel() {

    var uiState by mutableStateOf(LatestNewsUiState())
        private set

    fun refreshNews() {
        viewModelScope.launch {
            // If there isn't internet connection, show a new message on the screen.
            if (!internetConnection()) {
                uiState = uiState.copy(userMessage = "No Internet connection")
                return@launch
            }

            // Do something else.
        }
    }

    fun userMessageShown() {
        uiState = uiState.copy(userMessage = null)
    }
}

Il ViewModel non ha bisogno di sapere come l'UI mostra il messaggio sullo schermo, sa solo che c'è un messaggio utente che deve essere mostrato. Una volta mostrato il messaggio temporaneo, l'interfaccia utente deve notificarlo al ViewModel, causando un altro aggiornamento dello stato della UI per cancellare la proprietà userMessage:

Visualizzazioni

class LatestNewsActivity : AppCompatActivity() {
    private val viewModel: LatestNewsViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { uiState ->
                    uiState.userMessage?.let {
                        // TODO: Show Snackbar with userMessage.

                        // Once the message is displayed and
                        // dismissed, notify the ViewModel.
                        viewModel.userMessageShown()
                    }
                    ...
                }
            }
        }
    }
}

Scrivi

@Composable
fun LatestNewsScreen(
    snackbarHostState: SnackbarHostState,
    viewModel: LatestNewsViewModel = viewModel(),
) {
    // Rest of the UI content.

    // If there are user messages to show on the screen,
    // show it and notify the ViewModel.
    viewModel.uiState.userMessage?.let { userMessage ->
        LaunchedEffect(userMessage) {
            snackbarHostState.showSnackbar(userMessage)
            // Once the message is displayed and dismissed, notify the ViewModel.
            viewModel.userMessageShown()
        }
    }
}

Anche se il messaggio è temporaneo, lo stato dell'interfaccia utente è una rappresentazione fedele di ciò che viene visualizzato sullo schermo in ogni singolo momento. Può essere visualizzato o meno il messaggio per l'utente.

Nota: per un caso d'uso più avanzato con un elenco di messaggi per gli utenti da mostrare sullo schermo, consulta l'esempio di Jetsnack Compose.

Eventi di navigazione

La sezione L'utilizzo di eventi può attivare aggiornamenti dello stato descrive nel dettaglio come utilizzare lo stato dell'interfaccia utente per visualizzare i messaggi per gli utenti sullo schermo. Anche gli eventi di navigazione sono un tipo comune di eventi nelle app per Android.

Se l'evento viene attivato nella UI perché l'utente ha toccato un pulsante, l'interfaccia utente lo gestisce chiamando il controller di navigazione o esponendo l'evento al chiamante come componibile.

Visualizzazioni

class LoginActivity : AppCompatActivity() {

    private lateinit var binding: ActivityLoginBinding
    private val viewModel: LoginViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        binding.helpButton.setOnClickListener {
            navController.navigate(...) // Open help screen
        }
    }
}

Scrivi

@Composable
fun LoginScreen(
    onHelp: () -> Unit, // Caller navigates to the right screen
    viewModel: LoginViewModel = viewModel()
) {
    // Rest of the UI

    Button(onClick = onHelp) {
        Text("Get help")
    }
}

Se l'input dei dati richiede una convalida della logica di business prima della navigazione, il ViewModel deve esporre questo stato all'interfaccia utente. L'interfaccia utente reagisce al cambiamento di stato e si sposta di conseguenza. La sezione Gestire gli eventi ViewModel descrive questo caso d'uso. Ecco un codice simile:

Visualizzazioni

class LoginActivity : AppCompatActivity() {
    private val viewModel: LoginViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        /* ... */

        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { uiState ->
                    if (uiState.isUserLoggedIn) {
                        // Navigate to the Home screen.
                    }
                    ...
                }
            }
        }
    }
}

Scrivi

@Composable
fun LoginScreen(
    onUserLogIn: () -> Unit, // Caller navigates to the right screen
    viewModel: LoginViewModel = viewModel()
) {
    Button(
        onClick = {
            // ViewModel validation is triggered
            viewModel.login()
        }
    ) {
        Text("Log in")
    }
    // Rest of the UI

    val lifecycle = LocalLifecycleOwner.current.lifecycle
    val currentOnUserLogIn by rememberUpdatedState(onUserLogIn)
    LaunchedEffect(viewModel, lifecycle)  {
        // Whenever the uiState changes, check if the user is logged in and
        // call the `onUserLogin` event when `lifecycle` is at least STARTED
        snapshotFlow { viewModel.uiState }
            .filter { it.isUserLoggedIn }
            .flowWithLifecycle(lifecycle)
            .collect {
                currentOnUserLogIn()
            }
    }
}

Nell'esempio precedente, l'app funziona come previsto perché la destinazione corrente, Login, non verrebbe mantenuta nello stack di backup. Gli utenti non possono tornare indietro se premono Indietro. Tuttavia, nei casi in cui ciò può accadere, la soluzione richiederebbe una logica aggiuntiva.

Eventi di navigazione quando la destinazione viene mantenuta nello stack posteriore

Quando un ViewModel imposta uno stato che produce un evento di navigazione dalla schermata A alla schermata B e la schermata A viene mantenuta nello stack di navigazione posteriore, potrebbe essere necessaria una logica aggiuntiva per non continuare ad avanzare automaticamente alla schermata B. Per implementare questa funzionalità, è necessario disporre di uno stato aggiuntivo che indichi se l'interfaccia utente deve considerare il passaggio all'altra schermata. Normalmente, questo stato si trova nell'interfaccia utente, perché la logica di navigazione è un problema dell'interfaccia utente, non del ViewModel. Per spiegare meglio, prendiamo in considerazione il caso d'uso che segue.

Supponiamo che ti trovi nel flusso di registrazione della tua app. Nella schermata di convalida della data di nascita, quando l'utente inserisce una data, questa viene convalidata dal ViewModel quando l'utente tocca il pulsante "Continua". ViewModel delega la logica di convalida al livello dati. Se la data è valida, l'utente passa alla schermata successiva. Come ulteriore funzionalità, gli utenti possono spostarsi tra le diverse schermate di registrazione nel caso in cui vogliano modificare alcuni dati. Di conseguenza, tutte le destinazioni nel flusso di registrazione vengono mantenute nello stesso back stack. Dati questi requisiti, puoi implementare questa schermata nel seguente modo:

Visualizzazioni

// Key that identifies the `validationInProgress` state in the Bundle
private const val DOB_VALIDATION_KEY = "dobValidationKey"

class DobValidationFragment : Fragment() {

    private var validationInProgress: Boolean = false
    private val viewModel: DobValidationViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        val binding = // ...
        validationInProgress = savedInstanceState?.getBoolean(DOB_VALIDATION_KEY) ?: false

        binding.continueButton.setOnClickListener {
            viewModel.validateDob()
            validationInProgress = true
        }

        viewLifecycleOwner.lifecycleScope.launch {
            viewModel.uiState
                .flowWithLifecycle(viewLifecycleOwner.lifecycle)
                .collect { uiState ->
                    // Update other parts of the UI ...

                    // If the input is valid and the user wants
                    // to navigate, navigate to the next screen
                    // and reset `validationInProgress` flag
                    if (uiState.isDobValid && validationInProgress) {
                        validationInProgress = false
                        navController.navigate(...) // Navigate to next screen
                    }
                }
        }

        return binding
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putBoolean(DOB_VALIDATION_KEY, validationInProgress)
    }
}

Scrivi

class DobValidationViewModel(/* ... */) : ViewModel() {
    var uiState by mutableStateOf(DobValidationUiState())
        private set
}

@Composable
fun DobValidationScreen(
    onNavigateToNextScreen: () -> Unit, // Caller navigates to the right screen
    viewModel: DobValidationViewModel = viewModel()
) {
    // TextField that updates the ViewModel when a date of birth is selected

    var validationInProgress by rememberSaveable { mutableStateOf(false) }

    Button(
        onClick = {
            viewModel.validateInput()
            validationInProgress = true
        }
    ) {
        Text("Continue")
    }
    // Rest of the UI

    /*
     * The following code implements the requirement of advancing automatically
     * to the next screen when a valid date of birth has been introduced
     * and the user wanted to continue with the registration process.
     */

    if (validationInProgress) {
        val lifecycle = LocalLifecycleOwner.current.lifecycle
        val currentNavigateToNextScreen by rememberUpdatedState(onNavigateToNextScreen)
        LaunchedEffect(viewModel, lifecycle) {
            // If the date of birth is valid and the validation is in progress,
            // navigate to the next screen when `lifecycle` is at least STARTED,
            // which is the default Lifecycle.State for the `flowWithLifecycle` operator.
            snapshotFlow { viewModel.uiState }
                .filter { it.isDobValid }
                .flowWithLifecycle(lifecycle)
                .collect {
                    validationInProgress = false
                    currentNavigateToNextScreen()
                }
        }
    }
}

La data di convalida della data di nascita è la logica aziendale di cui è responsabile ViewModel. Nella maggior parte dei casi, ViewModel delega questa logica al livello dati. La logica per far passare l'utente alla schermata successiva è la logica dell'interfaccia utente, perché questi requisiti potrebbero cambiare a seconda della configurazione dell'interfaccia utente. Ad esempio, potresti non voler passare automaticamente a un'altra schermata del tablet se visualizzi contemporaneamente più passaggi di registrazione. La variabile validationInProgress nel codice riportato sopra implementa questa funzionalità e gestisce se l'interfaccia utente deve navigare automaticamente ogni volta che la data di nascita è valida e l'utente vuole andare al passaggio di registrazione successivo.

Altri casi d'uso

Se ritieni che il tuo caso d'uso per gli eventi UI non possa essere risolto con gli aggiornamenti dello stato della UI, potrebbe essere necessario riconsiderare il flusso di dati nella tua app. Considera i seguenti principi:

• Ogni classe deve fare ciò di cui è responsabile, non di più. La UI è responsabile della logica di comportamento specifica per le schermate, come le chiamate di navigazione, gli eventi di clic e l'ottenimento di richieste di autorizzazione. ViewModel contiene la logica di business e converte i risultati dei livelli inferiori della gerarchia nello stato dell'interfaccia utente.
• Pensa a dove ha origine l'evento. Segui l'albero delle decisioni presentato all'inizio di questa guida e fai in modo che ogni classe si occupi di ciò di cui è responsabile. Ad esempio, se l'evento ha origine dalla UI e genera un evento di navigazione, deve essere gestito nell'interfaccia utente. Alcune logiche potrebbero essere delegate a ViewModel, ma la gestione dell'evento non può essere delegata completamente a ViewModel.
• Se hai più consumatori e temi che l'evento venga consumato più volte, potrebbe essere necessario riconsiderare l'architettura dell'app. La presenza di più consumatori simultanei fa sì che il contratto consegnato esattamente una volta diventi estremamente difficile da garantire, quindi la quantità di complessità e comportamenti discreti esplode. Se hai questo problema, valuta la possibilità di spostare questi problemi nella struttura ad albero dell'interfaccia utente; potresti aver bisogno di un'entità diversa con ambito più in alto nella gerarchia.
• Pensa a quando lo stato ha bisogno di essere fruito. In determinate situazioni potresti non voler continuare a utilizzare lo stato quando l'app è in background, ad esempio mostrando un Toast. In questi casi, puoi utilizzare lo stato quando l'interfaccia utente è in primo piano.

Nota: in alcune app, potresti aver notato che eventi ViewModel vengono esposti all'interfaccia utente utilizzando i canali Kotlin o altri flussi reattivi. Quando il produttore (ViewModel) supera il consumer (UI-Compose o Views), queste soluzioni non garantiscono la distribuzione e l'elaborazione di questi eventi. Ciò può causare problemi futuri per lo sviluppatore ed è anche un'esperienza utente inaccettabile per la maggior parte delle app, perché potrebbe lasciare l'app in uno stato incoerente, introdurre bug o l'utente potrebbe mancare di informazioni fondamentali.

Se ti trovi in una di queste situazioni, riconsidera cosa significa effettivamente per la tua UI questo evento ViewModel una tantum. Gestiscile immediatamente e riducile allo stato dell'interfaccia utente. Lo stato della UI rappresenta meglio l'UI in un determinato momento, offre maggiori garanzie di distribuzione ed elaborazione, è in genere più semplice da testare e si integra in modo coerente con il resto dell'app.

Per saperne di più sul motivo per cui non dovresti utilizzare le API indicate sopra con alcuni esempi di codice, leggi il post del blog ViewModel: Anti-pattern degli eventi una tantum.

Samples

I seguenti esempi di Google mostrano gli eventi UI nel livello UI. Esplorale per vedere concretamente queste indicazioni: