因为SwiftUI View 采用的是结构体,当创建想要更改属性的结构体方法时,我们需要添加mutating关键字,例如:
在上文中,我列举了一些在 SwiftUI 中使用 Core Data 所遇到的困惑及期许。在今后的文章中我们将尝试用新的思路来创建一个 SwiftUI + Core Data 的 app,看看能否避免并改善之前的一些问题。本文将首先探讨如何定义数据。
SwiftUI中的界面是严格数据驱动的:运行时界面的修改,只能通过修改数据来间接完成,而不是直接对界面进行修改操作。
在 WWDC 2023 中,苹果介绍了 Swift 标准库中的新成员:Observation 框架。它的出现有望缓解开发者长期面临的 SwiftUI 视图无效更新问题。本文将采取问答的方式,全面而详尽地探讨 Observation 框架,内容涉及其产生原因、使用方法、工作原理以及注意事项等。
SwiftUI的环境使我们可以使用来自外部的值,这对于读取Core Data上下文或视图的展示模式等很有用。但是我们也可以将自定义对象发送到环境中,并在以后将它们读出来,这使我们可以在复杂的应用程序中更轻松地共享数据。
我在去年底使用了SwiftUI写了第一个 iOS app 健康笔记,这是我第一次接触响应式编程概念。在有了些基本的认识和尝试后,深深的被这种编程的思路所打动。不过,我在使用中也发现了一些奇怪的问题。我发现在视图(View)数量达到一定程度,随着数据量的增加,整个app的响应有些开始迟钝,变得有粘滞感、不跟手。app响应出现了问题一方面肯定和我的代码效率、数据结构设计欠佳有关;不过随着继续分析,发现其中也有很大部分原因来自于SwiftUI中所使用的响应式的实现方式。不恰当的使用,可能导致响应速度会随着数据量及View量的增加而大幅下降。通过一段时间的研究和分析,我打算用两篇文章来阐述这方面的问题,并尝试提供一个现阶段的使用思路。
SwiftUI与苹果之前的UI框架的区别不仅仅在于如何定义视图和其他UI组件,还在于如何在整个使用它的应用程序中管理视图层级的状态。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理,并添加了一点个人见解。本文为下篇。
在这篇文章中,我们将探讨几个在 SwiftUI 开发中经常使用且至关重要的属性包装器。本文旨在提供对这些属性包装器的主要功能和使用注意事项的概述,而非详尽的使用指南。
本文将对 @Published 与符合 ObservableObject 协议的类实例之间的沟通机制做以介绍,并通过三个示例:@MyPublished( @Published 的仿制版本 )、@PublishedObject(包装值为引用类型的 @Published 版本)、@CloudStorage(类似 @AppStorage ,但适用于 NSUbiquitousKeyValueStore ),来展示如何为其他的自定义属性包装类型添加可访问包裹其的类实例的属性或方法的能力。
苹果于 WWDC 2023 上推出新框架 SwiftData,提供声明性的、以 Swift 为先的 API,可在 iOS 应用中进行数据持久化工作。SwiftData 可轻松将一个 Swift 类转换为一个持久化模型,非常适合同 SwiftUI 一并使用。
编译 | 核子可乐、Tina SwiftUI 很好,但是苹果对它投资不足。 在 2019 年的 WWDC 大会上,苹果推出了一个全新的 SwiftUI 框架,这是一个现代化的 UI 界面编码结构,它是基于 Swift从头开始构建的。新框架使用声明性范例,让开发者用更少的代码编写相同的 UI。 SwiftUI 的愿景是降低开发 iOS 门槛,吸引更多开发者、丰富 iOS 的业态。并且 SwiftUI 可以“实现一次编码,可适应五端 Apple 产品平台”, 包括watchOS、tvOS、macOS 等,
长久以来,开发者对 SwiftUI 的导航系统颇有微词。受 NavigationView 的能力限制,开发者需要动用各种技巧乃至黑科技才能实现一些本应具备基本功能(例如:返回根视图、向堆栈添加任意视图、返回任意层级视图 、Deep Link 跳转等 )。SwiftUI 4.0( iOS 16+ 、macOS 13+ )对导航系统作出了重大改变,提供了以视图堆栈为管理对象的新 API ,让开发者可以轻松实现编程式导航。本文将对新的导航系统作以介绍。
我是在去年阅读王巍写的《SwiftUI 与 Combine 编程》才第一次接触到单一数据源这一概念的。
NSUbiquitousKeyValueStore 是苹果官方提供的用于在设备间共享键值数据的解决方案。本文将对其用法做以简单介绍,着重探讨如何便捷地在 SwiftUI 中使用 NSUbiquitousKeyValueStore。
VIPER架构模式是MVC或MVVM的另一种选择。虽然SwiftUI和Combine框架创建了一个强大的组合,可以快速构建复杂的ui和在应用程序中移动数据,但它们也面临着各自的挑战和对架构的看法。
在苹果生态的应用中,开发者或多或少都会使用到UserDefaults。我个人习惯将可被用户自定义的配置信息(精度、单位、色彩等)保存在UserDefaults中。随着配置信息的增加,在SwiftUI视图中使用的@AppStorage越来越多。
众所周知,SwiftUI 是一个响应式框架,这意味着,当数据源发生变化时,框架会自动更新视图。同样,当我们想调整视图显示时,应直接对状态进行修改。但是,SwiftUI 中的一些系统控件并没有完全遵循响应式的设计原则,由此在某些情况下会出现严重的错误,影响用户体验,并使开发者无所适从。
随着近年来有关 SwiftUI 的文章与书籍越来越多,开发者应该都已经清楚地掌握了 —— “视图是状态的函数” 这一 SwiftUI 的基本概念。每个视图都有与其对应的状态,当状态变化时,SwiftUI 都将重新计算与其对应视图的 body 值。
本文中我们将探讨在 SwiftUI 视图中批量获取 Core Data 数据的方式,并尝试创建一个可以使用 mock 数据的 FetchRequest。由于本文会涉及大量 前文[1] 中介绍的技巧和方法,因此最好一并阅读。
随着苹果对 iPadOS 的不断投入,越来越多的开发者都希望自己的应用能够在 iPad 中有更好的表现。尤其当用户开启了台前调度( Stage Manager )功能后,应用对不同视觉大小模式的兼容能力就越发显得重要。本文将就如何创建可自适应不同尺寸模式的程序化导航方案这一内容进行探讨。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理,并添加了一点个人见解。本文为上篇。
经过两年多的时间,SwiftUI发展到当前的3.0版本,无论SwiftUI的功能还是Swift语言本身在这段时间里都有了巨大的提升。是时候使用Async/Await来重构我的的状态容器代码了。
要编写出色的应用程序,您不仅需要提出一个好主意,还需要考虑未来。快速有效地适应、改进和扩展应用程序功能的灵活性至关重要。无论您是在团队中工作还是独自工作,从长远来看,您编写和组织代码的方式将对维护您的代码产生巨大影响。这就是 SOLID 原则的用武之地。
StateObject 是在 SwiftUI 2.0 中才添加的属性包装器,它的出现解决了在某些情况下使用 ObservedObject 视图会出现超预期的问题。本文将介绍两者间的异同,原理以及注意事项。
尽管 SwiftUI 的惰性容器以及 Core Data 都有各自的内存占用优化机制,但随着应用视图内容的复杂( 图文混排 ),越来越多的开发者遇到了内存占用巨大甚至由此导致 App 崩溃的情况。本文将通过对一个演示 App 进行逐步内存优化的方式( 由原先显示 100 条数据要占用 1.6 GB 内存,优化至显示数百条数据仅需 200 多 MB 内存 ),让读者对 SwiftUI 视图的存续期、惰性视图中子视图的生命周期、托管对象的惰值特性以及持久化存储协调器的行缓存等内容有更多的了解。
SwiftUI的TextField可能是开发者在应用程序中最常使用的文本录入组件了。作为UITextField(NSTextField)的SwiftUI封装,苹果为开发者提供了众多的构造方法和修饰符以提高其使用的便利性、定制性。但SwiftUI在封装中也屏蔽了不少的高级接口和功能,增加了开发者实现某些特定需要的复杂性。本文为【SwiftUI 进阶】系列文章中的一篇,在本文中,我将介绍如何在TextField中实现如下功能:
上一篇我们总结的主要是VStack里面的东西,由他延伸到 @ViewBuilder, 接着我们上一篇总结的我们这篇内容主要说的是下面的几点,在这些东西说完后我准备解析一下苹果在SiwftUI文档中说道的比较好玩的一个东西,具体的我们后面在看。这篇我们还是说我们关于SwiftUI的东西,再提一下Demo代码我已经提交上Git了,目前Demo进度为一级页面基本上结束,地图点击大头针的添加也刚处理完,代码有需要的小伙伴可以去Git看看,项目地址
@State是一个属性包装器(property wrapper),被设计用来针对值类型进行状态管理;用于在Struct中mutable值类型
判断一个可滚动控件( ScrollView、List )是否处于滚动状态在某些场景下具有重要的作用。比如在 SwipeCell[3] 中,需要在可滚动组件开始滚动时,自动关闭已经打开的侧滑菜单。遗憾的是,SwiftUI 并没有提供这方面的 API 。本文将介绍几种在 SwiftUI 中获取当前滚动状态的方法,每种方法都有各自的优势和局限性。
保证应用不因 Core Data 的原因导致意外崩溃是对开发者的起码要求。本文将介绍可能在视图中产生严重错误的原因,如何避免,以及在保证视图对数据变化实时响应的前提下如何为使用者提供更好、更准确的信息。由于本文会涉及大量前文中介绍的技巧和方法,因此最好一并阅读。
在 UIKit(AppKit)的世界中,通过框架提供的大量钩子(例如 viewDidLoad、viewWillLayoutSubviews 等),开发者可以将自己的意志注入视图控制器生命周期的各个节点之中,宛如神明。在 SwiftUI 中,系统收回了上述的权利,开发者基本丧失了对视图生命周期的掌控。不少 SwiftUI 开发者都碰到过视图生命周期的行为超出预期的状况(例如视图多次构造、onAppear 无从控制等)。
我最近开始重新开发我的“健康笔记”应用程序。由于新版本将只支持 iOS 17 及以上版本的设备,这让我在选择技术路线上享有更大的自由。
最近看了斯坦福大学 2020 春季的 SwiftUI 课程,总结一下 SwiftUI 是如何支持 MVVM 设计模式的。
我重新修改了 CloudStorage 的代码,现在可以同 AppStorage 完全一样将 UserDefaults 和 NSUbiquitousKeyValueStore 汇总到一起,在 SwiftUI 中统一管理了。
在我之前的文章@State研究中我们探讨过@State,通过它,我们可以方便的将值类型数据作为View的Source of truth。在SwiftUI 1.0时代,如果想将引用类型作为source of truth,通常的方法是使用@EnvironmentObject或者 @ObservedObject。
从 iOS 14 开始,SwiftUI 为视图提供了 onChange 修饰器,通过使用 onChange,我们可以在视图中对特定的值进行观察,并在其更改时触发操作。本文将对 onChange 的特点、用法、注意事项以及替代方案做以介绍。
本文将通过一段可复现的“灵异代码”,对 State 注入优化机制、模态视图( Sheet、FullScreenCover )内容的生成时机以及不同上下文( 相互独立的视图树 )之间的数据协调等问题进行探讨。
Safe Area(安全区域)是指不与导航栏、标签栏、工具栏或其他视图控制器提供的视图重叠的内容空间。
随着 Swift 5.5 引入了 async/await 特性,苹果也为 SwiftUI 添加了 task 视图修饰器,以方便开发者在视图中使用基于 async/await 的异步代码。本文将对 task 视图修饰器的特点、用法、注意事项等内容做以介绍,并提供了将其移植到老版本 SwiftUI 的方法。
Swift 5.5中引入的 async/await 语法,允许用更可读的方式来编写异步代码。异步编程可以提高应用程序的性能,但必须取消不需要的任务,以确保不需要的后台任务不会干扰到应用程序。本文演示了如何明确地取消一个任务,并展示了子任务是如何自动取消的。
Swift 5.5 终于为开发者带来了async,await,actor这些便捷的异步语法,而其中一个小小的@MainActor语法,能带来让我们的开发更加便捷安全。
从SwiftUI诞生之日起,预览(Canvas Preview )一直是个让开发者又爱又恨的功能。当预览正常工作时,它可以极大地提高开发效率;而预览又随时可能因为各种莫名其妙的原因崩溃,不仅影响开发进程,同时又让开发者感到沮丧(很难排查出导致预览崩溃的故障)。
我对 iOS 开发、手机开发、SwiftUI 开发经验有限,若有理解错误的部分欢迎指正。
作为 SwiftUI 最引人注目的功能之一,预览功能吸引了不少开发者初次接触 SwiftUI。然而,随着项目规模的增长,越来越多的开发者发现预览功能并不如最初想象的那么易用。由于预览崩溃的次数和场景的增加,一些开发者已经视预览为 SwiftUI 的缺点之一,并对其产生了排斥感。
WWDC 2023 正在如火如荼地进行。苹果不仅带来了全新形态的硬件产品,还推出了几个相当震撼的新框架。本文将聊聊我对本届 WWDC 中 SwiftUI 5.0 和 SwiftData 的初步印象。
SwiftUI 中 ViewModel 的变化会引起 UI 的变化,如何能做到监听 ViewModel?常见的有如下几种方式。
领取专属 10元无门槛券
手把手带您无忧上云