Хотел бы поделиться с вами некоторыми советами и трюками, которые я использовал на этом примере.

Скачайте Swift Playground со всем кодом из этой статьи:



Codable представлен в Swift 4 с целью заменить старый NSCoding API. В отличие от NSCoding у Codable есть поддержка JSON первого класса, что делает его перспективным вариантом для использования API JSON.

Codable отлично подходит в качестве NSCoding. Если имеется необходимость кодировать или декодировать некоторые локальные данные, которые вы должны контролировать в полной мере, вы можете использовать преимущество автоматического кодирования и декодирования.

На WWDC 2015 Apple объявила, что Swift — первый протокол-ориентированный язык программирования (видео сессии «Protocol-Oriented Programming in Swift»).

На этой сессии и ряде других (Swift in Practice, Protocol and Value Oriented Programming in UIKit Apps) Apple демонстрирует хорошие примеры использования протоколов, однако не даёт формального определения, что же такое Protocol-Oriented Programming.

В интернете множество статей о Protocol-Oriented Programming (POP), которые демонстрируют примеры использования протоколов, но и в них я не нашёл ясного определения POP.

Я попытался проанализировать примеры использования протоколов и сформировать принципы, которых стоит придерживаться, чтобы код можно было назвать протокол-ориентированным.

Даже для самого что ни на есть начинающего разработчика (скорее, на которого и рассчитан данный очерк), надеюсь, не секрет, что в коде не должно присутствовать никаких т.н. «hardcoded»-значений и прочих всяких там «magic numbers». Почему – тоже, надеюсь, понятно, а если нет, то в Сети имеются десятки, а то и сотни статей на эту тему, а также написан классический труд. «Android Studio» (наверное, не во всех случаях, но все же) даже любит генерировать «warnings» на эту тему и предлагать выносить строки и т.д. в ресурсные файлы. «Xcode» (пока?) такими подсказками нас не балует, и разработчику приходится самостоятельно держать себя в узде или, скажем, получать по рукам от коллег после «code review».

Все это касается и используемых в приложении цветов.

Во время нарезки графики под приложения часто возникает множество сложностей: от разрешения устройств и проблемы с сетками и рекомендациями Google до непосредственно передачи приложения разработчику. За 2 года я работала над дизайном более 10 приложений, научилась находить решения самых разных проблем и делать так, чтобы в конечном итоге приложение выглядело так же, как и в дизайне.
Об этом и пойдет речь под катом.

Если вы опытный дизайнер, то согласитесь, что вдохновление другими работами не является кражей элементов пользовательского интерфейса. Наоборот, это процесс исследования. Это следование гайдам. Это применение шаблонов, с которыми пользователи знакомы.

Некоторые могут возразить, что следование гайдам может убить творчество, и в итоге все приложения будут выглядеть одинаково. С точки зрения UX, я тут вижу другую проблему. Может казаться, что применение лучших шаблонов, которые используют Google / Facebook / Instagram / [вставить любимое приложение], всегда является отличным решением. Что они ставят себе такие же задачи, что и вы. Вот несколько шаблонов, которые считаются (или считались) лучшими, но в то же время не такие уж они и хорошие, какими кажутся на первый взгляд.