@aspid-crazy26 янв 2020 в 14:13

SwiftUI по полочкам

24 мин

103K

Дизайн мобильных приложений * Разработка мобильных приложений * iOS *

Из песочницы

+16

Комментарии 30

@candyapple 26 янв 2020 в 19:41

Очень полезная статья. Спасибо.

@aspid-crazy 26 янв 2020 в 21:41

Благодарю. В процессе ее написания я и для себя многое по полочкам разложил.

@kovserg 26 янв 2020 в 20:47

\.self означает что типа замыкания { (it) in it.self }?

@aspid-crazy 26 янв 2020 в 21:04

не совсем.
id нужен для внутренней работы ForeEach, что бы он мог для каждого элемента построить свою View с помощью переданного контента. Эту View нужно связать с элементом с помощью какого-то ключа. Параметр id, это именно указание, какой реквизит использовать для этой связи в качестве уникального ключа элемента коллекции. Для этого используется вариант инициализатора с указанием ключевого атрибута.

init(_ data: Data, id: KeyPath<Data.Element, ID>, content: @escaping (Data.Element) -> Content)

Когда указывается id: \.self, это значит, что в качестве ключа будет использован непосредственно сам элемент, а точнее, его хэш. Именно поэтому, указанный реквизит, или сам объект в случае \.self должен удовлетворять протоколу Hashiable

А в замыкание просто передается элемент коллекции Data, для которого нужно нарисовать отдельную View {Item in ...}

Подробнее о KeyPath можно почитать, например, тут

@kovserg 27 янв 2020 в 03:17

С непревычки немного заморочено. Но вроде понял.

code

struct Article {
    let title: String
    let body: String
}
let a1 = Article(title:"title", body:"body")

let v1 : (Article)->String = { (it) in it.title }
print("v1:",type(of:v1),v1(a1))

let v2 : (Article)->String = { $0.title }
print("v2:",type(of:v2),v2(a1))

let v3 : KeyPath<Article,String> = \.title
print("v3:",type(of:v3),a1[keyPath:v3])

let v4 = \Article.title
print("v4:",type(of:v3),a1[keyPath:v4])

v1: (Article) -> String title

v2: (Article) -> String title

v3: WritableKeyPath<Article, String> title

v4: WritableKeyPath<Article, String> title

ps: почему-то сразу вспомнился perl :)

@gian_tiaga 26 янв 2020 в 21:15

Также уродливо как и flutter =(

@adictive_max 27 янв 2020 в 03:44

А есть где-нибудь не уродливо?

@hardtop 27 янв 2020 в 05:59

Отлично написано. Сам на таком же старте (учу Swift, начиная с SwitfUI). Статья многое объясняет. Спасибо!

@aspid-crazy 27 янв 2020 в 09:32

Пожалуйста. Я довольно много времени потратил впустую, ковыряясь со своим первым проектом. В сети есть несколько примеров простых приложений, но стоит попытаться отойти от них чуть в сторону — и тут же начинаются грабли. Мне по началу очень не хватало системного понимания, что это такое, и как оно работает. Простые листинги кода в этом мало помогали. Пришлось прокачивать английский, и лезть на StackOverflow. Там довольно часто встречаются толковые объяснения.

Решил что немного систематизированной информации будет полезно для коллег, и написал эту статью.

@PS_erg 27 янв 2020 в 08:59

Я начал изучать UIKit, но теперь вот думаю делать упор на SwiftUI. Те же аналогии возникли с обычным/управляемым интерфейсом, только в 1с все-таки упр. формы — это необходимость при работе в режиме тонкого и веб-клиента, а SwiftUI — эволюция интерфейса в мире Swift. И вроде бы необходимости нет, но новая концепция мне определенно нравится больше. Хотел поинтересоваться, мобильная разработка — хобби или с 1С удалось завязать?

@aspid-crazy 27 янв 2020 в 09:08

Все зависит от того, насколько успешно все с моим пет-проектом. В данный момент, я сосредоточил на нем 100% своего времени. Надеюсь, с его помощью получится закрепиться на ниве мобильной разработки.

Впрочем, совсем забрасывать 1с я не хочу даже в случае его успеха. Я вижу непаханое поле на пересечении мобильной разработки и автоматизации бизнеса (ритейла в частности, т.к. основные мои компетенции наработаны именно вокруг ритейла).

@aspid-crazy 27 янв 2020 в 09:21

А что касается UIKit, то переход на SwiftUI с целью трудоустройства может быть преждевременным. В SwiftUI полно багов. Разработка пока похожа на танцы с бубнами — больше чем обычно. Описание ошибок в SwiftUI — штука такая. Почти рандомная. Проблема может быть в одной строчке кода, а компилятор ругается на совсем другие, с совсем другим описанием ошибки.

И по поводу багов — это действительно проблема для production. Например, NavigationLink (способ навигации между экранами, замена сегвеям) — сломан в текущем релизе XCode(11.3.1). Он работает только 1 раз. Т.е. вы сходили по ссылке, вернулись назад, кликаете на ту же ссылку — и ничего не происходит. До тех пор пока вы не сходите по другой ссылке — тогда первая заработает, но вторя останется недоступной.

@leonspok 27 янв 2020 в 13:12

По поводу NavigationLink, у меня эта проблема воспроизводилась только в симуляторе. На девайсе все вроде нормально. Но там других багов хватает.

@filimo 4 фев 2020 в 21:17

Сразу вопрос, вы делали проекты на SwiftUI? Предвижу что вы спросите меня тоже самое. У меня на GitHub есть свой достаточно большой проект github.com/filimo/ReaderTranslator.git на SwiftUI для macOS и iOS. Проблем с багами нет. Если хотите подискутировать и узнать больше о SwiftUI то велком на телеграм канал t.me/swift_ui

@aspid-crazy 4 фев 2020 в 21:21

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

@PS_erg 5 фев 2020 в 08:18

Посмотрел сценарий использования. В чем преимущество перед встроенной командой в MacOS и iOS Найти/Look up? Можно настроить словари, есть перевод, транскрипция, вызывается одним движением.

@filimo 6 фев 2020 в 10:31

Цель проекта:
— снять негативный налет со SwiftUI что фреймворк еще не готов для продакшена
— демонстрация возможностей SwiftUI, Combine и других новых Apple фреймворков
— пример архитектуры SwiftUI проектов на практике
С полным списком текущих возможностей проекта можно ознакомиться в разделе Issues, сейчас их больше 70 и в каждом из них есть еще sub-issues.

macOS версия:
— интегрирует в себя такие сервисы как Google Translate, Yandex переводчик, Reverso, MacMillan, Longman, Collins, MerriamWebster, StackExchange, Wikipedia
— имеет встроенный браузер и Safari extension
— автоматический перевод выделенного текста в этих сервисах, встроенном браузере, pdf или Safari через эти сервисы
— просмотр видео с WWDC с регулировкой скорости воспроизведения, перемоткой, подсветкой произносимых фраз, горячими клавишами и переводом в одно нажатие
— озвучкой выделенного текста через Voice engine с настройкой голоса
— озвучкой выделенных слов профессиональными дикторами (British, American)
— возможностью чтения pdf книг с паралельным прослушиванием, регулировкой скорости воспроизведения и удобной перемоткой
— функциональность для составления своего словаря, встроен механиз повторения слов и выражений с примерами предложений и озвучкой профессиональными дикторами

Мобильная версия:
— прослушивания аудио материалов с регулеровкой скорости и удобной перемоткой
— работа со своим словарем с переводом и примерами использование слова в предложениях с озвучкой профессиональх дикторов (British, American)
— перевода выделенного текста из других приложениях

@Firsto 27 янв 2020 в 09:32

Благодарю за подробный туториал, очень понятно всё разобрано, ничего лишнего! Действительно, похоже на Flutter.

Сам пишу под Android, но периодически имею дело с iOS, и хотелось быть в курсе технологий. :-)

@aspid-crazy 27 янв 2020 в 09:35

Рад помочь. Я планирую написать еще несколько статей в том же стиле, но уже более конкретных, на живых примерах. В частности о CoreData + SwiftUI. Подписывайтесь:)

@oolooq 27 янв 2020 в 09:37

Поковырялся в SwiftUI. До этого вообще не работал в mobile dev. Очень понравилось. Буду изучать swift. Только расстраивает то что он вообще не готов для продакшна. Но вообще очень приятная вещь.

@aspid-crazy 27 янв 2020 в 09:45

Хорошо помню, как оно было с управляемыми формами от 1с. Пока перед заказчиками стыдно не стало, что мы все еще пилим на обычных формах, убедить себя с ними разобраться не получалось. А менеджменту вообще без разницы, на чем там мы кодим — главное чтобы спайс не переставал поступать.

Так что это в первую очередь люди не готовы, как мне кажется.

@aspid-crazy 27 янв 2020 в 09:45

ошибочка вышла. Промахнулся. А удалить комментарий не получается

@lirnik1 27 янв 2020 в 11:25

Спасибо за статью. Изучаю swift для своих пет-проектов (не для работы) и как раз встал вопрос куда двигаться дальше: UIKit / SwiftUI. В частности, хотел бы сделать приложение для вокальных распевок с проигрыванием заготовленных гамм вверх/вниз по клавиатуре. Основные элементы интерфейса: рисованные кнопки “влево / вправо”, анимация клавиатуры, название нот. Что-то подобное реально сделать на SwiftUI? Или тут понадобятся какие-то готовые библиотеки, которых под SwiftUI еще не написаны?

@aspid-crazy 27 янв 2020 в 11:38

Не могу сказать, что обладаю большим опытом написания реальных приложений на SwiftUI. То, что я пока видел — очень воодушевляюще. Рисованные кнопки — да запросто. Что угодно может быть кнопкой, если к этому прилепить .onTapGesture(), в том числе и Image. Анимация — легко . Подписи к кнопкам — всего-то использовать .overlay(Text("Кнопка")). Единственное, для проигрывания аудио потребуется AVAudioPlayer из Foundation — но его в любом случае использовать, что в SwiftUI, что в UIKit (ну или какие-то другие библиотеки для работы со звуками, все таки SwiftUI — это про изображение).

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

Ну и последнее. SwiftUI умеет еще не все. Некоторые задачи решаются только путем создания элемента на UIKit и встраивания его в SwiftUI View с помощью специального контроллера.

@lirnik1 27 янв 2020 в 12:19

Спасибо за развернутый ответ. Пожалуй, попробую двинуть в сторону SwiftUI. Помимо прочего, его новизна и перспективность чисто психологически привлекает гораздо больше :) Может посоветуете какие-то материалы для плавного погружения в тему? Видел курс 100 дней SwiftUI от Hackingwithswift, но, если честно, масштабы пугают (неужели столько времени надо на освоение?).

@aspid-crazy 27 янв 2020 в 13:38

Если речь о введении в тему, то можно посмотреть русскоязычный курс на SwiftBook.ru.

Если речь о промышленном, так сказать, использовании, то время на освоение очень сильно зависит от начальной базы. Я с мобильной разработкой никак не был связан, так что да, времени ушло много, чтобы со всем разобраться. Именно курс 100 дней я не проходил, но на Hackingwithswift действительно много полезных материалов. К сожалению, их недостаточно. Их можно взять за точку отсчета, но для реального использования придется значительно углубиться в тему.

Как я уже писал выше, у меня, например, возникли определенные сложности с CoreData. На Hackingwithswift есть раздел на тему SwiftUI + CoreData, но там подразумевается, что вы уже знаете как работать с CoreData в принципе, и нужно только понять, как это к SwiftUI приложить.

Следующая статья (или через одну, я еще работаю над планом выхода статей) будет именно об этом.