SwiftUI除Canvas外另一种快速预览方案

当我们用SwiftUI编写界面组件时,Xcode编辑器的Canvas窗是一个非常重要工具,它的地位等同于UIKit时代的Storyboard。还记得曾经使用Storyboard时预览功能失效时,修改界面有多么不便。
如果无法对编写的UI进行实时预览,那么开发工作将变得寸步难行。想象一下,每微调一个颜色或尺寸,就编译、运行到模拟器,再点击进入相应界面去查看目标组件的工作状态,万一还要注入模拟数据,那就更是麻烦。
SwiftUI的Canvas发生错误、预览失效的情况常有发生。无法在编辑器预览,那么只能把思路放到运行模拟器预览了。
从编辑器到模拟器预览,步骤有:

  1. 编译、运行 【可提高编译速度】
  2. 进入到对应组件的展示页【可简化】
  3. 注入模拟数据【可简化】

使用@main注解

xxxApp.swift有 @main 注解,申明了程序的运行入口。

@main
struct YourApp: App {
    //...
}

所以,我们大可另外写一个 xxxApp_Preview.swift 文件,只显示要预览的组件。

@main // 当要预览时,打开
struct YourApp_Preivew: App {
    //...
}

// @main 并且把原app的@main注释掉
struct YourApp: App {
    //...
}

到这里,我们解决问题2.
对于问题1的解决,可以从代码编写方式入手,尽量使得组件轻量、独立,展示所用的数据无需通过网络、数据库查询等耗时。可看文末的建议。

规范PreviewProvider的写法

想象一下,如果我们要预览对应组件时,只需像下述这么调用,是不是方便很多?

@main 
struct YourApp_Preivew: App {
	var body: some Scene {
		WindowGroup {
			YourComponent_Previews.Demo()
		}
	}
}

为了实现这一点,我们需要规范PreviewProvider的写法。
把静态变量previews的内容封装成View。
如:

struct YourComponent_Previews: PreviewProvider {
    struct Demo: View {
        var body: some View {
            ZStack {
            YourComponent(number: 0, x: 0, y: 0, textAreaW: 50, textAreaH: 50, textAreaX: 0, textAreaY: 10, textColor: .red)
            }
        }
    }
    
    
    static var previews: some View {
        Demo()
        .frame(width: 500, height: 500)
        .previewLayout(.sizeThatFits)
    }
    
}

上述预览代码的编写方式,既可以给Canvas预览使用,当Canvas抽风时,又可以给xxxApp.swift调用,很是方便。

其它建议

对于组件的开发,其UI展示数据尽量由外界传入(通常有个父容器组合各个组件,就由父容器负责获取数据并传入),并优先使用简单数据(原生数据、还有比较常用UIKit的CGSize、UIImage等),这样比较容易写预览代码,也不会把组件和大的程序逻辑混在一起。

posted @   逆行  阅读(405)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
点击右上角即可分享
微信分享提示
主题色彩