第十八章 封装HUD和完善登录界面逻辑

我们几乎在 LoginPageViewModel 添加了大量的代码,才实现了请求展示 HUD,请求完毕展示信息之后 2 秒自动消失。

我们需要每个界面都要写这么多的代码吗?我们可以考虑进行封装,那么我们可以将 @MainActor 和 相关的 HUD的属性和逻辑转移到 BaseViewModel 里面。

我们进行登陆的方法的代码依然没有减少,我觉得这样的代码量还是很多。我们可以精简一下,请求的时候可以根据我们传入的参数自动显示 HUD,和自动的展示 错误的提示。

正确的提示交给使用者,这样精简之后,使用起来岂不是更加的简单。

这样我们使用起来,代码量就变得很简单了,而且如果中间多次请求,只需要在最后关闭 HUD 即可。

我们思考一下,我们每一个界面都需要设置下面代码来支持 HUD的显示吗?

我们可以使用继承方式,但是遗憾的是 Struct 不支持继承。我们用协议实现怎么样呢?

我们将所有单独的页面需要实现我们新增的扩展方法。

虽然也代码量也没有省多少,但是不需要传递那么多的参数,从而后面的改动不会影响外层的使用。

我们登陆不可能这么的逻辑代码不可能这么的简单,如果用户没有输入用户名和密码,自然不需要进行请求,浪费网络资源。

那么对于没有用户名和密码输入,我们则进行提示用户。

我们发现当我们直接点击登录按钮的时候,界面没有任何的提示。这是因为我们当时设置了只有 isAnimating = true 才会展示 HUDView,我们修改一下代码。

这样就完成了如果用户名和密码没有输入就提示用户输入,之后进行登录就加载 HUD,请求完毕展示信息。

我们登陆完毕之后,如果用户开启了记住密码,我们需要将用户的用户名和密码保存下来,下次不需要用户输入用户名和密码。

那么我们需要用到 @AppStorage,但是我们直接修改成下面代码,会有什么问题呢?

这样就算我们开启记住密码,系统已经将用户名和密码保存下来了。我们只能放在AppConfig里面,当开启就设置 AppConfig 的用户名和密码,进入登陆页面就读取 AppConfig 之前保存的用户名和密码。

我们在 LoginPageViewModel 的登录方法里面,当登录成功并且开启保存将用户名和密码进行保存。

我们在 LoginPageViewModel 的初始化方法里面,将之前保存的 用户名和密码进行设置。

我们登录完毕获取到的 gatewayUserName 相当于 JWT,用于后续需要用户的接口,那么我们也保存在 AppConfig 里面。

到此为止,我们终于完成了 LoginPage 的交互和逻辑。

相关推荐
东坡肘子2 天前
Swift 并发正被更广泛地接纳 -- 肘子的 Swift 周报 #133
人工智能·swiftui·swift
文件夹__iOS5 天前
SwiftUI 核心选型:class + ObservableObject VS struct + @State
ios·swiftui·swift
Wenzar_6 天前
# 发散创新:SwiftUI 中状态管理的深度实践与重构艺术 在 SwiftUI 的世界里,**状态驱动 UI 是核心哲学**。但随
java·python·ui·重构·swiftui
大熊猫侯佩7 天前
GeometryReader 生存指南(下集):与恶魔共舞——陷阱、禁忌与最终救赎
swiftui·performance·layout·frame·stack·geometryreader·preferencekey
大熊猫侯佩8 天前
别被系统绑架:SwiftUI List 替换背后的底层逻辑
swiftui·swift·apple
东坡肘子9 天前
从 OpenSwiftUI 到 DanceUI:换个方式 Dive SwiftUI -- 肘子的 Swift 周报 #132
人工智能·swiftui·swift
用户794572239541310 天前
【SwiftyJSON】拯救你的 as? [String: Any]——链式 JSON 访问的正确姿势
swiftui·objective-c·swift
用户794572239541310 天前
【Moya】为什么你的 Alamofire 代码需要再封装一层?
swiftui·objective-c·swift
空中海11 天前
第二章:SwiftUI 视图基础
ios·swiftui·swift