Извините, в качестве ссылки на Monte Carlo дала ссылку на medium.com, который в России не открывается. Исправлено. Больше не нашла ссылок, которые не открываются. Если не составит труда, подскажите, какие не открываются в России - заменю.
А "затасканная" задача была взята намеренно, чтобы не париться с контекстом. Уж не знаю, что где взял ChatGPT, но задачу понимает абсолютно точно. Я пробовала еще физические задачи : типа скользит шарик по сфере и в какой-то точке отрывается и начинает падать свободно - прекрасно рисует траекторию.
Абсолютно не лень. Азарт. Попробуйте, взять что-нибудь знакомое и проделать то же самое с известной вам задачей. Вам понравится. Под конец уже совсем наглеешь, а ChatGpt все равно выдает очень приличный код.
Кстати, что странно, я не заметила, чтобы chatGPT обворовывает GitHub. Уж поверьте, я все просмотрела. Код оригинальный, особенно в части concurrency. Что приятно удивило.
Упомянутая вами статья касается очень небольшого вопроса, связанного с различной трактовкой Optional в Core Data и в Swift. Это противоречие очень просто убирается путем добавления небольшого кода в расширении extension классов, соответствующих объектам Core Data. Моя статья посвящена возможностям, предоставленным Apple для Core Data в новом фреймворке SwiftUI и так и называется "Core Data в современном интерьере SwiftUI". Упомянутый вами вопрос составляет менее 1% от содержания моей статьи. Мне искренне жаль, что вы не поняли тех беспрецедентных возможностей, которые имеются в настоящее время у Core Data при работе в SwiftUI.
Да, это фантастический протокол Transferable. Тоже работаю над статьей о Transferable. для своего блога. Но чтобы это оценить, надо понимать, что было до появления этого протокола, то есть до iOS 16+.
За операции Drag & Drop (перетаскивание и "сброс") отвечал класс class NSItemProvider. Именно этот класс делает очень сложные вещи, связанные с передачей данных между процессами. Он также решает проблемы с безопасностью и определенно там есть многопоточность, потому что мы не хотим блокировать UI двух приложений в случае передачи между ними больших по объему изображений.
К сожалению, класс NSItemProvider — это до-Swift класс, и мы должны использовать “as” как “мостик” между такими Swift ТИПами как String, и такими ТИПами старого NS Мира, как NSString, это Objective-C вещи, и “as” является “мостом” в этот старый мир. До появления протокола Transferable технология Drag & Drop (перетаскивание и сброс) была одним из таких мест соприкосновения "старого" и нового Миров.
Почти параллельно с вашей статьей появились две статьи об опыте использования протокол Transferable :
Единственное, до чего не "дотягивает" протокол Transferable и соответствующий ему View модификатор dropDestination(for:action:isTargeted:), это возможность указания нескольких UTType.
Класс Operation имеет метод cancel(), однако использование этого метода только устанавливает свойство isCancelled в true, а что семантически означает «удаление» операции можно определить только при создании subclass Operation. Например, в случае загрузки данных из сети можно определить cancel() как отключение операции от сетевого взаимодействия.
Посмотрите мою другую статью "Concurrency в Swift 3 и 4. Operation и OperationQueue" в Habr, специально посвященную Operation.
Пожалуй, действительно не стоит обсуждать эффективное хранение структур structтем более в Standard Library.
В документации по Swift вовсе не сказано напрямую, что оптимизация хранения структур struct типа массивов Array, словарей Dictionary и строк String предполагает использование "кучи" (heap), там лишь сказано, что используется оптимизация для уменьшения затрат на копирование. Вместо того, чтобы делать копию немедленно, эти коллекции совместно используют память, в которой хранятся элементы, между исходным экземпляром и любыми копиями. Если одна из копий коллекции изменяется, элементы копируются непосредственно перед изменением.
Так что Apple оставляет за собой право, как она будет оптимизировать хранение структур struct, может и изменить это в любой момент времени.
Для нас важно лишь то, что в нашем коде ВСЕГДА у структуры struct будет такое поведение при изменении, как если бы копия была создана немедленно.
По большому счету структуры structявляются "неизменяемыми" (immutable) структурами данных в отличие от классов class.
Именно на основе того, что при любом изменении структуры structмы всегда имеем её новый экземпляр,и строится функциональное программирование.
Это особенно видно в новом фреймворке SwiftUI, в котором архитектура строится на основе MVVM, где View - всегда структуры struct, а ViewModels - классы class. Программирование в SwiftUI - это функциональное программирование.
Вы сами задаете интервал обновления.
А в fetch() уже работает @Published, а точнее CurrentValueSubject<Set, Never>([]), но это близко к @Published, и это воздействует на View SwiftUI.
У меня нет опыта работы с RxSwift, но многие отмечают, что хотя Combine пока по функциональности уступает RxSwift, он существенно превосходит RxSwift по быстродействию. Да это и понятно, ведь RxSwift написан поверх Swift, а Combine — ниже Foundation.
Лично меня поразило быстродействие связки Combine+ SwiftUI в задаче выборки данных о фильмах и их кинопостерах, что относится к ресурсо- затратным задачам. В том примере, который приведен в этой статье, при переходе от одной коллекции фильмов ( от тех, которые сейчас на экране, к популярным), выборка данных происходит столь быстро, что даже нет необходимости в экране «Loading...». «Сто лет» занимаюсь этими задачами и Combine+ SwiftUI преподнесли мне приятный сюрприз.
Да, я знаю, что одним из критериев конкурса было быстродействие.
Я конечно, не замеряла, но быстродействие очень хорошее.
Те, кто специально этим занимался отмечают существенное быстродействие по сравнению с UIKit.
Что касается навигации, то есть одно очень хорошее решение «Recreation of calculator-checklist project in SwiftUI», где очень просто воссоздается CustomSegue:
Извините, в качестве ссылки на Monte Carlo дала ссылку на medium.com, который в России не открывается. Исправлено. Больше не нашла ссылок, которые не открываются. Если не составит труда, подскажите, какие не открываются в России - заменю.
А "затасканная" задача была взята намеренно, чтобы не париться с контекстом. Уж не знаю, что где взял ChatGPT, но задачу понимает абсолютно точно. Я пробовала еще физические задачи : типа скользит шарик по сфере и в какой-то точке отрывается и начинает падать свободно - прекрасно рисует траекторию.
Абсолютно не лень. Азарт. Попробуйте, взять что-нибудь знакомое и проделать то же самое с известной вам задачей. Вам понравится. Под конец уже совсем наглеешь, а ChatGpt все равно выдает очень приличный код.
Кстати, что странно, я не заметила, чтобы chatGPT обворовывает GitHub. Уж поверьте, я все просмотрела. Код оригинальный, особенно в части concurrency. Что приятно удивило.
Упомянутая вами статья касается очень небольшого вопроса, связанного с различной трактовкой Optional в Core Data и в Swift. Это противоречие очень просто убирается путем добавления небольшого кода в расширении extension классов, соответствующих объектам Core Data. Моя статья посвящена возможностям, предоставленным Apple для Core Data в новом фреймворке SwiftUI и так и называется "Core Data в современном интерьере SwiftUI". Упомянутый вами вопрос составляет менее 1% от содержания моей статьи. Мне искренне жаль, что вы не поняли тех беспрецедентных возможностей, которые имеются в настоящее время у Core Data при работе в SwiftUI.
Это обычная практика. Посмотрите, например, эту статью SwiftUI views versus modifiers.
По-моему как раз наоборот: сразу видны все Swift ключевые слова и легче соориентироваться.
Исправлено. Repository был private
Да, это фантастический протокол Transferable. Тоже работаю над статьей о Transferable. для своего блога. Но чтобы это оценить, надо понимать, что было до появления этого протокола, то есть до iOS 16+.
За операции Drag & Drop (перетаскивание и "сброс") отвечал класс class NSItemProvider. Именно этот класс делает очень сложные вещи, связанные с передачей данных между процессами. Он также решает проблемы с безопасностью и определенно там есть многопоточность, потому что мы не хотим блокировать UI двух приложений в случае передачи между ними больших по объему изображений.
К сожалению, класс NSItemProvider — это до-Swift класс, и мы должны использовать “as” как “мостик” между такими Swift ТИПами как String, и такими ТИПами старого NS Мира, как NSString, это Objective-C вещи, и “as” является “мостом” в этот старый мир. До появления протокола Transferable технология Drag & Drop (перетаскивание и сброс) была одним из таких мест соприкосновения "старого" и нового Миров.
Почти параллельно с вашей статьей появились две статьи об опыте использования протокол Transferable :
First Experience With Transferable Implementing Drag And Drop In SwiftUI
Transferable Protocol in SwiftUI – Transferring Alternative Content With ProxyRepresentation
Единственное, до чего не "дотягивает" протокол Transferable и соответствующий ему View модификатор dropDestination(for:action:isTargeted:), это возможность указания нескольких UTType.
Раньше, до iOS 16+:
Теперь, начиная с iOS 16+:
Но выход есть:
Класс
Operationимеет методcancel(), однако использование этого метода только устанавливает свойствоisCancelledвtrue, а что семантически означает «удаление» операции можно определить только при созданииsubclass Operation. Например, в случае загрузки данных из сети можно определитьcancel()как отключение операции от сетевого взаимодействия.Посмотрите мою другую статью "Concurrency в Swift 3 и 4. Operation и OperationQueue" в Habr, специально посвященную
Operation.https://habr.com/ru/post/335756/
По-моему там есть пример.
По сути, assign(to:) - это прямая передача публикуемого значения другому "издателю" Publisher $currentWeather и никакой reference cycle не возникает.
Верно. Вы можете использовать вместо этого
Или использовать новый в iOS 14 метод https://developer.apple.com/documentation/combine/fail/assign(to:)
код стал еще проще.
Пожалуй, действительно не стоит обсуждать эффективное хранение структур
structтем более в Standard Library.В документации по Swift вовсе не сказано напрямую, что оптимизация хранения структур
struct типамассивовArray, словарейDictionaryи строкStringпредполагает использование "кучи" (heap), там лишь сказано, что используется оптимизация для уменьшения затрат на копирование. Вместо того, чтобы делать копию немедленно, эти коллекции совместно используют память, в которой хранятся элементы, между исходным экземпляром и любыми копиями. Если одна из копий коллекции изменяется, элементы копируются непосредственно перед изменением.Так что Apple оставляет за собой право, как она будет оптимизировать хранение структур
struct, может и изменить это в любой момент времени.Для нас важно лишь то, что в нашем коде ВСЕГДА у структуры
structбудет такое поведение при изменении, как если бы копия была создана немедленно.По большому счету структуры
structявляются "неизменяемыми" (immutable) структурами данных в отличие от классовclass.Именно на основе того, что при любом изменении структуры
structмы всегда имеем её новый экземпляр,и строится функциональное программирование.Это особенно видно в новом фреймворке SwiftUI, в котором архитектура строится на основе
MVVM, гдеView- всегда структурыstruct, аViewModels- классыclass. Программирование в SwiftUI - это функциональное программирование.Вы сами задаете интервал обновления.
А в fetch() уже работает @Published, а точнее CurrentValueSubject<Set, Never>([]), но это близко к @Published, и это воздействует на View SwiftUI.
Лично меня поразило быстродействие связки Combine+ SwiftUI в задаче выборки данных о фильмах и их кинопостерах, что относится к ресурсо- затратным задачам. В том примере, который приведен в этой статье, при переходе от одной коллекции фильмов ( от тех, которые сейчас на экране, к популярным), выборка данных происходит столь быстро, что даже нет необходимости в экране «Loading...». «Сто лет» занимаюсь этими задачами и Combine+ SwiftUI преподнесли мне приятный сюрприз.
Problem Solving with Combine Swift
Я конечно, не замеряла, но быстродействие очень хорошее.
Те, кто специально этим занимался отмечают существенное быстродействие по сравнению с UIKit.
Что касается навигации, то есть одно очень хорошее решение «Recreation of calculator-checklist project in SwiftUI», где очень просто воссоздается CustomSegue: