Комментарии 30
Очень полезная статья. Спасибо.
\.self означает что типа замыкания { (it) in it.self }?
не совсем.
id нужен для внутренней работы ForeEach, что бы он мог для каждого элемента построить свою View с помощью переданного контента. Эту View нужно связать с элементом с помощью какого-то ключа. Параметр id, это именно указание, какой реквизит использовать для этой связи в качестве уникального ключа элемента коллекции. Для этого используется вариант инициализатора с указанием ключевого атрибута.
Когда указывается id: \.self, это значит, что в качестве ключа будет использован непосредственно сам элемент, а точнее, его хэш. Именно поэтому, указанный реквизит, или сам объект в случае \.self должен удовлетворять протоколу Hashiable
А в замыкание просто передается элемент коллекции Data, для которого нужно нарисовать отдельную View {Item in ...}
Подробнее о KeyPath можно почитать, например, тут
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 можно почитать, например, тут
С непревычки немного заморочено. Но вроде понял.
ps: почему-то сразу вспомнился perl :)
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 :)
Также уродливо как и flutter =(
Отлично написано. Сам на таком же старте (учу Swift, начиная с SwitfUI). Статья многое объясняет. Спасибо!
Пожалуйста. Я довольно много времени потратил впустую, ковыряясь со своим первым проектом. В сети есть несколько примеров простых приложений, но стоит попытаться отойти от них чуть в сторону — и тут же начинаются грабли. Мне по началу очень не хватало системного понимания, что это такое, и как оно работает. Простые листинги кода в этом мало помогали. Пришлось прокачивать английский, и лезть на StackOverflow. Там довольно часто встречаются толковые объяснения.
Решил что немного систематизированной информации будет полезно для коллег, и написал эту статью.
Решил что немного систематизированной информации будет полезно для коллег, и написал эту статью.
Я начал изучать UIKit, но теперь вот думаю делать упор на SwiftUI. Те же аналогии возникли с обычным/управляемым интерфейсом, только в 1с все-таки упр. формы — это необходимость при работе в режиме тонкого и веб-клиента, а SwiftUI — эволюция интерфейса в мире Swift. И вроде бы необходимости нет, но новая концепция мне определенно нравится больше. Хотел поинтересоваться, мобильная разработка — хобби или с 1С удалось завязать?
Все зависит от того, насколько успешно все с моим пет-проектом. В данный момент, я сосредоточил на нем 100% своего времени. Надеюсь, с его помощью получится закрепиться на ниве мобильной разработки.
Впрочем, совсем забрасывать 1с я не хочу даже в случае его успеха. Я вижу непаханое поле на пересечении мобильной разработки и автоматизации бизнеса (ритейла в частности, т.к. основные мои компетенции наработаны именно вокруг ритейла).
Впрочем, совсем забрасывать 1с я не хочу даже в случае его успеха. Я вижу непаханое поле на пересечении мобильной разработки и автоматизации бизнеса (ритейла в частности, т.к. основные мои компетенции наработаны именно вокруг ритейла).
А что касается UIKit, то переход на SwiftUI с целью трудоустройства может быть преждевременным. В SwiftUI полно багов. Разработка пока похожа на танцы с бубнами — больше чем обычно. Описание ошибок в SwiftUI — штука такая. Почти рандомная. Проблема может быть в одной строчке кода, а компилятор ругается на совсем другие, с совсем другим описанием ошибки.
И по поводу багов — это действительно проблема для production. Например, NavigationLink (способ навигации между экранами, замена сегвеям) — сломан в текущем релизе XCode(11.3.1). Он работает только 1 раз. Т.е. вы сходили по ссылке, вернулись назад, кликаете на ту же ссылку — и ничего не происходит. До тех пор пока вы не сходите по другой ссылке — тогда первая заработает, но вторя останется недоступной.
И по поводу багов — это действительно проблема для production. Например, NavigationLink (способ навигации между экранами, замена сегвеям) — сломан в текущем релизе XCode(11.3.1). Он работает только 1 раз. Т.е. вы сходили по ссылке, вернулись назад, кликаете на ту же ссылку — и ничего не происходит. До тех пор пока вы не сходите по другой ссылке — тогда первая заработает, но вторя останется недоступной.
По поводу NavigationLink, у меня эта проблема воспроизводилась только в симуляторе. На девайсе все вроде нормально. Но там других багов хватает.
Сразу вопрос, вы делали проекты на SwiftUI? Предвижу что вы спросите меня тоже самое. У меня на GitHub есть свой достаточно большой проект github.com/filimo/ReaderTranslator.git на SwiftUI для macOS и iOS. Проблем с багами нет. Если хотите подискутировать и узнать больше о SwiftUI то велком на телеграм канал t.me/swift_ui
Живых работающих проектов — нет, только домашние песочницы. Впрочем, я планирую на основе одной из них сделать несколько публикаций. В первую очередь, чтобы меня ткнули носом, если где-то можно сделать лучше. Ну и сам материал постараюсь сделать полезным.
Посмотрел сценарий использования. В чем преимущество перед встроенной командой в MacOS и iOS Найти/Look up? Можно настроить словари, есть перевод, транскрипция, вызывается одним движением.
Цель проекта:
— снять негативный налет со 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)
— перевода выделенного текста из других приложениях
— снять негативный налет со 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)
— перевода выделенного текста из других приложениях
Благодарю за подробный туториал, очень понятно всё разобрано, ничего лишнего! Действительно, похоже на Flutter.
Сам пишу под Android, но периодически имею дело с iOS, и хотелось быть в курсе технологий. :-)
Сам пишу под Android, но периодически имею дело с iOS, и хотелось быть в курсе технологий. :-)
Поковырялся в SwiftUI. До этого вообще не работал в mobile dev. Очень понравилось. Буду изучать swift. Только расстраивает то что он вообще не готов для продакшна. Но вообще очень приятная вещь.
Хорошо помню, как оно было с управляемыми формами от 1с. Пока перед заказчиками стыдно не стало, что мы все еще пилим на обычных формах, убедить себя с ними разобраться не получалось. А менеджменту вообще без разницы, на чем там мы кодим — главное чтобы спайс не переставал поступать.
Так что это в первую очередь люди не готовы, как мне кажется.
Так что это в первую очередь люди не готовы, как мне кажется.
ошибочка вышла. Промахнулся. А удалить комментарий не получается
Спасибо за статью. Изучаю swift для своих пет-проектов (не для работы) и как раз встал вопрос куда двигаться дальше: UIKit / SwiftUI. В частности, хотел бы сделать приложение для вокальных распевок с проигрыванием заготовленных гамм вверх/вниз по клавиатуре. Основные элементы интерфейса: рисованные кнопки “влево / вправо”, анимация клавиатуры, название нот. Что-то подобное реально сделать на SwiftUI? Или тут понадобятся какие-то готовые библиотеки, которых под SwiftUI еще не написаны?
Не могу сказать, что обладаю большим опытом написания реальных приложений на SwiftUI. То, что я пока видел — очень воодушевляюще. Рисованные кнопки — да запросто. Что угодно может быть кнопкой, если к этому прилепить
В принципе, любую задачу, решаемую на SwiftUI, можно решить и на UIKit. И грамотно составленный код на UIKit, возможно, будет даже быстрее работать. Вопрос только во времени, которое вы затратите на этот код, и вероятности, что код написан не оптимально. В последнем случае, UIKit может оказаться медленнее SwiftUI.
Ну и последнее. SwiftUI умеет еще не все. Некоторые задачи решаются только путем создания элемента на UIKit и встраивания его в SwiftUI View с помощью специального контроллера.
.onTapGesture(), в том числе и Image. Анимация — легко . Подписи к кнопкам — всего-то использовать .overlay(Text("Кнопка")). Единственное, для проигрывания аудио потребуется AVAudioPlayer из Foundation — но его в любом случае использовать, что в SwiftUI, что в UIKit (ну или какие-то другие библиотеки для работы со звуками, все таки SwiftUI — это про изображение).В принципе, любую задачу, решаемую на SwiftUI, можно решить и на UIKit. И грамотно составленный код на UIKit, возможно, будет даже быстрее работать. Вопрос только во времени, которое вы затратите на этот код, и вероятности, что код написан не оптимально. В последнем случае, UIKit может оказаться медленнее SwiftUI.
Ну и последнее. SwiftUI умеет еще не все. Некоторые задачи решаются только путем создания элемента на UIKit и встраивания его в SwiftUI View с помощью специального контроллера.
Спасибо за развернутый ответ. Пожалуй, попробую двинуть в сторону SwiftUI. Помимо прочего, его новизна и перспективность чисто психологически привлекает гораздо больше :) Может посоветуете какие-то материалы для плавного погружения в тему? Видел курс 100 дней SwiftUI от Hackingwithswift, но, если честно, масштабы пугают (неужели столько времени надо на освоение?).
Если речь о введении в тему, то можно посмотреть русскоязычный курс на SwiftBook.ru.
Если речь о промышленном, так сказать, использовании, то время на освоение очень сильно зависит от начальной базы. Я с мобильной разработкой никак не был связан, так что да, времени ушло много, чтобы со всем разобраться. Именно курс 100 дней я не проходил, но на Hackingwithswift действительно много полезных материалов. К сожалению, их недостаточно. Их можно взять за точку отсчета, но для реального использования придется значительно углубиться в тему.
Как я уже писал выше, у меня, например, возникли определенные сложности с CoreData. На Hackingwithswift есть раздел на тему SwiftUI + CoreData, но там подразумевается, что вы уже знаете как работать с CoreData в принципе, и нужно только понять, как это к SwiftUI приложить.
Следующая статья (или через одну, я еще работаю над планом выхода статей) будет именно об этом.
Если речь о промышленном, так сказать, использовании, то время на освоение очень сильно зависит от начальной базы. Я с мобильной разработкой никак не был связан, так что да, времени ушло много, чтобы со всем разобраться. Именно курс 100 дней я не проходил, но на Hackingwithswift действительно много полезных материалов. К сожалению, их недостаточно. Их можно взять за точку отсчета, но для реального использования придется значительно углубиться в тему.
Как я уже писал выше, у меня, например, возникли определенные сложности с CoreData. На Hackingwithswift есть раздел на тему SwiftUI + CoreData, но там подразумевается, что вы уже знаете как работать с CoreData в принципе, и нужно только понять, как это к SwiftUI приложить.
Следующая статья (или через одну, я еще работаю над планом выхода статей) будет именно об этом.
Я в статье утверждал:
Как оказалось это не совсем так. Я в своих тестах использовал не прямое присвоение нового значения, а
Вы не сможете использоватьdidSetwillSetсобытия параметров структуры, обернутых в какие-то обертки.
Как оказалось это не совсем так. Я в своих тестах использовал не прямое присвоение нового значения, а
value += 1bool.toggle()
Спасибо. Очень полезная статья
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SwiftUI по полочкам