#swiftui Также в подборке есть очень полезная статья от Вадима Булавина про особенности тестирования View на SwiftUI.
#swiftui Итак, продолжаем цикл статей про SwiftUI. 3я часть про архитектуру приложения и наведение порядка с помощью CleanCode.
https://habr.com/ru/post/500470/
https://habr.com/ru/post/500470/
Хабр
Адаптируем существующее бизнес-решение под SwiftUI. Часть 3. Работаем с архитектурой
Доброго всем времени суток! С вами я, Анна Жаркова, ведущий мобильный разработчик компании «Usetech» Продолжаем разбирать тонкости SwiftUI. С предыдущими частями можно ознакомиться по...
#swiftui Что может SwiftUI из того, чего не может Autolayout? Это вью-обертка. Конечно, это композиция, но Autolayout не поддерживает наследование xib с расширением хоть каким-нибудь образом. Печаль…
#swiftui #туториал Stanfod University начали к наполнению своего ютуб-канала лекциями по SwiftUI
https://www.youtube.com/playlist?list=PLpGHT1n4-mAtTj9oywMWoBx0dCGd51_yG
https://cs193p.sites.stanford.edu
https://www.youtube.com/playlist?list=PLpGHT1n4-mAtTj9oywMWoBx0dCGd51_yG
https://cs193p.sites.stanford.edu
YouTube
CS193p iPhone Application Development Spring 2020
Lecture videos from the Stanford University course CS193p, Developing Applications for iOS using SwiftUI. These lectures were delivered on-line (due to the n...
#swiftui Итак, имеющиеся презентации просмотрены и проанализированы:
https://habr.com/ru/post/508002/
Что мне есть вам сказать. Apple внимательно весь этот год читали все, что писали энтузиасты по всему миру про SwiftUI: статьи, комментарии, обзоры, выступления на митапах и конференциях. И Apple не скрывают, что вдохновились их опытом. Что-то натолкнуло их на мысли, что-то они заимствовали полностью. Также есть влияния от Google. Ну в принципе это тренд - заимствовать у конкурентов и этого не скрывать.
В общем:
1. Теперь SwiftUI - технология для создания приложений под разные платформы, от часов до MacOS. В Xcode 12 есть шаблон для создания такого мультиплатформенного приложения. А структура приложения напоминает KMP.
2. Можно отказаться от AppDelegate/SceneDelegate и с помощью @main и протокола App сделать свою точку входа в приложение. UIHostingController и UISceneDelegate инкапсулированы внутри.
3. Apple отказывается от MVVM в пользу MVI/Redux.
4. Почти все контролы портированы на SwiftUI. Появляются LazyVGrid/LazyHGrid для GridItem - аналог UiCollectionView. Дополнительно заявлено об оптимизации структуры контрола.
5. Портированы фреймворки для SwiftUI
6. Есть средства для настройки адаптивности.
https://habr.com/ru/post/508002/
Что мне есть вам сказать. Apple внимательно весь этот год читали все, что писали энтузиасты по всему миру про SwiftUI: статьи, комментарии, обзоры, выступления на митапах и конференциях. И Apple не скрывают, что вдохновились их опытом. Что-то натолкнуло их на мысли, что-то они заимствовали полностью. Также есть влияния от Google. Ну в принципе это тренд - заимствовать у конкурентов и этого не скрывать.
В общем:
1. Теперь SwiftUI - технология для создания приложений под разные платформы, от часов до MacOS. В Xcode 12 есть шаблон для создания такого мультиплатформенного приложения. А структура приложения напоминает KMP.
2. Можно отказаться от AppDelegate/SceneDelegate и с помощью @main и протокола App сделать свою точку входа в приложение. UIHostingController и UISceneDelegate инкапсулированы внутри.
3. Apple отказывается от MVVM в пользу MVI/Redux.
4. Почти все контролы портированы на SwiftUI. Появляются LazyVGrid/LazyHGrid для GridItem - аналог UiCollectionView. Дополнительно заявлено об оптимизации структуры контрола.
5. Портированы фреймворки для SwiftUI
6. Есть средства для настройки адаптивности.
Хабр
SwiftUI 2020. Что изменилось?
Приветствую вас, жители Хабра и все интересующиеся разработкой под IOS. На связи Анна Жаркова, Senior iOS/Android разработчик компании Usetech Сегодня мы поговор...
#wwdc #swiftui Apple представили обновление ViewState, в соответствии с новым пониманием архитектуры для SwiftUI приложения:
1. Да, теперь это не MVVM, а MVI. Речь идет о поддержке непрерывного обновления View в зависимости от изменяемых данных, запрос которых рекомендуется делать в зависимости от цикла View
2. Появился новый @PropertyWrapper - @StateObject. Это статичная модель @ObservableObject, т.е неизменяемая. Почему и где нужно. @ObservableObject - пересоздается при пересоздании View. Да, Apple признали, что это тяжелая операция. Модель - это класс, он оказывается в heap, а это потенциальные leak of memory.
@StateObject - статичная вещь. Либо вы ее создаете при инициализации View, либо передаете из родительского View. Например, через @EnvironmentObject
3. Новые методы для триггера изменений в ObservedObject. Теперь это не только onReceive, но и onChange, onOpenURL, onContinueUserActivity. Похоже на Deep Linking
4. Новое понимание хранилища. Появляется @AppStorage - глобальное хранилище на основе UserDefaults, доступное из любой точки приложения. И @SceneStorage - аналогичное хранилище со скоупом внутри сцены и доступное только внутри View. С одной стороны, это позволяет организовать байндинг с сохраненными параметрам быстро и просто без посредников. Также предлагается использовать такой подход для хранения стейтов - очень похоже на Bundle. С другой, само прямое обращение к хранилищу из View является нарушением архитектурной парадигмы.
5. Насчет навигации не изменилось ничего. Либо оно еще в работе, либо Apple ждет от нас решений, где мы, оперируя новыми Storage, StateObject и новыми методами lifecycle, создадим что-то удобоваримое, чтобы им было что представить в следующем году и сказать нам всем одно единственное: "Спасибо".
Да, если вы не в курсе, они открыто говорят, что "вдохновились решениями неравнодушных разработчиков" для SwiftUI. Это "What's new in SwiftUI"
На следующей неделе будет статья про то, как эти изменения можно использовать в бою
1. Да, теперь это не MVVM, а MVI. Речь идет о поддержке непрерывного обновления View в зависимости от изменяемых данных, запрос которых рекомендуется делать в зависимости от цикла View
2. Появился новый @PropertyWrapper - @StateObject. Это статичная модель @ObservableObject, т.е неизменяемая. Почему и где нужно. @ObservableObject - пересоздается при пересоздании View. Да, Apple признали, что это тяжелая операция. Модель - это класс, он оказывается в heap, а это потенциальные leak of memory.
@StateObject - статичная вещь. Либо вы ее создаете при инициализации View, либо передаете из родительского View. Например, через @EnvironmentObject
3. Новые методы для триггера изменений в ObservedObject. Теперь это не только onReceive, но и onChange, onOpenURL, onContinueUserActivity. Похоже на Deep Linking
4. Новое понимание хранилища. Появляется @AppStorage - глобальное хранилище на основе UserDefaults, доступное из любой точки приложения. И @SceneStorage - аналогичное хранилище со скоупом внутри сцены и доступное только внутри View. С одной стороны, это позволяет организовать байндинг с сохраненными параметрам быстро и просто без посредников. Также предлагается использовать такой подход для хранения стейтов - очень похоже на Bundle. С другой, само прямое обращение к хранилищу из View является нарушением архитектурной парадигмы.
5. Насчет навигации не изменилось ничего. Либо оно еще в работе, либо Apple ждет от нас решений, где мы, оперируя новыми Storage, StateObject и новыми методами lifecycle, создадим что-то удобоваримое, чтобы им было что представить в следующем году и сказать нам всем одно единственное: "Спасибо".
Да, если вы не в курсе, они открыто говорят, что "вдохновились решениями неравнодушных разработчиков" для SwiftUI. Это "What's new in SwiftUI"
На следующей неделе будет статья про то, как эти изменения можно использовать в бою
#swiftui Итак, спустя месяц после WWDC 2020 все больше народу тянется переосмыслять нововведения в SwiftUI. И особое внимание уделяется MVI-архитектуре, которую Apple предлагают вместо (или вместе с) MVVM:
https://habr.com/ru/post/512542/
Идея у статьи неплохая, но все-таки не хватает структурированности в коде. Если уж ты берешься за рассказ про свое архитектурное решение, ну сделай ты код читабельным. Сбивает же
Из интересных моментов статьи я бы вынесла:
1. Расширение AnyView для абстракции
2. Использование статической функции build для отсроченной инициализации View
https://habr.com/ru/post/512542/
Идея у статьи неплохая, но все-таки не хватает структурированности в коде. Если уж ты берешься за рассказ про свое архитектурное решение, ну сделай ты код читабельным. Сбивает же
Из интересных моментов статьи я бы вынесла:
1. Расширение AnyView для абстракции
2. Использование статической функции build для отсроченной инициализации View
Хабр
MVI и SwiftUI – одно состояние
Представим, нам нужно внести небольшую правку в работу экрана. Экран меняется каждую секунду, поскольку в нем одновременно происходит множество процессов. Как...