八个常见的SwiftUI误用及对应的正确打开方式

直接把八条误用先简明扼要地罗列如下，然后我们逐条深入展开：

1. 添加不必要的 View 和 Modifier
2. 在需要用 @StateObject 的地方用了 @ObservedObject
3. Modifier 顺序错误
4. 给属性包装器添加属性观察者
5. 在需要用描边框的地方使用了描形状
6. Alert 和 Sheet 与可选状态的使用
7. 尝试改变 SwiftUI 视图后面的东西
8. 用错误的范围动态创建视图

表单

用户输入一些信息，SwiftUI 为这种场景专门提供了一个视图类型，称为Form，Form是一个可滚动列表，除了可以包含文本和图像这样的静态控件，也可以包含文本框，开关，按钮这些用户可交互的控件。

可以在form里放进任意多你想要的元素，不过如果元素超过10个，SwiftUI会要求你对元素进行分组。

静态工厂

静态工厂模式的三个好处

命名构造器

静态工厂模式的头等好处是：每一个静态工厂方法都有一个自己的名字。Apple 在 UIColor 类实现中使用这个模式创建了许多命名颜色，比如 .red， .yellow，等。 注意，Swift 中的这种实现并非是方法，而是静态属性，返回一个实际的实例。

1
2
3
4
5
6
7

public extension TimeInterval {
    public static var second: TimeInterval { return 1 }
    public static var minute: TimeInterval { return 60 }
    public static var hour: TimeInterval { return 3_600 }
    public static var day: TimeInterval { return 86_400 }
    public static var week: TimeInterval { return 604_800 }
}

记住一天或者一周有多少秒很困难吧？所以 TimeInterval.week比604_80 好多了。

委托代理

委托代理设计模式一种相对易用的两个对象间通信的方式。

init模式

初始化是准备要使用的类，结构体或枚举的实例的过程。

逐一成员构造器 (只有结构体有)

编译器会为结构体自动生成一个逐一成员构造器。生成的构造器将包含除拥有默认值的常量属性之外的所有属性，包括可选型；它的可访问性是 internal，所以对其他模块不可见。

只要结构体的任何一个存储属性是 private 的，那么结构体的默认逐一成员构造器也将是 private 的。同样，如果结构体的任何一个存储属性是 file private 的，那么逐一成员构造器也将是 file private 的。其他情况，这个构造器的访问级别是 internal。

简单类型

Playground是一个可以供你输入Swift代码并立即看到结果的沙盒环境

Make your Combine code reusable

在上一篇文章中，我向你展示了如何使用Combine来改善Combine管道的错误处理，并以一种对用户有意义的方式暴露SwiftUI应用中的错误。

不出所料，我们最终得到的代码看起来比开始时要复杂一些。正确处理错误比完全不处理错误(或忽略错误)占用更多的代码行。

但是我们可以做得更好!

在这篇文章中，你将了解Combine操作符:它们是什么，它们是如何工作的，以及如何将我们的代码重构成一个自定义的Combine操作符，从而使其更容易推理(reason about)，同时更易于重用。

How to handle errors and expose them to the user

作为开发者，我们往往是一群相当乐观的人。至少这是您在查看我们编写的代码时得到的印象——我们主要关注的是正确的路径，并且倾向于在错误处理上花费较少的时间和精力。

即使在本系列中，我们也一直忽略了错误处理。事实上，我们大多忽略了这一点:在之前的文章中，我们用默认值替换了任何错误，这对于我们的应用原型来说是可以的，但对于任何进入生产阶段的应用来说，这可能不是一个可靠的策略。

这一次，让我们仔细看看如何适当地处理错误!

由于大多数地方都有高速、低延迟(low-latency)的互联网，我们很容易忘记，并不是所有用户在使用我们的应用程序时都在快速、低延迟的上行链路上。你甚至不用去偏远的地方就能体验到不稳定的网络连接。我住在德国汉堡，尽管高速移动互联网无处不在，但在一些主要的地面交通线路上，有相当多的地方没有或非常糟糕的连接。

在构建访问互联网的应用程序时，我们应该注意这一点，并确保我们不会浪费带宽。

在本系列的这一部分中，我想重点讨论如何在使用Combine时优化应用程序中的网络访问。

overview

单例类是一种设计模式，在任何给定时间，程序中只能存在一个类的实例。这意味着每次从该类创建对象时，它都会返回相同的实例。当我们想要确保应用程序中只有一个类的实例时，通常使用单例类，例如应该在整个程序中使用的配置类。

另一方面，依赖注入是一种设计模式，其中对象的依赖项由外部实体注入到对象中，而不是对象自己创建它们。换句话说，对象不是创建自己的依赖项，而是提供来自外部的依赖项。这使得对象更具模块化和可测试性，因为它可以很容易地替换为模拟对象以进行测试。

依赖注入通常用于代码复杂性较高的大型应用程序中，并且需要减少应用程序不同部分之间的耦合。它还允许在应用程序的设计中具有更大的灵活性，使其更容易修改和扩展。

总之，单例类和依赖注入的主要区别在于单例确保一个类在程序中只存在一个实例，而依赖注入是一种从外部向对象提供其依赖的方法。它们可以一起使用，但是它们在软件设计中服务于不同的目的。