IS
а свой uiview можно всегда переписать на swiftui
Size: a a a
2020 April 22
V
особенно это касается экранов, которые зарыты глубоко внутри проложения (требуется авторизация, например, или, там, какой-то путь длинный внутри приложения)
а что мешает сделать библиотеку компонентов? В одном проекте у нас был проект с минимальными кастомными эелементами: кнопочки, лейбочки и т.п, в другом проекте более крупные элементы вроде карточек. Можно и контроллеры так же запилить. Кстати, хорошая идея 😏
TM
Если есть работодатель который платит за разработку с 0 на swiftUI это вообще круто конечно)
есть такие, брат
TM
а что мешает сделать библиотеку компонентов? В одном проекте у нас был проект с минимальными кастомными эелементами: кнопочки, лейбочки и т.п, в другом проекте более крупные элементы вроде карточек. Можно и контроллеры так же запилить. Кстати, хорошая идея 😏
да можно и готовыми воспользоваться)
IS
некоторые элементы uikit не присутствуют как нативные в swiftui, например, тот же UISearchBar
D
есть такие, брат
Ну тогда совсем класно, если тебе не нужно поддерживать еще все что до 13й бинго 10 из 10
M
это полезно прежде всего для, например, внешних библиотек, которые все еще на uikit. очень полезно
ну это да)
IS
но все решается небольшой оберткой в виде UIViewRepresentable
IS
Ну тогда совсем класно, если тебе не нужно поддерживать еще все что до 13й бинго 10 из 10
да, то что ios 13 и выше - большой минус, спору нет. многие еще поддерживают 10ку
TM
Ну тогда совсем класно, если тебе не нужно поддерживать еще все что до 13й бинго 10 из 10
Ну да, всегда все упирается в спрос по сути, мне 2 вакансии падали такие(надеюсь тебе пруфы не нужны), но swiftUI + Combine людям интересен
TM
да, то что ios 13 и выше - большой минус, спору нет. многие еще поддерживают 10ку
это правда и 9ку тоже я уверен, просто вопрос чисто в жертвах
D
Ну да, всегда все упирается в спрос по сути, мне 2 вакансии падали такие(надеюсь тебе пруфы не нужны), но swiftUI + Combine людям интересен
Моя мысль не в том что он не интересен, а в том что он сырой для прода. И бенефитов от использования rx сейчас много больше, через пару лет все изменится. Но UIKit как и rx еще смело будут жить лет 5-7
TM
Моя мысль не в том что он не интересен, а в том что он сырой для прода. И бенефитов от использования rx сейчас много больше, через пару лет все изменится. Но UIKit как и rx еще смело будут жить лет 5-7
полностью согласен. Я с точки зрения разраба, если мне развяжут руки будут платить деньги и скажут используй новое и осваивай, то мне вообще за радость будет
V
Моя мысль не в том что он не интересен, а в том что он сырой для прода. И бенефитов от использования rx сейчас много больше, через пару лет все изменится. Но UIKit как и rx еще смело будут жить лет 5-7
Абсолютно поддерживаю. А то и дольше. В некоторых моментах, если конечно не доработают - без UIKit никак.
IS
Моя мысль не в том что он не интересен, а в том что он сырой для прода. И бенефитов от использования rx сейчас много больше, через пару лет все изменится. Но UIKit как и rx еще смело будут жить лет 5-7
у меня был проект на rx, мне не понравилось. но это все - вусовщина. с swiftui+combine ты получаешь тоже самое, только нативное (в виде property wrappers), которое не внешнее, а внутреннее), и это не надстройка, а часть синтаксиса
TM
Абсолютно поддерживаю. А то и дольше. В некоторых моментах, если конечно не доработают - без UIKit никак.
UIKit точно в помойку не выбросят.
IS
UIKit точно в помойку не выбросят.
кажется я слышал что-то такое же про objective-c )) сейчас вакансии с objective-c в основном сопровождаются фразой "переписываем на swift" )))
IS
тоже будет и с uikit, поверь
IS
apple объединяет все платформы и уже не первый год
IS
чтобы один код - и пять платформ