Лучший способ спроектировать и запустить длительный, зависимый асинхронный процесс (ы) на iPhone? - PullRequest
1 голос
/ 27 ноября 2010

Я работаю над дизайном приложения для iPhone. У меня довольно напряженный процесс, который на высоком уровне определяется следующим образом:

  1. Пользователь выбирает элемент из UITableView для inApp покупки.
  2. Пользователь подтверждает покупку в пользовательском интерфейсе.
  3. Асинхронный процесс идет в App Store, чтобы проверить, есть ли элемент был куплен раньше. Если не, Товар куплен. IPhone Затем приложение уведомляется, что элемент покупка прошла успешно. (Если бы это было купленное ранее приложение не волнует и переходит к шагу 4.)
  4. Затем приложение отправляется на мой частный сервер, чтобы загрузить данные для приобретенного предмета.
  5. Затем приложение импортирует данные в CoreData.

Конечно, на каждом этапе процесса пользователю сообщается об ошибках, и весь процесс останавливается.

У меня есть класс ActivityIndicatorController, который представляет пользователю приятный UIActivityIndicator вместе с некоторым текстом, указывающим, что происходит. На каждом этапе процесса метка в ActivityIndicator должна обновляться с новым статусом.

Вопрос / проблема:

Кажется, с точки зрения дизайна и кодирования, САМОЕ ПРОСТОЕ, что нужно сделать, это использовать одну большую NSOperation для всех шагов. Тем не менее, я обеспокоен тем, что это может помешать мне позже. Я не хочу идти по неправильному пути, а потом вырвать кучу кода позже.

Моя интуиция говорит мне, что было бы ЛУЧШЕ реализовать три отдельных операции NSO (OpInAppPurchase, OpDownload, OpImport). Однако каждая последующая операция зависит не только от предыдущей, но и в случае сбоя остальные операции NSO вообще не должны вызываться. Но я не уверен, как спроектировать / кодировать это.

Любая помощь приветствуется.

EDIT:

Спасибо всем за помощь. За то, что я пытаюсь выполнить, я не хочу, чтобы пользователь отменил операцию. Тем не менее, я хочу, чтобы приложение могло отменить последующие операции. То, что я не смог осознать и только что обнаружил методом проб и ошибок (т. Е. «Тупой» момент), это то, что когда операция запускается в отдельном процессе, любые дочерние операции, которые запускаются, также выполняются в том же отдельном процессе .

После прочтения статьи Apple, ссылки на которую приведены ниже, я обнаружил, что для моих нужд прямо сейчас NSInvocationOperation выполняет именно то, что мне нужно, и избавляет меня от необходимости создавать отдельные объекты NSOperation для каждого процесса. Затем он выполнит обратный вызов с объектом NSError для основного потока в случае сбоя или другой обратный вызов для основного потока в случае успеха.

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

Ответы [ 2 ]

2 голосов
/ 27 ноября 2010

Добавляя каждый шаг в NSOperationQueue Вы можете убедиться, что этот шаг не прошел, прежде чем продолжить. См. статью об общем подходе.

Вы также можете инициировать и отвечать на запросы отмены от NSOperation, если операция сталкивается с проблемой. См. Ответ на события отмены в этой статье .

Ответ на события отмены:

После того, как операция начинает выполняться, он продолжает выполнять свою задачу до это закончено или пока ваш код явно отменяет операцию. Отмена может произойти в любое время, еще до начала операции выполнения. Хотя НСОоперация класс дает возможность клиентам отменить операцию, распознавая событие отмены является добровольным необходимость. Если операция была сразу же, не может быть способом вернуть любую память или ресурсы, которые были выделены. Как В результате объекты операции ожидается проверка на отмену события и грациозно выйти, когда они происходят в середине работа.

1 голос
/ 28 ноября 2010

Используйте NSOperationQueue. Инкапсулируйте каждую задачу в отдельную NSOperation. Установите зависимости, используя addDependency:.

«Как предотвратить выполнение других операций при сбое?», Спросите вы.

Ну, во-первых, убедитесь, что ваши NSOperation объекты являются хорошими гражданами и регулярно проверяйте, были ли они отменены, чтобы они могли остановить выполнение.

Затем просто выполните каждую операцию dependencies, чтобы проверить, отменены ли эти зависимости. Если это так, просто выйдите или отмените текущую операцию.

...