Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理,并添加了一点个人见解。本文为下篇。
本文将介绍在 SwiftUI 视图中打开 URL 的若干种方式,其他的内容还包括如何自动识别文本中的内容并为其转换为可点击链接,以及如何自定义打开 URL 前后的行为等。
通常在一个循环中创建多个SwiftUI视图。例如,我们可能想要遍历一系列名称,并让每个名称成为文本视图,或者遍历一系列菜单项,并将每个名称显示为图像。
@State是一个属性包装器(property wrapper),被设计用来针对值类型进行状态管理;用于在Struct中mutable值类型
在这篇文章中,我们将探讨几个在 SwiftUI 开发中经常使用且至关重要的属性包装器。本文旨在提供对这些属性包装器的主要功能和使用注意事项的概述,而非详尽的使用指南。
随着近年来有关 SwiftUI 的文章与书籍越来越多,开发者应该都已经清楚地掌握了 —— “视图是状态的函数” 这一 SwiftUI 的基本概念。每个视图都有与其对应的状态,当状态变化时,SwiftUI 都将重新计算与其对应视图的 body 值。
Swift 5.4 带来了一些巨大的编译改进,包括表达式中具有错误的更好的代码完成和增量编译的大幅度提高。但是,它也增加了一些重要的新功能和改进,因此让我们在这里进行深入研究...
SwiftUI的TextField可能是开发者在应用程序中最常使用的文本录入组件了。作为UITextField(NSTextField)的SwiftUI封装,苹果为开发者提供了众多的构造方法和修饰符以提高其使用的便利性、定制性。但SwiftUI在封装中也屏蔽了不少的高级接口和功能,增加了开发者实现某些特定需要的复杂性。本文为【SwiftUI 进阶】系列文章中的一篇,在本文中,我将介绍如何在TextField中实现如下功能:
SwiftUI 提供了强大的布局能力,不过这些布局操作都是在视图之间进行的。当我们想在 Text 中进行图文混排时,需要采用与视图布局不同的思路与操作方式。本文将首先介绍一些与 Text 有关的知识,并通过一个实际案例,为大家梳理出在 SwiftUI 中用 Text 实现图文混排的思路。
在 UIKit(AppKit)的世界中,通过框架提供的大量钩子(例如 viewDidLoad、viewWillLayoutSubviews 等),开发者可以将自己的意志注入视图控制器生命周期的各个节点之中,宛如神明。在 SwiftUI 中,系统收回了上述的权利,开发者基本丧失了对视图生命周期的掌控。不少 SwiftUI 开发者都碰到过视图生命周期的行为超出预期的状况(例如视图多次构造、onAppear 无从控制等)。
Swift 5.1 内置于 Xcode 11,新增了很多新特性,比较重要的有以下几个。
已迈入第三个年头的SwiftUI相较诞生初始已经提供了更多的原生功能,但仍有大量的事情是无法直接通过原生SwiftUI代码来完成的。在相当长的时间中开发者仍需在SwiftUI中依赖UIKit(AppKit)代码。好在,SwiftUI为开发者提供了便捷的方式将UIKit(AppKit)视图(或控制器)包装成SwiftUI视图。
当你编写涉及共享状态的代码时,如果你不确保这个共享状态在跨线程使用时是安全的,你就会在许多地方遇到数据竞争的问题。
每当我们将修饰符应用于 SwiftUI 视图时,我们实际上都会创建一个,应用了更改的新视图 —— 我们不仅仅是修改现有的视图。 如果你仔细想想,这种行为是有道理的 —— 我们的视图仅保留我们赋予它们的确切属性,因此,如果我们设置背景颜色或字体大小,则无处存储该数据。
每当我们将修饰符应用于SwiftUI视图时,我们实际上都会创建一个应用了更改的新视图——我们不仅会修改现有的视图。如果您考虑一下,这种行为是有道理的——我们的视图仅保留我们赋予它们的确切属性,因此,如果我们设置背景颜色或字体大小,则无处存储该数据。
Swift 5.5 内置于 Xcode 13,虽然版本号只增加了 0.1,看似是一个小版本升级,但却带来了非常多的新内容,其中最大的更新是引入了全新的并发编程方式。
作为一个严重依赖 SwiftUI 的开发者,同视图打交道是最平常不过的事情了。从第一次接触 SwiftUI 的声明式编程方式开始,我便喜欢上了这种写代码的感觉。但接触地越多,碰到的问题也越多。起初,我单纯地将很多问题称之为灵异现象,认为大概率是由于 SwiftUI 的不成熟导致的。随着不断地学习和探索,发现其中有相当部分的问题还是因为自己的认知不够所导致的,完全可以改善或避免。
SwiftUI与苹果之前的UI框架的区别不仅仅在于如何定义视图和其他UI组件,还在于如何在整个使用它的应用程序中管理视图层级的状态。
在上一篇关于 TCA 的文章中,我们通过总览的方式看到了 TCA 中一个 Feature 的运作方式,并尝试实现了一个最小的 Feature 和它的测试。在这篇文章中,我们会继续深入,看看 TCA 中对 Binding 的处理,以及使用 Environment 来把依赖从 reducer 中解耦的方法。
SwiftUI的@State属性包装器允许我们自由修改视图结构体,这意味着当程序更改时,我们可以更新视图属性以匹配。
大多初学者都会在第一时间惊叹于 SwiftUI 轻松实现各种动画效果的能力,但经过一段时间的使用后,他们会发现 SwiftUI 的动画并非像表面上看起来那样容易驾驭。开发者经常需要面对:如何动、怎么动、什么能动、为什么不动、为什么这么动、如何不让它动等等困扰。对 SwiftUI 的动画处理逻辑了解的不够深入是造成上述困扰的主要原因。本文将尝试对 SwiftUI 的动画机制做以介绍,以帮助大家更好地学习、掌握 SwiftUI 的动画,制作出满意的交互效果。
Safe Area(安全区域)是指不与导航栏、标签栏、工具栏或其他视图控制器提供的视图重叠的内容空间。
在上篇[2]中,我们对 result builders 做了较详细的介绍。本篇我们将通过对 ViewBuilder 的仿制,探索更多有关 SwiftUI 视图背后的秘密。
在WWDC 2021上,苹果为开发者带来了有一个期待已久的功能——AttributedString,这意味着Swift开发人员不再需要使用基于Objective-C的NSAttributedString来创建样式化文本。本文将对其做全面的介绍并演示如何创建自定义属性。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理,并添加了一点个人见解。本文为上篇。
将某个视图在父视图中居中显示是一个常见的需求,即使对于 SwiftUI 的初学者来说这也并非难事。在 SwiftUI 中,有很多手段可以达成此目的。本文将介绍其中的一些方法,并对每种方法背后的实现原理、适用场景以及注意事项做以说明。
本文将通过一段可复现的“灵异代码”,对 State 注入优化机制、模态视图( Sheet、FullScreenCover )内容的生成时机以及不同上下文( 相互独立的视图树 )之间的数据协调等问题进行探讨。
Slider 控件是一种允许用户从一系列值中选择一个值的 UI 控件。在 SwiftUI 中,它通常呈现为直线上的拇指选择器。有时将这种类型的选择器呈现为一个圆圈,拇指绕着圆周移动可能会更好。本文介绍如何在 SwiftUI 中定义一个环形的 Slider。
这个高级SwiftUI动画系列的第五部分将探索Canvas视图。从技术上讲,它不是一个动画视图,但当它与第四部分的 TimelineView 结合时,它带来了很多有趣的可能性,正如这个数字雨的例子所示。
今年 SwiftUI 新增最好的功能之一必须是布局协议。它不但让我们参与到布局过程中,而且也给了我们一个很好的机会去更好的理解布局在 SwiftUI 中的作用。
Swift 5.3 之前即使有多个尾随闭包也只有最后一个能被写成精简的形式,这种写法一个闭包在圆括号内,另一个在外面。新的写法把这些闭包都放在圆括号外面,显得更加简洁。注意:尾随闭包中的第一个闭包的标签会被强制省略。
在这个技术项目中,我们将探讨 SwiftUI 如何处理布局。有些事情已经解释过了,有些可能是你自己弄明白的,但更多的是你在这一点上想当然的事情,所以我希望一个详细的探索能真正为 SwiftUI 的工作方式提供一些启示。
尽管 SwiftUI 的惰性容器以及 Core Data 都有各自的内存占用优化机制,但随着应用视图内容的复杂( 图文混排 ),越来越多的开发者遇到了内存占用巨大甚至由此导致 App 崩溃的情况。本文将通过对一个演示 App 进行逐步内存优化的方式( 由原先显示 100 条数据要占用 1.6 GB 内存,优化至显示数百条数据仅需 200 多 MB 内存 ),让读者对 SwiftUI 视图的存续期、惰性视图中子视图的生命周期、托管对象的惰值特性以及持久化存储协调器的行缓存等内容有更多的了解。
梁启健,携程金融支付中心开发工程师,主要负责支付iOS端的开发与优化工作,喜欢研究大前端和跨平台技术。
打算用几篇文章介绍一下 TCA (The Composable Architecture[1]),这是一种看起来非常契合 SwiftUI 的架构方式。
已经了解了 SwiftUI 如何通过使用 @State 属性包装器将变化的数据存储在结构体中,如何使用 $ 将状态绑定到UI控件的值,以及更改 @state 包装的属性时是如何自动让 SwiftUI 重新调用我们的结构体的 body属性的。
SwiftUI的环境使我们可以使用来自外部的值,这对于读取Core Data上下文或视图的展示模式等很有用。但是我们也可以将自定义对象发送到环境中,并在以后将它们读出来,这使我们可以在复杂的应用程序中更轻松地共享数据。
保证应用不因 Core Data 的原因导致意外崩溃是对开发者的起码要求。本文将介绍可能在视图中产生严重错误的原因,如何避免,以及在保证视图对数据变化实时响应的前提下如何为使用者提供更好、更准确的信息。由于本文会涉及大量前文中介绍的技巧和方法,因此最好一并阅读。
最近,在我正在开发一个在 Dribbble 上找到的设计的 SwiftUI 实现时,我想到了一个点子,可以通过一些酷炫的筛选器扩展该项目以缩小结果列表。
在本文中,我们将深入探讨一些创建 SwiftUI 动画的高级技术。我将广泛讨论 Animatable[1] 协议,它可靠的伙伴 animatableData[2],强大但经常被忽略的 GeometryEffect[3] 以及完全被忽视但全能的 AnimatableModifier[4] 协议。
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
从SwiftUI诞生之日起,预览(Canvas Preview )一直是个让开发者又爱又恨的功能。当预览正常工作时,它可以极大地提高开发效率;而预览又随时可能因为各种莫名其妙的原因崩溃,不仅影响开发进程,同时又让开发者感到沮丧(很难排查出导致预览崩溃的故障)。
RangeValidator 控件用于检测用户输入的值是否介于两个值之间。可以对不同类型的值进行比较,比如数字、日期以及字符。我们一般会用来验证输入的年龄或者考试的分数等。
Apple 引入了新的结构体 UIFont.Width,这代表了一种新的宽度样式。
到目前为止,最后一部分显示了一个简单的文本视图,其中包含用户输入的任何账单金额,但现在是该项目重要部分的时候了:我们希望该文本视图显示每个人需要为账单支付多少。
GeometryReader 自 SwiftUI 诞生之初就存在,它在许多场景中扮演着重要的角色。然而,从一开始就有开发者对其持负面态度,认为应尽量避免使用。特别是在最近几次 SwiftUI 更新中新增了一些可以替代 GeometryReader 的 API 后,这种观点进一步加强。本文将对 GeometryReader 的“常见问题”进行剖析,看看它是否真的如此不堪,以及那些被批评为“不符预期”的表现,是否其实是因为开发者的“预期”本身存在问题。
后续这个SwiftUI分类的文章全部都是针对SwiftUI的日常学习和理解写的,自己利用Swift写的第二个项目也顺利上线后续的需求也不是特着急,最近正好有空就利用这段时间补一下自己对SwiftUI的理解,这个过程当中正好把整个学习过程记录下来,方便自己查阅,也希望能给需要的同学一点点的帮助。由于自己还欠着RxSwift的帐,这次也是想着先放弃别的账务(欠的的确挺多的)先全心全意的把这两块的帐给补补,希望补上这笔账之后自己对Swift的理解也能上一个台阶,对Siwft的理解自认为还是感觉欠缺的,不算是真的深入的掌握,我对SwiftUI也是在学习当中,现在能查阅的关于SwiftUI的资料很多是需要收费的,遇到问题只能想办法努力解决,有写的不钟意的地方,希望多加指正!
前些日子,一位网友在聊天室中就如下的 问题[3] 与大家进行了交流与探讨 —— 如何通过 Text + AttributedString 实现类似文章关键字检索的功能,并可通过按钮在搜索结果中进行滚动切换?
StateObject 是在 SwiftUI 2.0 中才添加的属性包装器,它的出现解决了在某些情况下使用 ObservedObject 视图会出现超预期的问题。本文将介绍两者间的异同,原理以及注意事项。
领取专属 10元无门槛券
手把手带您无忧上云