Создание iOS-приложения – непростая задача. Разработчикам хочется как можно быстрее завершить этот процесс и наконец запуститься в AppStore. Но на этом все не заканчивается: впереди у создателей долгие годы исправления ошибок, улучшения функций и совместной работы с другими разработчиками. Мы бы хотели немного облегчить им жизнь и для этого решили разобрать три вещи, которые нужно избегать при iOS-разработке (спасибо Envato Tuts+ за информацию).
1. Константы, константы… мне и с переменными норм
На первый взгляд, переменные более универсальны чем константы. Но если вы можете использовать константу, то лучше к переменным не прибегать. У констант есть несколько преимуществ.
Читаемость
Это, пожалуй, главное преимущество. Предположим, вы пишете e-commerce приложение для США. Указываете локальную ставку налога с продаж — 8,75%. И в этот момент к разработке подключается условный Вася, который о налоге с продаж ничего не знает.
Если вы введете переменную для обозначения ставки налога с продаж, он может изменить ее буквально одной строкой кода, что может серьезно навредить приложению. Если вы поменяете ключевое слово с var на let, компилятор сообщит, что это значение не может быть изменено, и Вася отдернет свои судьбоносные персты от клавиатуры.
Ссылка на значение
С помощью let можно ссылаться на какое-либо значение в коде. Создаете вы приложение, создаете и вдруг по примеру Rolling Stones решаете покрасить все в черный. Если вы прописали константу, то при изменении в одном месте все остальные ссылки на цвет тоже изменятся. А если нет, то придется выискивать и менять все вручную.
Инстанцирование класса или структуры
Если вы создаете синглтон (singleton), вам нужно при этом создать и общий экземпляр (shared instance) класса. Обычно это делается через объявление static let внутри объявления класса. После этого вы даете имя константе, присваиваете ее экземпляру класса и можете спокойно использовать его во всем приложении.
Если вам нужно создать экземпляр обычного класса (скажем, в ViewController.swift), вы создаете константу и присваиваете ее экземпляру нужного вам класса – таким образом возникает ссылка, которой вы можете легко воспользоваться во всем файле. Константы снова в деле!
Как видите, константы имеют много преимуществ. Они повышают читаемость кода, они полезны для хранения неизменяемых величин и, конечно, не так бесполезны, как вы думаете. Крутые разработчики любят константы и изменяют им с переменными только если от изменения значений никуда не деться.
2. Bang Operator! Как круто звучит, то что надо для опционала!
Опционалы — очень мощная фича Swift. Это типы а-ля int и String, аннотированные с вопросительным знаком после объявления типа. Если вы хотите объявить переменную как опциональную строку, то можете просто написать:
var someVariable: String?Это сигнал компилятору, что в ней либо будет значение, либо не будет. String? и String считаются двумя разными типами.
Опционал — это подарочная коробка. В этой коробке может храниться, а может и не храниться значение. Если вы хотите это узнать, нужно опционал развернуть. Это делается по-разному.
Неправильно: Forced Unwrapping (Принудительное извлечение значения)
Эта операция (выполняется с помощью восклицательного знака) называется Bang Operator. Не советуем ей пользоваться. Если в значении извлекаемого таким образом опционала будет nil (ничто), то приложение рухнет. Вот например как здесь:
var someVariable: String?
var somethingElse: String = "hello"
func setupApp() {
self.somethingElse = self.someVariable!
}
В этом примере приложение упадет, потому что мы не определили значение someVariable и пытаемся присвоить его переменной типа String. Как раз для защиты от таких ошибок и создавались опционалы, а мы сводим все их усилия не нет.
Правильно: Optional Binding (Привязка опционала)
Это один из самых популярных методов работы с опционалами. Вы просто присваиваете значение опционала константе через инструкцию if. Если из опционала можно извлечь значение, компилятор входит в замыкание, и вы можете использовать созданную константу. В противном случае вы попадаете на ветку else и делаете вид, что ничего не произошло.
Для сравнения возьмем тот же пример:
var someVariable: String?
var somethingElse: String = "hello"
func setupApp() {
if let theThing = someVariable {
self.somethingElse = self.someVariable!
} else {
print("error")
}
}
С привязкой опционала компилятор не рушит все приложение, а спокойно входит в ветку else и печатает «ошибку».
И снова правильно: Optional Chaining (опциональная цепочка)
Другим распространенным способом безопасного извлечения опционалов является опциональная цепочка. Так вы сможете полностью избежать значений nil с помощью всего одной строки. Если в какой-то момент такое значение будет получаться, эта строка кода просто перестает выполняться. Например:
var someClass: SomeClass? = SomeClass()
var somethingElse: String?
func setupApp() {
self.somethingElse = someClass?.createString()
}
Если someClass равен nil, то не будет выполнена вся строка, значение somethingElse становится равным nil. Если значение отлично от nil, как в примере выше, то оно присваивается переменной somethingElse. В любом случае приложение не упадет.
И опять верно: Nil Coalescing (Оператор объединения по nil)
Этот метод позволяет обрабатывать опционалы одной строкой, но в отличие от метода выше, вы обязаны указываете значение по умолчанию или «else». То есть для сценария, когда опционал окажется равным nil). Например:
var someVariable: String?
var somethingElse: String = "hello"
func setupApp() {
self.somethingElse = someVariable ?? "error"
}
Выглядит загадочно, но суть проста. Если выражение слева имеет какое-либо значение (то есть не равное nil), то это значение и будет использовано. Если значение равно nil, то будет использовано значение по умолчанию – в этом случае, захардкоженная строка. Выражение справа должна быть отлично от nil, а его тип должен быть неопциональным — иначе теряется весь смысл.
3. Оставим все эти шаблоны архитектуры на потом
И напоследок классическая ошибка. Многие не структурируют код, отчего страдает устойчивость, эффективность и способность его поддерживать в принципе. Можно втиснуть весь свой код в классы ViewController, но этот опрометчивый шаг отольется горючими слезами, когда придется изменить и дебажить код.
Код — это фундамент, на котором вы разрабатываете свое приложение. Без последовательно заложенного фундамента многоэтажный дом вашего приложения легко обрушится. Фундамент iOS приложения – это выбранный шаблон проектирования. Рассмотрим два наиболее часто используемых шаблона.
MVC (Model-View-Controller)
Шаблон проектирования Model-View-Controller, или MVC, разделяет каждую часть вашего кода на три части: модель, вид и контроллер.
- Модель. Это по сути данные приложения. Эта часть охватывает многократно используемые структуры и классы, которые работают только с данными приложения. Модель не работает ни с чем, что связано с view или с тем, как информация будет показана пользователю.
- Вид. Отвечает только за визуальное представление данных, а также за взаимодействие с пользователем. Он не обрабатывает ничего, что связано с данными или с конкретными view. Это просто класс, который можно многократно использовать без повторения кода.
- Контроллер. Вот наш главный герой. Он берет данные из модели, а затем отправляет их во view, чтобы отобразить их для пользователя. Обычно это происходит в ViewController.swift – он воспринимает входные данные и меняет модель по мере необходимости.
Существует множество вариаций MVC, например, MVVM и MVP. О них стоит почитать, но принцип их работы схож с MVC, поэтому мы не будем здесь на них останавливаться. Все это — шаблоны проектирования, которые делают наш код модульным.
Синглтоны
Синглтон — это единственный экземпляр класса, который всегда присутствует в памяти. И что в нем особенного? Предположим, вы создаете приложение, которое подключается к базе данных, и вам нужно куда-то разместить все подключения. Синглтоны для этого подойдут идеально. Вот как их создавать:
// Declaration
class DataService {
static var shared = DataService()
func createUser() {
}
}
// Call-site
DataService.shared.createUser()
Если следовать этим простым советам, приложение будет легче поддерживать, и вы найдете ошибки быстрее клиентов.
Все рассмотренные нами ошибки прекрасно иллюстрируют старинную русскую мудрость: «Тише едешь — дальше будешь». Надеемся, что статья была полезна, и ждем, что вы тоже расскажете нам, как обходили какие-нибудь подводные камни iOS-разработки. Обещаем приятный подарок от Программы ЕФС автору самого оригинального рассказа!
Автор: EFS_programm
