Хорошо помню, как оно было с управляемыми формами от 1с. Пока перед заказчиками стыдно не стало, что мы все еще пилим на обычных формах, убедить себя с ними разобраться не получалось. А менеджменту вообще без разницы, на чем там мы кодим — главное чтобы спайс не переставал поступать.
Так что это в первую очередь люди не готовы, как мне кажется.
Рад помочь. Я планирую написать еще несколько статей в том же стиле, но уже более конкретных, на живых примерах. В частности о CoreData + SwiftUI. Подписывайтесь:)
Пожалуйста. Я довольно много времени потратил впустую, ковыряясь со своим первым проектом. В сети есть несколько примеров простых приложений, но стоит попытаться отойти от них чуть в сторону — и тут же начинаются грабли. Мне по началу очень не хватало системного понимания, что это такое, и как оно работает. Простые листинги кода в этом мало помогали. Пришлось прокачивать английский, и лезть на StackOverflow. Там довольно часто встречаются толковые объяснения.
Решил что немного систематизированной информации будет полезно для коллег, и написал эту статью.
А что касается UIKit, то переход на SwiftUI с целью трудоустройства может быть преждевременным. В SwiftUI полно багов. Разработка пока похожа на танцы с бубнами — больше чем обычно. Описание ошибок в SwiftUI — штука такая. Почти рандомная. Проблема может быть в одной строчке кода, а компилятор ругается на совсем другие, с совсем другим описанием ошибки.
И по поводу багов — это действительно проблема для production. Например, NavigationLink (способ навигации между экранами, замена сегвеям) — сломан в текущем релизе XCode(11.3.1). Он работает только 1 раз. Т.е. вы сходили по ссылке, вернулись назад, кликаете на ту же ссылку — и ничего не происходит. До тех пор пока вы не сходите по другой ссылке — тогда первая заработает, но вторя останется недоступной.
Все зависит от того, насколько успешно все с моим пет-проектом. В данный момент, я сосредоточил на нем 100% своего времени. Надеюсь, с его помощью получится закрепиться на ниве мобильной разработки.
Впрочем, совсем забрасывать 1с я не хочу даже в случае его успеха. Я вижу непаханое поле на пересечении мобильной разработки и автоматизации бизнеса (ритейла в частности, т.к. основные мои компетенции наработаны именно вокруг ритейла).
не совсем.
id нужен для внутренней работы ForeEach, что бы он мог для каждого элемента построить свою View с помощью переданного контента. Эту View нужно связать с элементом с помощью какого-то ключа. Параметр id, это именно указание, какой реквизит использовать для этой связи в качестве уникального ключа элемента коллекции. Для этого используется вариант инициализатора с указанием ключевого атрибута.
Когда указывается id: \.self, это значит, что в качестве ключа будет использован непосредственно сам элемент, а точнее, его хэш. Именно поэтому, указанный реквизит, или сам объект в случае \.self должен удовлетворять протоколу Hashiable
А в замыкание просто передается элемент коллекции Data, для которого нужно нарисовать отдельную View {Item in ...}
Так что это в первую очередь люди не готовы, как мне кажется.
Решил что немного систематизированной информации будет полезно для коллег, и написал эту статью.
И по поводу багов — это действительно проблема для production. Например, NavigationLink (способ навигации между экранами, замена сегвеям) — сломан в текущем релизе XCode(11.3.1). Он работает только 1 раз. Т.е. вы сходили по ссылке, вернулись назад, кликаете на ту же ссылку — и ничего не происходит. До тех пор пока вы не сходите по другой ссылке — тогда первая заработает, но вторя останется недоступной.
Впрочем, совсем забрасывать 1с я не хочу даже в случае его успеха. Я вижу непаханое поле на пересечении мобильной разработки и автоматизации бизнеса (ритейла в частности, т.к. основные мои компетенции наработаны именно вокруг ритейла).
id нужен для внутренней работы ForeEach, что бы он мог для каждого элемента построить свою View с помощью переданного контента. Эту View нужно связать с элементом с помощью какого-то ключа. Параметр id, это именно указание, какой реквизит использовать для этой связи в качестве уникального ключа элемента коллекции. Для этого используется вариант инициализатора с указанием ключевого атрибута.
Когда указывается id: \.self, это значит, что в качестве ключа будет использован непосредственно сам элемент, а точнее, его хэш. Именно поэтому, указанный реквизит, или сам объект в случае \.self должен удовлетворять протоколу Hashiable
А в замыкание просто передается элемент коллекции Data, для которого нужно нарисовать отдельную View {Item in ...}
Подробнее о KeyPath можно почитать, например, тут