#iphone #objective-c
#iPhone #objective-c
Вопрос:
привет, я разрабатываю sms-приложение для своего клиента. на данный момент я внедрил этот план.
1) Приложение продолжает опрашивать сервер асинхронным запросом, чтобы это не мешало работе пользовательского интерфейса.
2) для отправки sms я в настоящее время использую синхронный запрос, в зависимости от ответа с сервера я делаю разные вещи. я показываю вращающийся круг и заставляю пользователя ждать, пока я не получу ответ от сервера.
у моего клиента проблема с пунктом 2.
Клиент говорит, что как только нажата кнопка отправить sms, он должен вернуться на рабочий стол и должен иметь возможность переходить на любой экран и выполнять все другие действия, предлагаемые приложением. я мог бы использовать асинхронный запрос, но я не уверен, как обрабатывать ответы с сервера, когда я нахожусь на другом контроллере просмотра, отличном от того, с которого вызывается запрос.
Кто-нибудь может мне помочь в этом.
Спасибо.
Комментарии:
1. Можете ли вы поместить логику отправки в класс, который выполняет опрос? Таким образом, они оба могут выполняться в фоновом режиме, пока пользователь перемещается по приложению.
Ответ №1:
Классическим способом обработки ответа на асинхронное действие является либо делегирование, либо уведомления. Не используйте синглтон. Это нарушает модульность и развязку различных контроллеров представления.
Дорожная карта того, как обрабатывать асинхронные действия
- Зарегистрируйтесь для получения ответа на асинхронные действия. Это может быть установка делегата запрашивающего объекта, например,
NSURLConnectionдля контроллера представления, что обычноselfиспользуется в этом контексте. Другая возможность заключается в том, что вы регистрируетесь для получения уведомления, которое запускается запрашивающим объектом, если что-то произошло, например, когда загрузка завершена или произошла ошибка. - Реализуйте методы делегирования или уведомления для обновления вашей модели и / или вашего пользовательского интерфейса. Имейте в виду, что обновление пользовательского интерфейса должно происходить в вашем основном потоке.
- Запустите асинхронное действие. В фоновом режиме создается отдельный поток или выполняется операция с использованием GCD. Это детали реализации, и они вас не беспокоят.
- Дождитесь ответа, в результате которого будет выполнен один из ваших реализованных методов, который вы затем используете для обновления того, что изменилось.
Разница между уведомлениями и делегатами
Два различия между делегатами и уведомлениями заключаются в том, что делегирование представляет собой соединение «один к одному» между делегатом и делегирующим объектом. Уведомления публикуются во всем приложении и могут просматриваться таким количеством объектов, сколько необходимо, создавая соединение «один ко многим». Подумайте об этом как о трансляции. Второе основное отличие заключается в том, что делегирование может использоваться для передачи информации обратно от делегата к делегирующему объекту. Это означает, что делегирующий объект запрашивает у делегата определенную информацию. Типичным примером может быть источник данных UITableView . Однако уведомления — это улица с односторонним движением. Информация поступает от объекта публикации к объектам наблюдения. Это имеет смысл, потому что подумайте о ситуации, когда у вас было бы более одного наблюдателя, и каждый из них давал бы обратную связь объектам публикации. Какой из них был бы правильным?
В вашем случае вам пришлось бы искать методы делегирования объекта асинхронного HTTP-запроса и реализовывать их соответствующим образом.
Комментарии:
1. большое вам спасибо за ваше предложение, я использовал делегирование, и это сработало довольно хорошо. однако у меня есть другая проблема. приведенный выше ответ на мой вопрос заставляет меня почувствовать, что вы можете ответить на мою следующую проблему. Пожалуйста, ознакомьтесь с моим следующим вопросом.
Ответ №2:
Может быть, вы можете попробовать ASIHTTPRequest , он синхронизирует асинхронный запрос
Если вы используете асинхронный запрос, вы можете делать что угодно после нажатия кнопки для выполнения запроса.
Ответ №3:
Решение зависит от обработки ответа …. если вы просто показываете пользователю, что отправка sms не удалась / успешна, вы можете сделать это в любом общем служебном классе, который показывает alert .. но для этого вам нужно создать экземпляр singletone вашего класса connection, чтобы делегат (сам класс) не умирал, когда возвращается ответ…….
Комментарии:
1. @пользователь698952 . Ну, когда пользователь отправляет sms, в зависимости от ответа с сервера, мне приходится отображать другой контроллер просмотра, а иногда просто отправленное sms-оповещение alertview.
2. Боюсь, вы неправильно используете термин singleton . Синглтон — это объект одного класса, который является общим для всего приложения. Например, [NSUserDefaults standardDefaults] является синглтоном или [UIApplication sharedApplication] является синглтоном, потому что существует только один объект . В вашем случае у вас может быть более одного асинхронного HTTP-запроса в приложении, так что это не синглтон .
3. Также неверны рассуждения о том, зачем вам нужен синглтон. Объект делегата не является release, потому что обычно именно этот объект делегата владеет (сохраняет) объектом, вызывающим делегат. Подумайте
UITableView: TableViewController сохраняетUITableView, и именно поэтому источник данных (делегат) всегда присутствует, если его вызывает TableView. Если контроллер отключается, он также освобождает TableView, поэтому не может возникнуть ситуации, при которой делегат освобождается до TableView!4. @GorillaPatch : Поведение методов UITableView и delegate при асинхронном соединении сравнивать не следует …. потому что при асинхронном соединении… делегаты будут вызываться между ними, в будущем мы никогда не уверены, когда они будут вызваны…. И в случае, если @Rajashekar хочет, чтобы методы делегирования вызывались даже после изменений viewcontroller… вот почему объект делегата соединений должен быть активен даже после смерти вызывающего viewcontroller …. иначе он не смог бы получить ответ..
Ответ №4:
Для этого нам нужно отслеживать currentViewController …… мы можем сделать это, создав ссылку …….. id currentViewController в appDelegate(with setter/getters) ………. таким образом, он может быть доступен в любом приложении……..
указанный на него объект должен изменяться каждый раз, когда пользователь изменяет ViewController …. это поможет нам узнать, с каким пользователем ViewController в данный момент работает.
затем, когда однотонный класс соединения завершит загрузку ответа, мы можем использовать это currentViewController with your desired viewController.
Я не уверен, как вы используете другой контроллер представления ……. нажимаете на него / представляете его или добавляете его представление…..
Комментарии:
1. @user698952 итак, вы думаете, что я должен использовать одноэлементный класс (который имеет ASI-HTTP-AsynRequest) для отслеживания viewcontroller или мне следует рассмотреть одноэлементный класс (который имеет ASI-HTTP-AsynRequest) с добавлением viewcontroller в окно appdelegate в зависимости от ответа, любой идеи…
2. синглтон для класса, которому делегирован класс NSURLConnection… так что при переходе с одного viewcontroller на другой … вы не освобождаете этот класс ……. в противном случае ему не удастся определить местонахождение своего делегирования………. и для currentViewController (который помогает нам отслеживать текущий viewcontroller) нам нужно сделать его свойством в AppDelegate, чтобы он мог быть доступен всем ViewControllers ….. также я все еще не уверен, какой механизм замены viewcontroller . вы используете…….
3. @user698952 прямо сейчас я не использую никакой механизм замены viewcontroller, в моих предыдущих приложениях, если мне нужно всплывающее окно viewcontroller, независимо от любого viewcontroller, который находится сверху — я добавляю view controller в окно appdelegate и удаляю его, когда закончу.
4. @user698952 я немного почитал со времени моего предыдущего поста, и хотя я должен использовать ASI-HTTP-AsynRequest, поскольку он более роботизирован, чем nsurlconnection, и он предлагает намного больше возможностей. я попытаюсь использовать одноэлементный класс с методами делегирования ASI-HTTP-AsynReques и посмотрю, что получится. как ты думаешь, это хорошая идея?
5. @Rajashekar да, основная идея этого обсуждения заключается в том, что нам нужен живой объект, который можно использовать даже после того, как мы изменим контроллер представления / или выпустим его….. @GorillaPatch предлагает нам обычный способ его использования (его можно использовать только тогда, когда мы все еще ждем ответа, но это не так ..)…. Я надеюсь, вы поняли мою идею об использовании singleton…. также для обработки этого ответа мы должны использовать какой-нибудь метод, написанный в AppDelegate … который уменьшит дублирование кода для обработки этого конкретного ответа…. Спасибо