Início / coding / Perguntas / 78786629
Accepted
Roman
Asked: 2024-07-24 14:15:03 +0800 CST

Inlining aguarda de diferentes threads no SwiftUI

  • 772

Aqui está um trecho de código do meu SwiftUI ViewModel:

@Published var data: Data
@Published var showingAlert = false
    
func fetchData() {
    Task {
        let result = await NetworkManager.fetchData(),
        await updateUI(with: result)
    }
}
    
@MainActor
private func updateUI(with result: Result<Data, Error>) {
    do {
        data = try result.get()
    } catch {
        showingAlert = true
    }
}

Não tenho certeza se esta é a abordagem idiomática (sou relativamente novo no SwiftUI), mas funciona muito bem.

Minha pergunta é:
podemos nos livrar de uma "espera" mesclando as linhas em uma única?

await updateUI(with: NetworkManager.fetchData())

Este código é equivalente ao anterior?
Mais importante ainda, preciso que a chamada de rede seja executada em um thread em segundo plano enquanto as atualizações da IU são executadas no thread principal. Este ainda é o caso aqui?

Como isso pode ser comprovado? (você sabe, na era GPT tudo deveria ser verificado 😂)

swiftui

1 respostas

  1. Best Answer

    Sim, estes são equivalentes. Da proposta do Swift Evolution :

    Considere o seguinte exemplo:

    // func redirectURL(for url: URL) async -> URL { ... }
// func dataTask(with: URL) async throws -> (Data, URLResponse) { ... }

let newURL = await server.redirectURL(for: url)
let (data, response) = try await session.dataTask(with: newURL)

    Neste exemplo de código, uma suspensão de tarefa pode ocorrer durante as chamadas para redirectURL(for:)e dataTask(with:)porque são funções assíncronas. Assim, ambas as expressões de chamada devem estar contidas em alguma awaitexpressão, pois cada chamada contém um potencial ponto de suspensão. Um awaitoperando pode conter mais de um ponto de suspensão potencial. Por exemplo, podemos usar um awaitpara cobrir ambos os possíveis pontos de suspensão do nosso exemplo, reescrevendo-o como:

    let (data, response) = try await session.dataTask(with: server.redirectURL(for: url))

    O awaitnão possui semântica adicional; como try, apenas marca que uma chamada assíncrona está sendo feita.

    Contanto que NetworkManager.fetchData()não esteja isolado do ator principal, ele será executado em um thread não principal, pelo pool de threads cooperativo. Mesmo que seja isolado do ator principal, provavelmente você está utilizando URLSessionAPIs na sua implementação, que não são isoladas.

    Você pode ligar MainActor.shared.assertIsolated()para NetworkManager.fetchData()"provar" isso. Se esse método falhar, você não estará no ator principal.

    Parece que você está usando um ObservableObjectpara isso. Não há necessidade ObservableObjectapenas para esta operação assíncrona. Você pode mover tudo para o seu arquivo View.

    @State var data: Data?
@State var showingAlert = false
    
// @MainActor // in iOS 18, the 'View' protocol is entirely isolated to the MainActor, so this will be redundant
private func updateUI(with result: Result<Data, Error>) {
    do {
        data = try result.get()
    } catch {
        showingAlert = true
    }
}

func fetchData() async {
    let result = await NetworkManager.fetchData(),
    // similarly for the 'await' here. You don't need it in iOS 18
    /*await*/ updateUI(with: result)
}

    Você pode então chamar isso em um modificador .task { ... }ou task(id: something) { ... }, que cancela a tarefa se a visualização desaparecer. No momento, você ObservableObjectnão lida com o cancelamento do nível superior Taskque você criou.

    • 1

relate perguntas