Вопрос 2: при описанном подходе мы отказываемся от стандартных анимаций переходов между экранами (и от модальных презентаций), а значит должны реализовать кастомные, верно?
Если да, то не слишком много будет работы с повторением стандартных анимаций и исправлением багов, особенно учитывая годы костылей на UIKit у любителей понаделать кастомные tab/nav-бары?
Я работал с UIKit 3 года, но повидал много таких костылей (сам не грешил).
Бонус: предлагаю заменить @ObservedObject на @StateObject внутри struct ContentView, потому что не рекомендовано использовать @ObservedObject для хранения состояния вьюшки в SwiftUI, для этого предназначен @StateObject, цитата:
SwiftUI might create or recreate a view at any time, so it’s important that initializing a view with a given set of inputs always results in the same view. As a result, it’s unsafe to create an observed object inside a view. Instead, SwiftUI provides the StateObject attribute for this purpose
Удивительный ответ. Я всегда думал, что женщинам навязали каблуки "модой" или комплексами неполноценности (не в обиду сказано), но изменять пропорции отношения длины ног к телу - это же надо додуматься) Занятно, занятно
Я сам отучился 5 лет для галочки, потом 5 лет отработал менеджером для радости родителей и наконец начал думать своей головой и так сложилось, что изучил мобильную разработку и уже 2 года с удовольствием верстаю экранчики на айфон.
В универе учился на банкира кстати, банковское дело ведь такое полезное в жизни и позволяет так классно разобраться в финансах (нет).
В финансах классно разобраться я смог только заработав и потратив первые пару миллионов.
Привет!
Интересная статья.
Вопрос 1: почему завернул containered в массив?
self.stack += [containered]Вопрос 2: при описанном подходе мы отказываемся от стандартных анимаций переходов между экранами (и от модальных презентаций), а значит должны реализовать кастомные, верно?
Если да, то не слишком много будет работы с повторением стандартных анимаций и исправлением багов, особенно учитывая годы костылей на UIKit у любителей понаделать кастомные tab/nav-бары?
Я работал с UIKit 3 года, но повидал много таких костылей (сам не грешил).
Бонус: предлагаю заменить @ObservedObject на @StateObject внутри struct ContentView, потому что не рекомендовано использовать @ObservedObject для хранения состояния вьюшки в SwiftUI, для этого предназначен @StateObject, цитата:
SwiftUI might create or recreate a view at any time, so it’s important that initializing a view with a given set of inputs always results in the same view. As a result, it’s unsafe to create an observed object inside a view. Instead, SwiftUI provides the StateObject attribute for this purpose
Удивительный ответ. Я всегда думал, что женщинам навязали каблуки "модой" или комплексами неполноценности (не в обиду сказано), но изменять пропорции отношения длины ног к телу - это же надо додуматься) Занятно, занятно
Упомянуто не значит "можно использовать в продакшене" сегодня
Сам учил Swift по курсам одной из школ и в гугле.
В итоге первый оффер был на 70к (при старой зп в 140к в неинтересной мне сфере), а через год офферы уже были х2 от прежней зарплаты и выше.
Вопрос только в настойчивости и уверенности в себе.
Желаю Лене успехов!
Это необычный способ обучения, кому-нибудь может зайти)
Пару лет назад я написал пару экранов с неймингом на русском просто ради эксперимента)
Мне тоже интересно услышать ответ на этот вопрос.
Я сам отучился 5 лет для галочки, потом 5 лет отработал менеджером для радости родителей и наконец начал думать своей головой и так сложилось, что изучил мобильную разработку и уже 2 года с удовольствием верстаю экранчики на айфон.
В универе учился на банкира кстати, банковское дело ведь такое полезное в жизни и позволяет так классно разобраться в финансах (нет).
В финансах классно разобраться я смог только заработав и потратив первые пару миллионов.
Если вокруг все плохо, команду/компанию нужно менять.
Ну а если ты являешься этим самым менеджером, который не сумел собрать классную команду, то меняться надо самому.