Лекция 16. Мультиплатформенная версия EmojiArt (macOS). CS193P Весна 2021г.

Это Лекция 16 курса Stanford CS193p, весна 2021 года.

Эта лекция полностью посвящена мультиплатформенной поддержке. В частности, запускается приложение EmojiArt на Mac как собственное приложение для macOS, но при этом вы будете удивлены парой вещей. Одна из них — это какой мощный UI мы создали для работы с документами на Mac на базе документо-ориентированной SwiftUI архитектуры, а также сколько нашего iOS кода практически без модификации работает на Mac. Для той части, которая не работает, применяется несколько стратегических хитростей, способных максимально адаптировать наш код к мультиплатформенности.

На Лекции 16 профессор создает единый проект с большим количеством общего кода, и да,  с некоторыми #if os(…) — else #endif, потому что две платформы, macOS и iOS, это не одно и то же. У них не совсем один и тот же способ взаимодействия с пользователями и т. д., так что он адаптирует код к разным платформам.

Читать далее

Лекция 15. Интеграция с UIKit. CS193P Весна 2021г.

Это Лекция 15 курса Stanford CS193p, весна 2021 года.

Хотя название Лекции «Интеграции с UIKit«, задача этой Лекции — более широкая, заставить работать наше документо-ориентированное приложение EmojiArt на iPhone. До сих пор функциональные возможности приложения EmojiArt в большей степени были ориентированы на iPad. Запуск этого приложения на iPhone показал, что большая часть кода прекрасно адаптируется самой SwiftUI, например, popover на iPad автоматически преобразуется в полноэкранный sheet на iPhone, но не все работает так гладко.

Например, нам пришлось добавить ещё три способа получения фонового изображения background для нашего документа, ибо перетягивание его из Safari, находящегося тут же на экране iPad, в случае iPhone не работает.

Вот эти способы :

  • копирование  и вставка (Copy & Paste) изображения c  Pasteboard
  •  изображение с фотокамеры
  •  изображение из Библиотеки Фотографий (Photo Library)

Для этого мы должны были решить вопрос размещения множества кнопок Button, соответствующих различным способам получения фонового изображения документа, на панели инструментов toolbar, а также вопросы интеграции UIKit API  фотокамеры и Библиотеки Фотографий (Photo Library) в SwiftUI приложение.

Читать далее

Лекция 14. «Документо-ориентированная» архитектура. CS193P Весна 2021г.

Это Лекция 14 курса Stanford CS193p, весна 2021 года.

На этой Лекции профессор подробно, строка за строкой, рассматривает код в главном файле приложения с @main, и очень наглядно демонстрирует, как работает «сцена» Scene. В большинстве случаев вы просто будете использовать одну из двух основных встроенных в SwiftUI “сцен” Scene, которыми являются WindowGroup и DocumentGroup с аргументом newDocument. Есть также DocumentGroup (viewing:) для read-only документов.

WindowGroup и DocumentGroup немного напоминают ForEach для Scenes , но эти ForEach “проходят” не через массив Array “чего-то”. Вместо этого каждая из этих “сцен” Scene создается пользователем либо путем создания «New Window» на Mac, либо путем разделения экрана разными (или одинаковыми) приложениями на iPad. На iPhone создание Scene выполняется только один раз, потому что только одна “сцена” Scene в данный момент находится на iPhone и заполняет собой целый экран. 

WindowGroup — это основной не “документо-ориентированный” встроенный в SwiftUI Scene. Это то, что мы использовали до сих пор в обоих наших приложениях Memorize и EmojiArt.  Внутри WindowGroup мы просто размещаем топовое View, которое хотим видеть на нашем экране. Мы можем делиться нашей ViewModel в виде @StateObject со всеми “сценами” Scene, которые можно создать.

Эти “сцены” Scene немного отличаются для различных платформ и в вашем приложении может быть множество Scenes. Легче всего это представить на Mac, где каждое “окно” — это маленькая “сцена” Scene, все очень, очень просто. На iPhone тоже легко представить, что такое “сцена” Scene, у вас всего одна “сцена” Scene самого верхнего уровня. Но на iPad вы можете даже не осознавать, что там происходит со “сценами» Scenes.

Поэтому профессор не торопится переходить сразу к DocumentGroup. Сначала он дает нам почувствовать в полной мере, что такое «сцена» Scene, оставаясь в пределах WindowGroup и рассматривая попутно такие «Обертки Свойства», как @SceneStorage@AppStorage и @ScaledMetric. Все это сопровождается великолепным демонстрационным примером на iPad. В результате чего мы приходим к тому, что если мы оставим наше приложение EmojiArt в WindowGroup, то всё, на что можно рассчитывать — это автосохранение единственного документа.

Это приводит нас прямо к разговору об архитектуре “документо-ориентированного” приложения в SwiftUI, в котором главным действующим лицом является “документ” наподобие EmojiArt. Конечно, мы хотим, чтобы у каждого документа EmojiArt была своя собственная ViewModel и чтобы каждый документ имел свой отдельный файл. Но кроме этого мы хотим иметь возможность переименовывать, перемещать эти файлы, удалять эти файлы и т.д. и все это в одном приложении.

У SwiftUI есть очень мощный механизм, который заботится обо всем этом вместо нас, и на Лекции 14 профессор учит нас использовать этот механизм, который называется DocumentGroup. Он превращает EmojiArt в многодокументное приложение и позволяет ему работать как “родному” приложению как на iOS, так и на Mac. Для этого не требуется много кода. 

Читать далее

Лекция 13. «Издатель» Publisher. Ещё о «постоянном хранении». Cs193P Весна 2021г.

Это Лекция 13 курса Stanford CS193p, весна 2021 года.

Лекция 13 посвящена 3-м темам:

  • “издатель” Publisher
  •  “постоянное хранения” (persistence) в «облаке» CloudKit
  • “постоянное хранение” (persistence) в локальной базе данных CoreData.

Две бонусные лекции (Enroute) с демонстрацией CoreData были прочитаны весной 2020 года, а не весной 2021 года. Изложенный материал (Picker, использование Codable для извлечения данных из REST API и CoreData) по-прежнему актуален (по крайней мере, на весну 2021 года), поэтому эти лекции также включены сюда. Ссылки представлены в конце этого поста.

“Издатель” Publisher

Первая тема — это “издатели” Publisher, своего рода API, некоторый формализм, для потоковой информации, которая порождается одной частью вашей программы, a потребляется — другой.

“Издатель” Publisher — это лишь один из «игроков» реактивного Swift фреймворка Combine, который оперирует такими абстрактными понятиями, как «издатели» Publishers, «подписчики» Subscribers и операторы Operators. Благодаря тому, что Apple предоставляет разработчикам уже готовых «издателей», «подписчиков» и операторов, код, написанный с помощью Combine, оказывается очень компактным и хорошо читаемым.

Читать далее

Лекция 12. Привязка Binding. «Всплывающие окна» sheet popover Alert. Navigation. EditMode. CS193P Spring 2021.

Это Лекция 12 курса Stanford CS193p, весна 2021 года.

На этой фантастической и очень важной Лекции (она длится почти 2 часа) Пол Хэгерти рассматривает супер важную тему — Property Wrappers (“Обертки Свойства”). Мы наконец-то поймем, что такие вещи как @State, @StateObject, @Published, @ObservedObject и другие @штуковины делают под «капотом». Поэтому сначала эту тему профессор представляет теоретически, то есть на слайдах, а затем следует громадная демонстрация, на которой показывается все это в действии, но не только это, а также много всего другого, что можно изучить только в  демонстрационном пример: текстовые поля TextField, «всплывающие окна» popover и sheet, навигацию с помощью NavigationView, формы Form, списки List, режим редактирования EditMode и т.д, интересные модификаторы .onDelete, .onMove, .onChange.

Property Wrapper (“Обертка Свойства”) — это просто структура struct, в которую встроен некоторый шаблон “поведения”переменной var, которую эта структура struct “оборачивает”.

Например, @State заставляет переменную var “жить” в “куче” (heap), делая её writable в View, то есть дает возможность “писать” в нее новые значения в противоположность обычным переменным var в View, которые являются unwritable (только для чтения).

Мы знаем, что @Published публикует изменения переменной var, которые заставляют Views перерисовывать себя или делать другие подобные вещи.

То же самое происходит с @ObservedObject переменной var, которая отслеживает изменения в вашей ViewModel и заставляет View перерисовывать себя.

Читать далее

Лекция 11. Постоянное хранение (Persistence). Обработка ошибок. CS193P Spring 2021.

Это Лекция 11 курса Stanford CS193p, весна 2021 года.

Главная тема этой Лекции — «постоянное хранение» (Persistence), то есть хранение данных в файловой системе и других местах на самом устройстве и в iCloud. Теме «постоянного хранения» сопутствуют еще две важные темы. Это формат хранения данных (самым распространенным форматом является JSON формат) и обработка ошибок, ибо операции ввода/ вывода типа записи на диск или считывания с диска, сопутствующие «постоянному хранению» (Persistence), порождают достаточное количество возможных фатальных ошибок, требующих обработки. Что касается JSON формата, то в Swift существует очень мощный Codable механизм, который позволяет практически любую структуру struct или перечисление enum превратить в  Blob данных в формате JSON.

Все 3 темы — «постоянное хранение» (Persistence), обработка ошибок  и механизм Codable — сначала рассматриваются теоретически, а затем и в демонстрационном примере. Читать далее

Лекция 8. Анимация. Демонстрация. CS193P Spring 2021.

Это восьмая Лекция курса Stanford CS193p, весна 2021 года. Лекция 8 полностью посвящена демонстрации различных возможностей анимации в SwiftUI:

  • matchedGeometryEffect, который действует при сдаче карт
  • переворот карты, который осуществляется нашим специальным Animatable модификатором Cardify
  •  анимация нашей геометрической фигуры Shape в виде “пирога” Pie
  • неявная анимация, которая крутит эмодзи при совпадении карт
  • перетасовка карт и выбор карты представляют явную анимацию
  • запуск анимации при появлении (.onAppear) некоторых вещей
  • как задерживать анимацию карт при их сдаче
  • как диагностировать проблемы, когда у нас не происходит анимация, которую мы ожидаем при появлении на экране и уходе с экрана View, которое является частью условного предложения if-else

Читать далее

Лекция 7. Модификаторы ViewModifier. Анимация. CS193P Spring 2021.

Это седьмая Лекция курса Stanford CS193p, весна 2021 года. Лекция  7 и Лекция 8 полностью посвящены анимации. Мы собираемся выяснить, как она работает. По ходу дела нам придется изучить модификаторы ViewModifier, которые очень сильно вовлечены в процесс анимации.

Объясняется протокол ViewModifier, который затем используется для того, чтобы сделать возможным преобразование любого View в карту игры Memorize путем «картафикации» ( от слова «карта»). Затем лекция переходит к углубленному рассмотрению анимации и начинает комплексную многолекционную демонстрацию анимации. 

Если Лекция 8 — это, по существу, демо-Лекция, на которой профессор Пол Хэгерти демонстрирует все возможные анимации, какие только вы можете себе представить, то на Лекции 7 изложены теоретические основы анимации и представлено начало (неявная анимация, чтобы заставить смайлик на Memorize карте вращаться, когда она совпадает с другой картой, и модификаторы ViewModifier) той огромной демонстрации, которая последует на Лекции 8.

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

Золотые правила анимации.

Только изменения могут анимироваться. Если ничего не изменяется, то ничего не будет анимироваться. Это фундаментальное правило.

 Какого рода изменения могут анимироваться?

Реально в SwiftUI, только 3 типа изменений:

  • аргументы модификаторов ViewModifiers,
  • геометрические фигуры Shapes, то есть аргументы при создании Shapes,
  • “появление” или «уход» Views на UI.

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

Модификаторы ViewModifiers — это основные “агенты изменений” в UI, но изменение аргументов ViewModifier должно произойти ПОСЛЕ того, как View разместился на UI. Другими словами, изменения аргументов модификаторов рассматриваются системой анимации только ПОСЛЕ момента присоединения View к  UI.

Читать далее

Лекция 4. Больше о MVVM enum Optional. CS193P Spring 2021.

Это четвертая Лекция курса Stanford CS193p, весна 2021 года, и она сразу начинается с продолжения демонстрационного примера прошлой Лекции 3, на которой были сконструированы модель Model и ViewModel для карточной игры «на запоминание» MemorizeView  (то есть UI) мы создали на Лекциях 1и 2. На этой Лекции архитектура MVVM реализуется во всей своей реактивной мощи.

После того, как MVVM заработает, профессор возвращается к слайдам, чтобы вкратце поговорить о двух вещах. Первая  — это еще один системный ТИП Swift, называемый перечислением enum, а вторая — это специальная версия перечисления enum, называемая Optional. Наверное, это одно из самых важных перечислений enum, если не самое главное enum во всем Swift.

Читать далее

Лекция 3. MVVM и система ТИПов в Swift. CS193P Spring 2021.

Это третья Лекция курса Stanford CS193p, весна 2021 года. На первых двух Лекциях мы много узнали о том, как создавать UI, используя SwiftUI на примере карточной игры «на запоминание» Memorize

На этой неделе мы узнаем, как “подцепить” наш UI к логике, которая знает, как играть в карточную игру “на совпадение”. Но сначала профессор рассматривает две действительно важные концептуальные идеи: MVVM и системные ТИПы языка программирования Swift.

MVVM

MVVM — это, по сути, способ организации всего кода в нашем приложении. 

Системные ТИПы в Swift, очевидно, позволяют нам делать все, что мы делаем в языке программирования Swift и, следовательно, в SwiftUI.

MVVM, как и MVC, разделяет весь код нашего приложения на код пользовательского интерфейса (UI), то есть то, что мы называем View, от логики нашего приложения, которую мы называем моделью Model.

Model —  полностью UI НЕзависима. Model вбирает в себя все данные Data и логику Logic, которые  описывают “ЧТО” делает ваше приложение. View — это то, «КАК» ваше приложение предстает перед пользователем,  Model — это то, “ЧТО”  ваше приложение делает на самом деле. Model — единственный источник ИСТИНЫ (“Truth”) для данных, которые представляют нашу игру. 

 View всегда будет отражением текущего состояния Model. View по большому счету вообще не имеет состояния State (то есть оно stateless). Ему не нужно хранить слишком много информации о состояниях State, потому что ИСТИНА (“Truth”) о состоянии игры всегда находится в Model. В демонстрационном приложении Memorize, который мы делали на прошлой неделе, всё своё время мы проводили за написанием кода для переменной var body нашего View. Этот var body всегда должен что-то возвращать на основе текущего состояния Model. Views — неизменны (immutable). Их нельзя изменить. Следовательно, нет другого способа изменить наш View, кроме как целиком перестроить var body. Следовательно, 100% того, как  выглядит View, определяется исключительно тем, что находится в  реализации переменной var body.

Мы называем этот вид кодирования декларативным, потому что мы декларируем в переменной var body, как выглядит пользовательский интерфейс (UI) нашего View. Конец истории. Это противоположно виду кодирования, к которому мы привыкли и который мы называем императивным.

Читать далее