Tag: Rxflow

RxFlow第1部分:理论上

RxFlow是基于Reactive Flow Coordinator模式的iOS应用程序导航框架。 该项目是RxSwiftCommunity组织的一部分。 这三篇文章对它的详细概念进行了解释: RxFlow第1部分:理论上 RxFlow第2部分:实践中 RxFlow第3部分:提示和技巧 这是Github存储库:https://github.com/RxSwiftCommunity/RxFlow 感谢您的反馈,随时可以贡献contribute 我将介绍RxFlow :我的设计框架,在iOS应用程序中实现了Reactive Flow Coordinator。 RxFlow是RxSwiftCommunity支持的项目。 关于iOS应用程序中的导航,有两种选择: 使用Apple和Xcode提供的内置机制:Storyboard和Segues 直接在代码中实现自定义机制 这两种解决方案的缺点: 内置机制:导航是相对静态的,并且情节提要非常庞大。 导航代码污染了UIViewControllers 自定义机制:根据所选的设计模式(路由器,协调器),代码可能难以设置并且可能很复杂 RxFlow旨在: 促进将故事板切割成原子单元,以实现协作和UIViewControllers的可重用性 允许根据导航上下文以不同方式呈现UIViewController 简化依赖注入的实现 从UIViewControllers删除任何导航机制 促进反应式编程 在处理大多数导航案例的同时,以声明的方式表示导航 促进将应用程序切成逻辑导航块 从情节提要到协调器模式 随着我作为iOS开发人员(以及Android或Web应用程序开发人员)的经验的增长,我一直面临着有关导航的同样疑问。 对于所有其他概念问题,有很多模式可以解决常见的体系结构问题和关注点需求分离(MVC,MVP,MVVM,VIPER等)。 但是,一旦设计导航,我就被撕碎了: 如何在Storyboard / Segues中使用依赖项注入? 如何控制应用程序的流程? 如何摆脱UIViewControllers中的导航样板代码? 随着时间的流逝,我对iOS应用程序的构想从带有一个Storyboard的MVC到带有多个Storyboard的MVC,最终达到了我们可以称为当今最佳实践之一:带有Flow Coordinator的 MVVM。 这非常好,因为我们可以玩依赖注入,UIViewControllers可重用性和可测试性。 我有机会将这种模式应用于生产中的大型复杂应用程序。 但是最后,仍然有一些问题困扰着我: 我总是不得不一次又一次地编写协调器模式, 有很多委派模式用于允许ViewModel与协调器进行回通讯。 我开始研究Redux模式,尤其是导航状态机制。 我们可能有一个全局导航状态,该状态通过RxSwift Observables公开,并且有人在监听此状态并驱动导航。 我发现唯一令人不安的是这种导航状态的独特性以及它可能具有的不受控制的责任(以及它可以存储的海量数据) 导航只是一种状态的反射,这种状态可以逐步修改的想法开始出现。 一种状态,将散布在整个应用程序结构中,而不是存储在单个位置中,而是由观察者统一起来,可以对它作出反应并因此驱动导航。 在本文的后面,这些散布在应用程序中的小状态称为“ 步骤” […]

RxFlow第3部分:提示和技巧

RxFlow是基于Reactive Flow Coordinator模式的iOS应用程序导航框架。 该项目是RxSwiftCommunity组织的一部分。 这三篇文章对它的详细概念进行了解释: RxFlow第1部分:理论上 RxFlow第2部分:实践中 RxFlow第3部分:提示和技巧 这是Github存储库:https://github.com/RxSwiftCommunity/RxFlow 感谢您的反馈,随时可以贡献contribute 让我们深入探讨我在响应式编程方面遇到的一些技巧和窍门。 UIViewControllers使反应 正如我们在第2部分中所看到的,我们需要在某个时候以响应方式知道何时显示一个Presentable 。 一个可呈现对象公开了3个可观察对象: 在RxFlow中 ,UIViewController符合此协议,因此我们必须找到一种使它们具有反应性的方法。 希望在此过程中发现的一个很棒的项目在此方面起到了很大的帮助:RxViewController。 通过应用我在这篇文章中描述的模式,它为UIViewControllers提供了Reactive扩展:Swift中的Verstatile命名空间。 此外,它使用RxCocoa内置函数可以观察选择器调用。 一旦理解了这一概念,便对UIViewController进行了自己的扩展。 作为记录,这就是协调器的用法,其中“ nextPresentable”是由Flow上的“ navigation (to 🙂 ”函数生成的Presentable 。 在关联的Presentable第一次显示之后,我们仅听下一个Stepper 。 让我们暂停一下 RxFlow中的另一个关键原理是: 流中发生的事情,留在流中 。 因此,如果Flow不再位于视图层次结构的顶部,我必须找到一种方法来“暂停” Steps的订阅。 RxSwift不提供“开箱即用”的方式来暂停订阅,但RxSwiftExt可以。 这是来自RxSwiftCommunity的项目。 它为RxSwift添加了许多新的运算符,例如“ pausable”。 除非第二个可观察序列中的最新元素为true,否则它将暂停源可观察序列的元素。 让我们看一下实现。 实际上,这只是3个RxSwift内置运算符的组合: withLatestFrom:与由主要Observable触发的值相关联,该值是另一个称为“ pauser”的Observable的最后一个值(驱动暂停的那个值) 过滤器:仅接受“ pauser”中可观察到的值为true的值 映射:忽略制表符的Observable值,以便仅返回的值是主Observable的值 再次,这是协调器使用的方式: 这很容易理解:当“ rxVisible”的Observable值为false时,nextStepper的步骤将暂停。 具有存储属性的协议? 作为面向协议的框架, RxFlow希望开发人员实现多种协议。 当您建立这种框架时,您不希望用户为实现那些协议而必须实现的过多功能或特性感到困扰。 […]

RxFlow第2部分:实践中

RxFlow是基于Reactive Flow Coordinator模式的iOS应用程序导航框架。 该项目是RxSwiftCommunity组织的一部分。 这三篇文章对它的详细概念进行了解释: RxFlow第1部分:理论上 RxFlow第2部分:实践中 RxFlow第3部分:提示和技巧 这是Github存储库:https://github.com/RxSwiftCommunity/RxFlow 感谢您的反馈,随时可以贡献contribute 综上所述, RxFlow旨在: 简化将导航切割为逻辑部分 从视图控制器中删除导航代码 鼓励视图控制器的可重用性 促进反应式编程 促进依赖注入 快速提醒您以下术语: Flow :每个Flow都定义了应用程序中的导航区域。 步骤 :每个步骤都是应用程序中的导航状态。 流程和步骤的组合描述了所有可能的导航操作。 步进器 :可以是任何可以发出步进的东西。 步进器将负责触发流中的每个导航动作 可表示的 :它是可以表示的东西的抽象,基本上UIViewController和Flow是可表示的 NextFlowItem :它告诉协调器将在其响应式机制中产生新步骤的下一件事是什么 协调员 : 协调员的工作是以一致的方式混合流程和步骤的组合 同样重要的是要记住, RxFlow使用面向协议的编程,这样它才不会将代码冻结在继承层次结构中。 在RxFlow仓库中,您将找到一个演示应用程序。 它几乎显示了每种可能的导航类型: 导航堆栈 标签栏 掌握/细节 模态弹出 RxFlow主要是关于以反应方式处理导航状态更改。 为了在多个上下文中重用,这些状态必须不知道用户所处的当前导航流。因此,状态不是表示“我要转到此屏幕”,而是表示“某人或某件事已完成”。此操作”, RxFlow将根据当前导航流选择正确的屏幕。 使用RxFlow时 ,此导航状态称为步骤 。 枚举是描述步骤的好方法: 它们易于使用, 一个值只能定义一次(因此状态是唯一的) 使用它们是安全的,因为Swift希望您在switch语句中实现所有可能的值 他们可以嵌入将从一个屏幕提供给另一个屏幕的值 它们是值类型,因此不存在传播不受控制的共享引用 例如,在演示应用程序中,所有这些都是我们涵盖导航可能性所需的所有步骤 。 […]