Comments 18
Интрига в заголовке заставила прочитать статью.
1. Уже есть Swift 4 с Decodable, JSONSerialization не нужен
2. Использовать URLDownloadTask для API — не лучшая практика, захламлять систему одноразовыми файлами не стоит. DataTask для API был бы более логичен.
3. С форматированием кода (отступы) совсем беда.
4.
5. Используйте weak вместо unowned, иначе легко словите Nil Unwrapping.
6. Force Unwrap (
2. Использовать URLDownloadTask для API — не лучшая практика, захламлять систему одноразовыми файлами не стоит. DataTask для API был бы более логичен.
3. С форматированием кода (отступы) совсем беда.
4.
NSAppTransportSecurity.NSAllowsArbitraryLoads — PLEASE NO! Используйте TLS для ВСЕГО, в самом крайнем случае разрешайте доступ без шифрования к ограниченному числу доменов…5. Используйте weak вместо unowned, иначе легко словите Nil Unwrapping.
6. Force Unwrap (
xxx!) — зло в любом виде, особенно (ОСОБЕННО) в декодировании данных из сторонних источников.
а можно подробнее про 6 пункт? как быть системе если данные не пришли?
Я не про систему, а про особенность Swift. Swift спроектирован как null-safe язык (привет Java-программистам с их NPE), и любые объекты, которые могут быть «null» объявляются как
Если в момент «force unwrap» значение переменной (или результата метода) окажется null (nil) — приложение завершит работу с Fatal Error.
Вывод — ВСЕГДА используйте optional unwrap и конструкции вида "
Type? (синтаксический сахар к Optional<Type>). Обращаться к таким объектам можно определёнными способами, и один из них — «force unwrap»:let value: Type? = someFunc()
print(value) // выведет Optional(value) или nil
print(value!) // force unwrap - выведет value
Если в момент «force unwrap» значение переменной (или результата метода) окажется null (nil) — приложение завершит работу с Fatal Error.
Вывод — ВСЕГДА используйте optional unwrap и конструкции вида "
if let x = optional { ... }" / "guard let x = optional else { ... ; return }"
На мой взгляд вывод неверен.
Может быть так что мы хотели бы иметь URL для какого-то объекта и инициализировать его из статичной строки. Если мы будем использовать
Может быть так что мы хотели бы иметь URL для какого-то объекта и инициализировать его из статичной строки. Если мы будем использовать
guard let или if let, то не получим URL и можем потратить какое-то время на поиск ошибки, которая могла быть в опечатке строки для это URL. Но если бы мы использовали let url = URL(string: "https://habr.com")!, ошибку нашли бы на много быстрее, что было бы равносильно assert.
Если Вы хотите получить именно ошибку, то сделайте к примеру функцию, которая будет возвращать URL в случае успеха, либо выкидывать ошибку, которую Вы будете отлавливать и обрабатывать. Если Вы будете использовать:
let url = URL(string: "https://habr.com")!Есть исключения из любого правила. Статические URL к серверам API можно делать force-unwrap, и использовать ".appendingPathComponent" или «URL.init(_, baseURL:)». Вполне нормальная практика. Но все данные, которые могут прийти извне, надо валидировать optional-binding'ом или другими способами (Decodable в самый раз). Force unwrap — это крэш приложения. Он не уходит в do...catch и вообще никак не обрабатывается. Это зло, которое надо использовать ОЧЕНЬ осторожно.
Спасибо DjPhoeniX за развернутый комментарий.
1) На swift 4 все равно не могу написать, потому что мой компьютер не тянет. Об этом я писал. Но практика хорошая.
2) Вопрос к авторам книги, так как они используют URLDownloadTask исключительно в образовательных целях. Но и упоминают, что DataTask удобнее и короче.
3) Попытаюсь в следующих статьях это исправить.
4) Вот этого не знал. Буду изучать и использовать.
5) Так же не знал о различиях weak и unowned.
6) Не доглядел. В большем части кода, все-таки я использую безопасный optional binding.
Недочеты со временем исправлю.
1) На swift 4 все равно не могу написать, потому что мой компьютер не тянет. Об этом я писал. Но практика хорошая.
2) Вопрос к авторам книги, так как они используют URLDownloadTask исключительно в образовательных целях. Но и упоминают, что DataTask удобнее и короче.
3) Попытаюсь в следующих статьях это исправить.
4) Вот этого не знал. Буду изучать и использовать.
5) Так же не знал о различиях weak и unowned.
6) Не доглядел. В большем части кода, все-таки я использую безопасный optional binding.
Недочеты со временем исправлю.
По-моему какая-то жесть… Лучше почитайте эту статью или посмотрите как в Alamofire. И в этом коде:
не задаете размер окна, а создаете новое, непонятно зачем…
self.window = UIWindow(frame: UIScreen.main.bounds) не задаете размер окна, а создаете новое, непонятно зачем…
Добрый день. Можете пояснить ситуацию, почему:
class RestRequest: NSMutableURLRequest {
}
let request = RestRequest() // падает
let request = NSMutableURLRequest() // работает
На ObjectiveC как-то без сюрпризов с конструктором
class RestRequest: NSMutableURLRequest {
}
let request = RestRequest() // падает
let request = NSMutableURLRequest() // работает
На ObjectiveC как-то без сюрпризов с конструктором
Изменения, внесенные в статью, по мере учета комментариев:
1) NSAppTransportSecurity позволяет загружать теперь только с домена, внесенного в исключения, а не со всех http сайтов, как это было ранее.
2) Убраны комментарии очевидных вещей. Оставлены только комментарии, поясняющие некоторые решения, например, необходимые в будущем. Сами комментарии включены в код, а не вынесены следом, как было ранее.
3) Код инициализации lazy var перенесен в них самих, а не в отдельные функции, как было ранее.
4) Сделал нормальное форматирование кода.
5) Почти все unwrapping сделал через guard. Оставил forse unwrapping только для свойства-замыкания и для обработки url.
6) Несмотря на кривость решения через download task и delegate, сохранил его, как памятник старины, чтобы знать, с чего все начиналось, и понять, чем современные решения лучше. Более современное решение будет показано в новой статье.
1) NSAppTransportSecurity позволяет загружать теперь только с домена, внесенного в исключения, а не со всех http сайтов, как это было ранее.
2) Убраны комментарии очевидных вещей. Оставлены только комментарии, поясняющие некоторые решения, например, необходимые в будущем. Сами комментарии включены в код, а не вынесены следом, как было ранее.
3) Код инициализации lazy var перенесен в них самих, а не в отдельные функции, как было ранее.
4) Сделал нормальное форматирование кода.
5) Почти все unwrapping сделал через guard. Оставил forse unwrapping только для свойства-замыкания и для обработки url.
6) Несмотря на кривость решения через download task и delegate, сохранил его, как памятник старины, чтобы знать, с чего все начиналось, и понять, чем современные решения лучше. Более современное решение будет показано в новой статье.
Sign up to leave a comment.
Взаимодействие с сервером через API в iOS на Swift 3. Часть 1