Лекция 9. Анимация (часть 2). CS193P Spring 2023.

Ниже представлен небольшой фрагмент Лекции 9 Стэнфордского курса CS193P Весна 2023 «Разработка iOS приложений с помощью SwiftUI«.
Полный русскоязычный неавторизованный конспект Лекции 9 в формате Google Doc и в виде PDF-файла, который можно скачать и использовать offline, доступны здесь.
Код находится на GitHub.

С полным перечнем Лекций и Домашних Заданий на русском языке можно познакомиться здесь.

. . . . . . . . . . . . . .

Колоду карт довольно просто реализовать.

Это может быть private переменной var, которая является some View и представляет собой ZStack несданных карт undealtСards. Не сданные карты undealtСards находятся прямо вверху и я создал их ранее. Мы будем рисовать несданных карт undealtСards с помощью того же CardView, что мы нарисовали любые другие карты:

Но есть кое-что, что я хочу сделать с этим — я хочу явно указать размер колоды карт с помощью маленького ViewModifier, который я покажу сегодня — это .frame, им очень легко злоупотребить, будьте очень осторожны при его использовании.
О чем .frame?
Я говорил вам, что Views сами решают, какого размера они хотят быть, помните это?
Они могут это сделать с помощью .frame. Но сам по себе .frame в реальности не будет определять размер самого View. Это больше похоже на создание контейнера этого размера и предложения View этого пространства.

Помните, как при размещении Views на экране (Layout) вам предлагается пространство, a View сам определяет свой размер, чтобы там поместиться?
Таким образом, .frame предоставит вам пространство.
Теперь CardView использует всё предоставленное ему пространство.
Итак, я могу написать .frame(width: deckWidth, height: deckWidth / aspectRatio), где deckWidth — это ширина моей колоды карт, и я позже сделаю для нее константу. Высота колоды, конечно же, будет равна ширине колоды деленной на соотношение сторон aspectRatio:

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

Теперь причина, по которой я сказал, что этим легко злоупотребить. 
Посмотрите, как мы программируем, мы никогда не указываем точные размеры вещей, мы просто размещаем их в VStacks и HStacks или располагаем в AspectVGrid и все такое. И мы даже использовали GeometryReader, чтобы узнать, a сколько у меня места? Потом мы разделяли полученное пространство между нужными нам Views, которые как бы отреагировали на то, сколько места им дали..
Единственный раз, когда мы выбрали фиксированный размер — это наш теперешний случай, когда мы создали пространство фиксированного размера, чтобы наш View (колода карт) в нем разместился.
И мы даже использовали GeometryReader, чтобы узнать, a сколько у меня места? Потом мы разделяли полученное пространство между нужными нам Views, которые как бы отреагировали на то, сколько места им дали.
Здесь я выбираю конкретную ширину колоды deckWidth равную 50:

Читать далее

Лекция 7. Shape, ViewModifier, Constants. CS193P Spring 2023.

Ниже представлен фрагмент Лекции 7 Стэнфордского курса CS193P Весна 2023 «Разработка iOS приложений с помощью SwiftUI«.
Полный русскоязычный неавторизованный конспект Лекции 7 в формате Google Doc и в виде PDF-файла, который можно скачать и использовать offline, доступны здесь.

Код находится на GitHub.

С полным перечнем Лекций и Домашних Заданий на русском языке можно познакомиться здесь.

Что мы делаем сегодня? 

. . . . . . . . . .

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

Вы видели, как взлетела маленькая цифра +2? Это говорит о том, сколько я получил баллов.
Позвольте мне еще раз попытаться получить больше очков. Теперь хорошо, количество очков +13.

Демонстрационный пример Shape

Итак, мы собираемся создать этот маленький круглый “пирог” Pie, который ведет обратный отсчет. Мы не будем анимировать его сегодня, но мы создадим свою собственную геометрическую фигуру Shape в виде маленького “пирога”.

Для того, чтобы мы могли увидеть, что здесь происходит, я собираюсь измениться количество карт, которые у меня есть в игре, до четырех карт:

И мы положим все наши карты “лицом” вверх,  потому что мы собираемся разместить там “пирог” Pie:

Давайте начнем с нашего CardView, который вы видите здесь на экране.
Я размещу там круг Circle ( ) вместо “пирога” Pie:

И это ZStack. Они сгруппированы с помощью Group, но это все еще ZStack
И я просто помещаю Circle() позади текста Text. Мы почти закончили, правда?
Это не “пирог” Pie, а круг Circle(), и он имеет ярко-оранжевый цвет, пожалуй, слишком яркий, ведь таймер не так уж и важен. Давайте к нашему кругу Circle() добавим немного непрозрачности
.opacity ( 0.5 ):

Можно было бы снизить до .opacity ( 0.4 ):

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

Читать далее

Лекция 6. Layout, @ViewBuilder. CS193P Spring 2023.

Ниже представлен фрагмент Лекции 6 Стэнфордского курса CS193P Весна 2023 «Разработка iOS приложений с помощью SwiftUI«.
Полный русскоязычный неавторизованный конспект Лекции 6 в формате Google Doc и в виде PDF-файла, который можно скачать и использовать offline, доступны здесь.
Код находится на GitHub.

С полным перечнем Лекций и Домашних Заданий на русском языке можно познакомиться здесь.

На сегодняшней Лекции 6, a, по сути, на всей этой неделе мы подберем несколько тем и попытаемся понять больше о том, как то, что мы делали, действительно работает.

Первая тема — это Layout, то есть расположение Views на экране. Как место на экране распределяется между всеми Views с помощью HStack, LazyVGrid, ScrollView и всех других подобных вещей? Как они решают, кому какое место достанется?
Затем у нас будет небольшая демонстрация.

Аналогичная ситуация с @ViewBuilder.
У нас есть есть такая классная штука как @ViewBuilder. Мы знаем, что это просто функция, которая возвращает some View. Но мы также знаем, что это круто и что это список Views, там есть if else, if let, switch и локальные переменные.
Так как же работает @ViewBuilder? Я не буду говорить о том, как на самом деле реализован @ViewBuilder, но я собираюсь поговорить о том, как вы его используете и как он работает.

Расположение на экране: Layout.

Как пространство на экране назначается и распределяется между всеми Views, которые там появляются? И это на самом деле это невероятно элегантная маленькая система и очень-очень простая, но в то же время с очень строгими правилами. Это делает расположение Views настолько невероятно предсказуемым, почти 100% предсказуемым.

Работа системы Layout состоит из 3-х шагов:

Первый шаг состоит, конечно, в том, что Views предоставляется некоторое пространство. Например, вашему ContentView, который находится в самом верху вашего приложения, доступен весь экран. Это отправная точка.
Но как только вы начнете создавать HStacks и VGrids, вам предлагают все меньше и меньше места по мере того, как вы спускаетесь вниз по иерархии Views.
Контейнерам Views, таким как HStack или VGrid или другим подобным им контейнерам, предлагается определенное пространство, a они в свою очередь предлагают его своим “детям”-Views с помощью определенных алгоритмов. 

Затем выполняется второй шаг, крайне важный и все дело именно в нём, он заставляет всю систему Layout действительно работать, потому что после того, как Views предложат пространство, даже если это обычный текст Text или изображение Image или что-то еще, ОНИ ВЫБИРАЮТ, какого размера они хотят быть. Единственный, кто может выбрать размер View — это само View. Невозможно принудительно указать размер View, ОНИ сами выбирают свой размер в зависимости от предложенного им пространства. Мы собираемся поговорить о том, как они это делают, но это НЕРУШИМОЕ ПРАВИЛО: Views ВЫБИРАЮТ свой собственный размер.
И именно это во многом делает систему Layout полностью предсказуемой, у вас не бывает странных случаев, когда вы действительно не понимаете, что произойдет. Никто никому ничего не навязывает.

Затем, на третьем шаге, как только Views выбрали свои размеры, они хотят вернуться в контейнер Views, который предлагал им пространство, и быть размещенными внутри него. 
Теперь, когда контейнеры Views знают все размеры, они могут размещать все вещи внутри себя, Например, HStack размещает Views, сдвигая их вправо или влево. То есть позиционирование Views полностью зависит от HStack.
Таким образом, размеры Views выбираются самими Views, а позиционирование осуществляется контейнерами Views.

Так работает система Layout. И это всегда работает таким образом, и у этого есть действительно хороший маленький протокол protocol Layout для исполнения этого «танца». Я покажу, как выглядит этот протокол, когда мы доберемся до демонстрационного примера.

Читать далее

Лекция 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 — сначала рассматриваются теоретически, а затем и в демонстрационном примере. Читать далее

Лекция 10. Жесты. CS193P Spring 2021.

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

На прошлой Лекции 9 мы узнали многое о многопоточности. Мы также стали специалистами по технологии Drag & Drop (перетягивание и «сброс)», теперь пришло время использовать этот механизм для формирования нашего фонового изображения background. Мы хотим иметь возможность перетаскивать (Drag) изображение из Safari, “сбрасывать” его на наш документ и формировать background нашего документа. В таком сценарии мы будет отвечать только за “сброс” (Drop), перетаскивание (Drag) выполняется Safari. Так что нам даже не нужен модификатор .onDrag, нам достаточно иметь просто .onDrop.

В нашем documentBody уже есть модификатор .onDrop, предназначенный для «сброса» наших маленьких эмодзи из палитры, теперь мы заинтересованы также в получении URL-адресов изображения .url, а также самого изображения .image. Профессор показывает, как просто можно дополнять перечень «сбрасываемых» и загружаемых объектов в модификатор .onDrop.

Но дело в том, что сброс URL-адреса изображения предполагает последующую его загрузку из интернета, а это может занять несколько секунд или даже минуту при медленном интернете. В этом случае, если не предпринять надлежащие меры, наше приложение может просто «замереть», заставить пользователя нервничать и он может буквально “убить” наше приложение, a затем вообще стереть его со своего устройства. Необходимость любой ценой сохранить отзывчивость UI для пользователя вынуждает нас использовать многопоточность, о которой мы говорили на слайдах на прошлой лекции. На этом стэнфордском курсе использование многопоточности рассматривается исключительно в этом очень важном аспекте, связанным с НЕ блокировкой UI. Мы не будем блокировать UI, если все, что может заблокировать наш UI, будет выполняться на другом потоке. О том, как это можно сделать, было рассказано на прошлой Лекции 9, а на этой Лекции профессор конкретно демонстрирует это в приложении EmojiArt.

Читать далее

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

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

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

Читать далее