34 篇博文 含有标签「iOS」

在开发 iOS 应用时，推送通知是与用户保持联系的关键功能。然而，在接入苹果的 APNS（Apple Push Notification Service）时，可能会遇到各种技术挑战。以下是一些常见的 APNS 推送服务接入问题及其解决方案。

本次发布会总共 4 款 iPhone：基础款 iPhone 14，加大基础款 iPhone 14 Plus，Pro 款 iPhone 14 Pro，加大 Pro 款 iPhone 14 Pro Max。

又是一年一度的 WWDC，例行总结一下。

本专题主要解决 Swift 5.5 增加的 Concurrency 功能的学习，首要问题就是要明白Swift Concurrency 是什么。

推荐从官方文档学起，对接口使用能有些概念，接着从提案清单去了解，为什么提出这个功能？解决了什么问题？最终采取的方案为什么是这样做？

最后，可以看看别人对这个功能的理解，以及在实际场景下的实践经验。

定义​

先看一下ViewBuilder的定义，实际上这是一个@resultBuilder 的 struct。

@resultBuilder public struct ViewBuilder {

    public static func buildBlock() -> EmptyView

    public static func buildBlock<Content>(_ content: Content) -> Content where Content : View
}

问题起源​

SwiftUI 的可变容器 View 有VStack, HStack, ZStack, ForEach, Group等。

@ViewBuilder 因为是 @resultBuilder修饰的 struct，定义了很多静态方法buildBlock，这些方法可以接收一个或多个子 View，实际返回的是一个TupleView类型，最多接收 10 个参数。

我们可以用具体的方法来调用：

// TupleView<(Text, Text)>
let inner = ViewBuilder.buildBlock(

前端快速发展了这么多年，诞生了非常多有意思的 State 框架，用法上都有自己的一套，但是归根结底还是围绕着 Mutable 还是 Immutable 的选择。本人深受 React 的颠覆式影响，近几年都是跟随 Immutable 的单项数据流模式，所以在架构上选择时，除了基础的 MVVM + Reactive，有时还会把 Flux 也引入其中。

说到 Flux，那就不得不提 Redux 了。Redux 并不是完全照搬了 Flux 的思想，而是提倡全局 Store，整个应用使用同一个 Store，所有的公共状态都从 Store 获取。这当然是有待商榷的，因为应用大了，公共状态必然很多，怎么分别管理子状态是要慎重考虑的。本人更倾向于尽量使用类似 React 的 useState，先把状态分散化管理，有需要的复杂界面采用useReducer, 全局 Store 只存储一些登录状态、主题、语言等相关的设置。

State 设计好之后，就是 UI 开发的事情了。上古时代，jQuery 将 State 和 CSS 一起拼成 HTML 字符串给某个标签赋值，对应到前几年写的 iOS UIKit 代码也是类似情况，那种命令式刷新 UI 的方式难看至极，已经过时了。

为什么需要依赖注入，则不在本文讨论范围中。

Why Resolver?​

Swift 的依赖注入库有很多，比如 GitHub Star 数最多的Swinject，也有大厂开源的如 Uber 的Needle，百度的CarbonGraph, 其它的如Cleanse，以及本文介绍的Resolver。

为什么技术选型时选择 Resolver？ 最重要的一点是 Resolver 的接口设计非常简洁，能够适应各种依赖注入的场景。

原文：Building a token refresh flow with async/await and Swift Concurrency

Swift 5.5 引入了 async/await，更进一步简化异步代码的语法。

本文作者使用网络请求中自动刷新 token 的功能来说明用法，这是 OAuth 2 里面必备的一个功能了。

导航栏返回按钮的标题是前一个 View Controller 的 title，但是设计 App 时基本上只保留箭头，所以这个标题很鸡肋。