Почему я должен выпустить (и поэтому dealloc) объекты непосредственно перед тем, как приложение вышло?
Когда дело доходит до РАЗМЕЩЕНИЯ данных на веб-сайте, Система. Сеть. HttpWebRequest (определенная для HTTP реализация WebRequest) является совершенно достойным решением. Это поддерживает SSL, асинхронные запросы и набор других положительных героев, и хорошо зарегистрировано на MSDN.
полезная нагрузка может быть чем-либо: данные в формате JSON или безотносительно - пока Вы устанавливаете свойство ContentType на что-то сервер, ожидают и понимают (наиболее вероятный application/json, text/json или text/x-json), все будут в порядке.
Одна потенциальная проблема при использовании HttpWebRequest от системной службы: так как это использует прокси IE и информацию об учетных данных, поведение по умолчанию может быть немного странным при выполнении как пользователь LOCALSYSTEM (или в основном любая учетная запись, которая не входит в систему в интерактивном режиме регулярно). Установка свойств Proxy и Authentication к Nothing (или, как Вы люди C# предпочитают называть его, null, я предполагаю) должна избежать этого.
5 ответов
Думаю, единственный ответ, который имеет для меня хоть какой-то смысл, - «последовательность». Нет, возможно, вам не всегда нужно реализовывать dealloc , но если вы всегда будете это делать, вы не забудете сделать это, когда это будет иметь значение. И, кроме того, написание двух строк кода, которые не могут быть вызваны, стоит более 30 секунд.
Кроме того, очень маловероятно, что вы потратите впустую свои драгоценные циклы ЦП (которые, кстати, не настолько ценно, что вы когда-нибудь заметите разницу. Эти анимации для iPhone существуют в основном для того, чтобы выиграть время вашего приложения для запуска / выключения), потому что, когда приложение завершает работу, оно обычно не беспокоит объекты dealloc , потому что, как вы говорите, дни выделения памяти в куче уже позади.
Так что, да, dealloc вряд ли когда-либо будет вызван на UIApplicationDelegate , но стоит ли вам это делать в любом случае? Не совсем.
Потому что ты будешь знать, Артем.
Давайте поиграем в небольшую игру под названием «Что если».
Что если , вы разработаете отличное приложение. Действительно мастерское приложение - и публике оно нравится! Ваши продажи растут, птицы поют ваше имя, трепеща в небе!
Но вы решили ничего не делать в своем AppDelegate dealloc. Всего несколько секунд времени вы решили не заморачиваться. Что в этом плохого?
Ой, сначала ты спокойно спишь на куче денег. Но по мере того, как продажи растут и растут, вас настигает небольшой приступ. А потом начинаются сны.
Квадратные формы, сначала нечеткие. Проходят дни, и они становятся яснее, по мере того как вы спите все меньше и меньше. И вот, наконец, однажды, понимаете.
Это блоки, Артем. Блоки памяти . А что они делают в твоих мечтах? Ну вы видите не совсем освободившись от существования до закрытия приложения, они должны были куда-то уйти. Приложение исчезло, телефон переехал.
Итак, они переместились в вашу HEAD . И с каждым днем прибывает все больше, оставляя меньше места для СЕБЯ .
Надеюсь, это было информативно ... Артем.
Лучшая причина - повторное использование. Есть вероятность, что вы сможете переместить объект из одного места в другое или изменить его назначение. Если вы это сделаете, лучше всего убедиться, что все ваши i отмечены точками, а t перечеркнуты.
Это тоже просто хорошая привычка. Если вы не забудете делать это там, вы будете делать это везде.
Потому что возможно, что освобожденный класс имеет побочный эффект, такой как сохранение состояния в его методе dealloc или в одном из его суперклассов. ОС не должно беспокоиться, она должна вернуть все ресурсы, несмотря ни на что.
В опубликованном вами примере кода не требуется освобождать что-либо при завершении работы приложения. Если вы думаете о методе dealloc, он не будет вызываться при завершении работы приложения.
В нескольких местах документации Apple отмечает, что отказ от отправки метода dealloc при выходе является намеренным выбором дизайна, потому что, как вы сказали, гораздо эффективнее просто освободить все адресное пространство. См. Обсуждение документации Dealloc .