Распространенные ошибки в iOS разработке

Р

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

Кстати, у нас вы можете прочитать о самой распространенной ошибке в использовании UITableView.

Массивный ViewController

Шаблон MVC является ключевым в разработке под iOS. Идея состоит в том, что есть 3 слоя:

  • Модель — представляет бизнес-логику. Этот слой не взаимодействует со слоем Представления.
  • Представление — состоит из объектов, строящих пользовательский интерфейс. Хорошими примерами являются UIButton, UITableView, UILabel и т. д. Представление не должно иметь никакой бизнес логики.
  • Контроллер — находится между Представлением и Моделью. Обеспечивает их взаимодействие.

Однако, в действительности слой контроллера куда больше, чем он должен быть. Очень часто в контроллер заходит слишком много бизнес-логики. В результате, ViewController становится очень массивным. Это плохой стиль при разработке приложений. Я тоже как то наступил на эти грабли, и сейчас провожу колоссальную работу по рефакторингу моей игры. Подробную историю об этом я расскажу после релиза новой версии.

Для получения более детальной информации вы можете взглянуть на один из предыдущих постов «Ловушка MVC».

Операции с UI не в главном потоке

Если вы сталкиваетесь с проблемами, которые трудно воспроизвести снова, которые случаются то очень часто, то вовсе не происходят в вашем приложении — вполне вероятно, что в приложении присутствует проблема многопоточности. Как я уже как то писал — UIKit не поточно. Большинство разработчиков знают об этом, но из за мелких отвлекающих факторов это все еще происходит очень часто — UI (User Interface) выходит за рамки главного потока. Так что будьте очень осторожны, если вы выполняете параллельный код. Для получения более подробной информации о параллельности вы можете взглянуть на наш недавний пост о NSBlockOperation.

Тестирование только в симуляторе

Симулятор iOS очень быстрая и полезная штука. С помощью симулятора вы облегчите разработку и сможете всегда иметь доступ к файловой системе приложения. Тем не менее симулятор не является реальным устройством. Бывают ситуации, когда симулятор и устройство ведут себя по разному. Так же симулятор имеет гораздо большую производительность, чем устройство, так что симулятор — не лучший выбор для тестов скорости приложения.

Таким образом, вы должны использовать как симулятор, так и реальное устройство при разработке. Более подробная информация содержится в одном из предыдущих постов.

Тестирование только на новейших устройствах

Использование реального устройства необходима. Тем не менее это еще не все. Не лучшим решением было бы тестировать приложение только на новейших устройствах. Представьте что вы пишите приложение под iPad и тестируете его на iPad Pro. Не стоит забывать, что iOS 9 поддерживает еще и старичка iPad 2 и что в производительности этих двух компьютеров огромная пропасть. Может случится так, что идеально плавное приложение (на iPad pro) будет просто неработоспособным на iPad 2. Конечно, нет необходимости иметь все-все устройства. Но и ориентироваться на новейшее тоже не стоит.

Детальная информация о тестировании на устройстве. 

Неправильное использование памяти

Да, компилятор и iOS делают за вас большую часть работы при обработке памяти. Но это не означает, что вы не должны заботится о ней вовсе. По прежнему существуют вероятности утечки памяти. Это может произойти из за retain-циклов. Так же не забывайте использовать инструменты, помогающие следить за памятью. Детально об этом вы можете прочесть в статье о memory-эффективных приложениях.

memory

Force Unwrapping Optionals

Одной из главных целей Swift является создание безопасного кода. Неотъемлемой частью достижения этой цели являются Опционалы(необязательные значения):  не-опциональные значения обязательно должны иметь значения и не должны стать nil. Так что если вы хотите позволить значению стать nil, вы должны объявить его как опциональное:

Если вы захотите позволить опциональным значениям взаимодействовать с не-опциональными, то компилятор выдаст ошибку:

Так что опциональные значения необходимо разворачивать (unwrapping):

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

Детальнее про опционалы вы можете причитать в официальном гайде Apple.

И напоследок хочу сказать еще об одной маленькой ошибке при разработке не только под iOS, а в целом — динозаврообразность =) Ребят, вы работаете с новейшими технологиями, и непозволительно отставать от современных тенденций. Старайтесь по максимуму использовать все новейшее, что предлагает платформа и не стойте на месте.

Поддержите ресурс blog.justDev:

Сведения об авторе

Игорь Малеваный

Добавить комментарий

Instagram

Поддержите ресурс blog.justDev:

Свежие записи

Рубрики