从SwiftUI诞生之日起,预览(Canvas Preview )一直是个让开发者又爱又恨的功能。当预览正常工作时,它可以极大地提高开发效率;而预览又随时可能因为各种莫名其妙的原因崩溃,不仅影响开发进程,同时又让开发者感到沮丧(很难排查出导致预览崩溃的故障)。
作为一个程序员,如果让你考虑设计一套逻辑对原始文本针对不同语言的进行本地化转换,我想大多数人都会考虑使用字典(键值对)的解决方案。苹果也是采取了同样的处理,通过创建针对不同语言的多个字典,系统可以轻松的查找出一个原始文本(键)对应的本地化文本(值)。比如:
在WWDC 2021上,苹果为开发者带来了有一个期待已久的功能——AttributedString,这意味着Swift开发人员不再需要使用基于Objective-C的NSAttributedString来创建样式化文本。本文将对其做全面的介绍并演示如何创建自定义属性。
本文将介绍在 SwiftUI 视图中打开 URL 的若干种方式,其他的内容还包括如何自动识别文本中的内容并为其转换为可点击链接,以及如何自定义打开 URL 前后的行为等。
Swift 5.5 内置于 Xcode 13,虽然版本号只增加了 0.1,看似是一个小版本升级,但却带来了非常多的新内容,其中最大的更新是引入了全新的并发编程方式。
var heading:String = "By default, both the text stack and the spacer occupy half of the parent view"
NSUbiquitousKeyValueStore 是苹果官方提供的用于在设备间共享键值数据的解决方案。本文将对其用法做以简单介绍,着重探讨如何便捷地在 SwiftUI 中使用 NSUbiquitousKeyValueStore。
SwiftUI之List Group NavigationView ForEach
SwiftUI 提供了强大的布局能力,不过这些布局操作都是在视图之间进行的。当我们想在 Text 中进行图文混排时,需要采用与视图布局不同的思路与操作方式。本文将首先介绍一些与 Text 有关的知识,并通过一个实际案例,为大家梳理出在 SwiftUI 中用 Text 实现图文混排的思路。
随着 SPM( Swift Package Manager ) 功能的不断完善,越来越多的开发者开始在他的项目中通过创建多个 Package 的方式来分离功能、管理代码。SPM 本身提供了对包中各类资源( 包括本地化资源 )的管理能力,但主要局限于在本包中使用这些资源,难以将资源进行共享。在有多个 Target 均需调用同一资源的情况下,原有的方式很难应对。本文将介绍一种在拥有多个 SPM 包的项目中,对资源进行统一管理的方法。
经过上一篇文章,我们已经可以在桌面上展示出一个小组件出来了,你肯定想小试牛刀,动手改一改,那我们就从改小组件的布局做起吧。本文不会讲解Swift语法,如果是熟悉Flutter,Kotlin这种语言的,问题也不大。本文只讲解小组件中常用的SwiftUI组件。
本文来自TME腾讯音乐娱乐-酷我音乐团队,迈腾大队长投稿,本文仅作为个人学习记录使用,也欢迎在许可协议范围内转载或使用,请尊重版权并且保留原文链接,谢谢您的理解合作. 如果您觉得本文章对您能有帮助,您可以使用关注此公众号,感谢支持.
在 2023 年 6 月 6 日的 WWDC 23 上 Apple 推出了 Xcode 15,相比较 Xcode 14,它有如下变化。
在上文中,我列举了一些在 SwiftUI 中使用 Core Data 所遇到的困惑及期许。在今后的文章中我们将尝试用新的思路来创建一个 SwiftUI + Core Data 的 app,看看能否避免并改善之前的一些问题。本文将首先探讨如何定义数据。
已迈入第三个年头的SwiftUI相较诞生初始已经提供了更多的原生功能,但仍有大量的事情是无法直接通过原生SwiftUI代码来完成的。在相当长的时间中开发者仍需在SwiftUI中依赖UIKit(AppKit)代码。好在,SwiftUI为开发者提供了便捷的方式将UIKit(AppKit)视图(或控制器)包装成SwiftUI视图。
在上篇[2]中,我们对 result builders 做了较详细的介绍。本篇我们将通过对 ViewBuilder 的仿制,探索更多有关 SwiftUI 视图背后的秘密。
如果想获得更好的阅读体验,请访问我的博客 www.fatbobman.com[1]
SwiftUI的TextField可能是开发者在应用程序中最常使用的文本录入组件了。作为UITextField(NSTextField)的SwiftUI封装,苹果为开发者提供了众多的构造方法和修饰符以提高其使用的便利性、定制性。但SwiftUI在封装中也屏蔽了不少的高级接口和功能,增加了开发者实现某些特定需要的复杂性。本文为【SwiftUI 进阶】系列文章中的一篇,在本文中,我将介绍如何在TextField中实现如下功能:
梁启健,携程金融支付中心开发工程师,主要负责支付iOS端的开发与优化工作,喜欢研究大前端和跨平台技术。
最早看到这个电子木鱼是在抖音刀叔的视频中,最近貌似在圈内火了,恰逢课上在讲多媒体编程,简单实现一个。
作为一个严重依赖 SwiftUI 的开发者,同视图打交道是最平常不过的事情了。从第一次接触 SwiftUI 的声明式编程方式开始,我便喜欢上了这种写代码的感觉。但接触地越多,碰到的问题也越多。起初,我单纯地将很多问题称之为灵异现象,认为大概率是由于 SwiftUI 的不成熟导致的。随着不断地学习和探索,发现其中有相当部分的问题还是因为自己的认知不够所导致的,完全可以改善或避免。
SwiftUI 通过调用视图实例的 body 属性来获取视图值。在 View 协议中,body 被属性包装器 @ViewBuilder 所标注,这意味着,通常我们只能在 body 中使用 ViewBuilder 认可的 Expression 来声明视图( 如果显式使用 return ,虽然可以避开 ViewBuilder 的限制,但因受只能返回一种类型的限制,影响视图的表达能力 )。
尽管 SwiftUI 的惰性容器以及 Core Data 都有各自的内存占用优化机制,但随着应用视图内容的复杂( 图文混排 ),越来越多的开发者遇到了内存占用巨大甚至由此导致 App 崩溃的情况。本文将通过对一个演示 App 进行逐步内存优化的方式( 由原先显示 100 条数据要占用 1.6 GB 内存,优化至显示数百条数据仅需 200 多 MB 内存 ),让读者对 SwiftUI 视图的存续期、惰性视图中子视图的生命周期、托管对象的惰值特性以及持久化存储协调器的行缓存等内容有更多的了解。
苹果于 WWDC 2023 上推出新框架 SwiftData,提供声明性的、以 Swift 为先的 API,可在 iOS 应用中进行数据持久化工作。SwiftData 可轻松将一个 Swift 类转换为一个持久化模型,非常适合同 SwiftUI 一并使用。
@State是一个属性包装器(property wrapper),被设计用来针对值类型进行状态管理;用于在Struct中mutable值类型
Swift 5.4 带来了一些巨大的编译改进,包括表达式中具有错误的更好的代码完成和增量编译的大幅度提高。但是,它也增加了一些重要的新功能和改进,因此让我们在这里进行深入研究...
本文中我们将探讨在 SwiftUI 视图中批量获取 Core Data 数据的方式,并尝试创建一个可以使用 mock 数据的 FetchRequest。由于本文会涉及大量 前文[1] 中介绍的技巧和方法,因此最好一并阅读。
对每一个使用 Core Data 的开发者来说,用 Xcode 的 Core Data 模型编辑器构建数据模型、创建容器、加载数据模型并通过托管对象上下文最终创建托管对象实例,这都是十分普通的过程。但你是否好奇过这一切的内部运行机制,Core Data 是如何在幕后辅助我们完成这一切的?本文将深入探究 Core Data 是如何通过数据模型构建出托管对象实例的内部运行机制,读完本文可以让你对 Core Data 的工作流程有更深入的理解,在开发中可以更得心应手。
在本文中,我们将深入探讨一些创建 SwiftUI 动画的高级技术。我将广泛讨论 Animatable[1] 协议,它可靠的伙伴 animatableData[2],强大但经常被忽略的 GeometryEffect[3] 以及完全被忽视但全能的 AnimatableModifier[4] 协议。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理,并添加了一点个人见解。本文为下篇。
前些日子,一位网友在聊天室中就如下的 问题[3] 与大家进行了交流与探讨 —— 如何通过 Text + AttributedString 实现类似文章关键字检索的功能,并可通过按钮在搜索结果中进行滚动切换?
保证应用不因 Core Data 的原因导致意外崩溃是对开发者的起码要求。本文将介绍可能在视图中产生严重错误的原因,如何避免,以及在保证视图对数据变化实时响应的前提下如何为使用者提供更好、更准确的信息。由于本文会涉及大量前文中介绍的技巧和方法,因此最好一并阅读。
每个开发新手,在编写软件前都听说过这样一条原则:“别自我重复”。但 App Store 上不少体量最大的 iOS 应用却仍在犯下同样的致命错误:不必要地照搬整个模块。
Table 是 SwiftUI 3.0 中为 macOS 平台提供的表格控件,开发者通过它可以快捷地创建可交互的多列表格。在 WWDC 2022 中,Table 被拓展到 iPadOS 平台,让其拥有了更大的施展空间。本文将介绍 Table 的用法、分析 Table 的特点以及如何在其他的平台上实现类似的功能。
源码 1. Swift 首先看下工程组织结构 下面就是源码了 1. SceneDelegate.swift import SwiftUI class SceneDelegate: UIRespond
iOS 15 在几个月前的 2021 年 9 月发布。在本文中,我分析了 iOS 15 的内置应用程序 :
后续这个SwiftUI分类的文章全部都是针对SwiftUI的日常学习和理解写的,自己利用Swift写的第二个项目也顺利上线后续的需求也不是特着急,最近正好有空就利用这段时间补一下自己对SwiftUI的理解,这个过程当中正好把整个学习过程记录下来,方便自己查阅,也希望能给需要的同学一点点的帮助。由于自己还欠着RxSwift的帐,这次也是想着先放弃别的账务(欠的的确挺多的)先全心全意的把这两块的帐给补补,希望补上这笔账之后自己对Swift的理解也能上一个台阶,对Siwft的理解自认为还是感觉欠缺的,不算是真的深入的掌握,我对SwiftUI也是在学习当中,现在能查阅的关于SwiftUI的资料很多是需要收费的,遇到问题只能想办法努力解决,有写的不钟意的地方,希望多加指正!
VIPER架构模式是MVC或MVVM的另一种选择。虽然SwiftUI和Combine框架创建了一个强大的组合,可以快速构建复杂的ui和在应用程序中移动数据,但它们也面临着各自的挑战和对架构的看法。
随着 Swift 5.5 引入了 async/await 特性,苹果也为 SwiftUI 添加了 task 视图修饰器,以方便开发者在视图中使用基于 async/await 的异步代码。本文将对 task 视图修饰器的特点、用法、注意事项等内容做以介绍,并提供了将其移植到老版本 SwiftUI 的方法。
“对齐”是 SwiftUI 中极为重要的概念,然而相当多的开发者并不能很好地驾驭这个布局利器。在 WWDC 2022 中,苹果为 SwiftUI 增添了 Layout 协议,让我们有了更多的机会了解和验证 SwiftUI 的布局原理。本文将结合 Layout 协议的内容对 SwiftUI 的 “对齐” 进行梳理,希望能让读者对“对齐”有更加清晰地认识和掌握。
本文实例讲述了Android开发之圆角矩形创建工具RoundRect类。分享给大家供大家参考,具体如下:
iOS 14 Apple 推出了 WidgetKit,Widget 就像一个迷你版的 App,可以快速访问它所提供的信息—比如天气、日历事件、笔记等。Widget 还可以充当“快捷方式”,点击它会立即跳转到 App 的指定位置。
苹果开发者大会 WWDC 2019 在北京时间今天凌晨开幕。在这场大会上除了「史上最难看 Mac 主机」、首次出现的iPadOS以外,我们还终于可以对饱受诟病的iTunes说再见了。而对于开发者来说,新发布的 SwiftUI 可能是最吸引人的特性,在 苹果公司软件工程高级副总裁Craig Federighi的演示中,我们可以轻松地把一百行的前端代码缩减到十几行。
在 iOS 14 正式版发布之前我写了一篇博文《iOS开发之WidgetKit》,iOS 14 正式版发布以后,经测试,Apple 改变了 Widget 的 API,所以本文进行一个补充说明(在前文的基础上做了修改,尤其是代码部分)。
拍照 private static final int TAKE_PICTURE = 0; void takePhotoClick() { if (Build.VERSION.SDK_INT >= 23) { requestPermissions(new String[]{Manifest.permission.CAMERA}, REQUEST_CODE_ASK_PERMISSIONS); } else { startActivityForResult(new In
GeometryReader 自 SwiftUI 诞生之初就存在,它在许多场景中扮演着重要的角色。然而,从一开始就有开发者对其持负面态度,认为应尽量避免使用。特别是在最近几次 SwiftUI 更新中新增了一些可以替代 GeometryReader 的 API 后,这种观点进一步加强。本文将对 GeometryReader 的“常见问题”进行剖析,看看它是否真的如此不堪,以及那些被批评为“不符预期”的表现,是否其实是因为开发者的“预期”本身存在问题。
在 UIKit 和 SwiftUI 中设置颜色时,无法直接通过.的方式进行颜色的书写,必须带上前缀UIColor或者Color,因为无法根据上下文进行成员推测,Swift 5.4 中改进了这个语法,可以省去前缀且支持链式调用。
领取专属 10元无门槛券
手把手带您无忧上云