Swift async/await реализует обновление с использованием задачи

У меня есть сценарий, в котором пользователь может попытаться обновить приложение из нескольких мест, но я хочу обновить его только один раз для каждого запроса.

Просто хотел знать, может ли что-то подобное работать: каждый раз, когда происходит второе обновление или третий запрос, приложение будет ждать текущего выполняемого запроса.

class Test {

  private var currentTask: Task<Int, Never>?

  @MainActor
  func refresh() async -> Result<Int, Never> {
    if let currentTask {
      return await currentTask.result
    }

    let task = Task {
      // Long operation

      return 1
    }

    currentTask = task

    let result = await task.result

    currentTask = nil

    return result
  }

}

Нет, вам нужно дождаться внутренней задачи

lorem ipsum 19.07.2024 19:48

@loremipsum – Он этого ждет, не так ли?

Rob 19.07.2024 22:30

Однако я бы, как минимум, отказался от типа Result<Int, Never>, поскольку это ненужный шум. И currentTask тоже не разворачивается.

Rob 19.07.2024 22:46

Да, это ошибка, так и должно быть if let currentTask { Всем спасибо

David Gonçaalves 23.07.2024 14:18
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
4
76
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Да, этот подход будет работать. Я использую что-то очень похожее в своем приложении.

actor Service {
    private var task: Task<Void, Error>?

    func fetchData() async throws {
        if let task {
            return try await task.value
        }

        let task = Task {
            try await actualFetchData()
        }

        self.task = task
        defer {
            self.task = nil
        }
        return try await task.value
    }

    private func actualFetchData() async throws {
        // Fetching data from the server/database
    }
}

По сути, вы предоставляете метод-оболочку, который гарантирует выполнение запроса на выборку, только если другой не выполняется. Ваша реализация обязательно должна работать.

Эта функциональность может быть расширена для поддержки выборки дискретных данных для конкретного объекта, к которому вы будете обращаться по его уникальному идентификатору.

actor Service {
    private var tasks = [UUID: Task<Void, Error>]()

    func fetchData(for uuid: UUID) async throws {
        if let task = tasks[uuid] {
            return try await task.value
        }

        let task = Task {
            try await actualFetchData(for: uuid)
        }

        tasks[uuid] = task
        defer {
            tasks[uuid] = nil
        }
        return try await task.value
    }

    private func actualFetchData(for uuid: UUID) async throws {
        // Fetching data from the server/database
    }
}

Спасибо за отсрочку. Я заметил одну вещь: я использую главного актера для защиты задачи от любых проблем с параллелизмом, но вы ничего не использовали. Есть ли за этим какая-то причина?

David Gonçaalves 19.07.2024 21:07

И да, и нет, мой сервис не должен возвращаться/работать в основной очереди. Если вам нужна такая функциональность, обязательно добавьте @MainActor в сигнатуру функции.

Witek Bobrowski 19.07.2024 21:12

@Роб, спасибо, что указал на это. В этом примере вызов actualFetchData Sure вызывает ошибку. Отметка обеих функций @MainActor исправляет это. Но весь смысл сохранения задачи здесь заключается в том, чтобы гарантировать, что actualFetchData не будет вызываться в одно и то же время (из любого места). Я бы порекомендовал сделать тип Service актером. (что я только что сделал в посте)

Witek Bobrowski 19.07.2024 23:43

Да, актер должен выполнить эту работу, чтобы избежать проблем с параллелизмом и получить текущую задачу. Спасибо.

David Gonçaalves 23.07.2024 14:15

Другие вопросы по теме