一种IOS中视图组织方法及系统与流程

文档序号:12595548阅读:268来源:国知局
一种IOS中视图组织方法及系统与流程

本发明涉及IOS视图技术领域,更具体地,涉及一种IOS中视图组织方法及系统。



背景技术:

目前,iOS应用开发中用户看得见的界面都是通过视图控制器(view controller)来组织调度的,在传统的苹果设计思路下,一个视图控制器中通常会处理视图(view)、网络请求(network)、代理(delegate)、其他(other)等部分的逻辑,如图1所示。在进行界面开发时,一般的流程是按照设计稿分析有哪些子视图,然后在一个视图控制器中用原生控件构造出一个个的子视图,装配子视图,最后实现设计稿的效果。伴随着移动互联网的发展,移动端应用程序功能越来越多,视图结构越来越复杂,早先在视图控制器中一个一个控件构造子视图的方案造成视图控制器里代码过多且不易维护,无法在其他视图控制器中复用。

为解决上述技术问题,现有技术中出现了封装子视图的方案。在封装子视图的方案中,通过控件构造子视图的逻辑封装在了子视图的内部,在视图控制器中只需要直接构造已经封装好的子视图就可以直接使用,提升了视图控制器的一定的结构性。

然而,现有封装子视图的方案只解决了视图控制器中的view部分的逻辑,network、delegate、other部分逻辑仍然都在一个视图控制器中处理,而由于这三部分逻辑都是依赖于view的逻辑的,在视图控制器内部需要根据view的不同而做不同的逻辑处理,造成可读性差和不好维护的问题。可读性差主要体现在所有逻辑都在一个视图控制器中处理,一大片一大片的代码不易阅读,同时在前面提到的view、network、delegate、other各部分逻辑分散不连贯。不好维护主要体现在当出现方案变更或需要进行扩展时,改动或扩展的成本非常高,因为当某个视图需要变更时,需要修改视图控制器中network、delegate、other部分中对应的依赖此视图的部分代码。



技术实现要素:

本发明为克服上述问题或者至少部分地解决上述问题,提供一种IOS中视图组织方法和系统。

根据本发明的一个方面,提供一种IOS中视图组织方法,包括:

步骤1,将待构建视图中各子视图的UI视图类和与其对应的各逻辑分别封装在各个子视图控制器中;

步骤2,基于所述各子视图控制器组成所述待构建视图的主视图控制器;所述主视图控制器通过调用各子视图控制器中的UI视图类和与其对应的各逻辑从而实现待构建视图的组织。

根据本发明的另一个方面,提供一种IOS中视图组织系统,包括第一模块和第二模块:

所述第一模块,与所述第二模块相连,用于将待构建视图中各子视图的UI视图类和与其对应的各逻辑分别封装在各个子视图控制器中;

所述第二模块,与所述第一模块相连,用于基于所述各子视图控制器组成所述待构建视图的主视图控制器;所述主视图控制器通过调用各子视图控制器中的UI视图类和与其对应的各逻辑从而实现待构建视图的组织。

本申请提出本发明描述了一种IOS中视图组织方法及系统,此方案主要思路是将原视图控制器中的view、network、delegate等逻辑封装成一个一个的子视图控制器,每种样式的view对应一种子视图控制器,在其内部去处理各自的view、network、delegate等逻辑。然后将各子视图控制器像搭积木一样来组成最终的视图控制器。本发明有效提升代码的结构化、易阅读和可维护性,提升代码应变需求变更的能力,提高版本迭代的速度。

附图说明

图1为现有技术中传统视图控制器结构示意图;

图2为根据本发明实施例一种IOS中视图组织方法的整体流程示意图;

图3为根据本发明实施例一种IOS中视图组织方法中所述构建的主视图控制器结构示意图;

图4为根据本发明实施例一种IOS中视图组织系统的整体结构示意图。

具体实施方式

下面结合附图和实施例,对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明,但不用来限制本发明的范围。

本发明描述了一种结构化的视图组织方案,基于此方案可以构造出结构化、可读性强、维护成本低、扩展性强的视图控制器。主要思路是将原视图控制器中的view、network、delegate、other逻辑封装成一个一个的子视图控制器,每种样式的view对应一种子视图控制器,在其内部去处理各自的view、network、delegate、other逻辑。然后将各子视图控制器像搭积木一样来组成最终的视图控制器。示意图如图2所示。

如图3,本发明一个具体实施例中,示出一种IOS中视图组织方法总体示意图。整体来说,包括:步骤1,将待构建视图中各子视图的UI视图类和与其对应的各逻辑分别封装在各个子视图控制器中;步骤2,基于所述各子视图控制器组成所述待构建视图的主视图控制器;所述主视图控制器通过调用各子视图控制器中的UI视图类和与其对应的各逻辑从而实现待构建视图的组织。

在本发明另一个具体实施例中,一种IOS中视图组织方法,所述步骤1还包括:

S11,将所述待构建视图拆分成各子视图:按照视图设计稿将视图拆分成一个一个的子视图view1、view2、…、viewN。

生成各子视图相对应的UI视图类:针对每个视图创建与之对应的UIView子类ViewClass1、ViewClass2、…、ViewClassN(在iOS开发中,所有的视图都应该是UIView类或UIView的子类),并在这些子类中按照设计需要封装其构造逻辑。

S12,基于所述各UI视图类生成与所述各子视图相对应的各子视图控制器、与所述各子视图相关的逻辑;生成与所述各子视图相关的逻辑:针对每个ViewClass,创建与之对应的视图控制器类即UIViewController的子类(在iOS开发中,所有的视图控制器都应该是UIViewController的子类)ViewController1、ViewController2、…、ViewControllerN,并在这些子类中封装其network、delegate、other等部分逻辑,并暴露handleNetwork、handleDelegate、handleOther等方法供外部调用(依赖具体场景不同,此三类方法能够有多个),这样做的好处是将每个视图的逻辑封装在自己的视图控制器中,符合高内聚标准,避免了后面将要提到的主视图控制器中出现大量的碎片代码(碎片代码指逻辑不连贯的代码)。而传统方案中没有视图控制器的封装,所有逻辑都是通过视图直接写在主视图控制器中,这样会造成主视图控制器中出现大量的和该视图相关的代码,最后造成逻辑不连贯而成为碎片代码。

S13,基于不同子视图,将所述各UI视图类和所述相关的逻辑分别封装在所述各子视图控制器中。

在本发明另一个具体实施例中,一种IOS中视图组织方法,所述步骤1还包括:步骤1中各逻辑还能够为:网络请求逻辑network、代理逻辑delegate和其他other逻辑(包括但不限于:用户交互事件响应逻辑、网络状态变更监听逻辑、网络请求逻辑和/或代理逻辑)。

在本发明另一个具体实施例中,一种IOS中视图组织方法,所述步骤2中利用所述主视图控制器通过调用各子视图控制器中的UI视图类还包括:主视图控制器通过控制各子视图控制器,从各子视图控制器中获取对应的UI视图类并添加到主视图控制器的UI视图类中。

在本发明另一个具体实施例中,一种IOS中视图组织方法,所述步骤2中利用所述主视图控制器通过调用各子视图控制器中的UI视图类对应的各逻辑从而实现待构建视图的组织还包括:所述主视图控制器通过调用各子视图控制器中所封装的网络请求逻辑并添加到主视图控制器网络请求逻辑中;所述主视图控制器通过调用各子视图控制器中所封装的代理逻辑并添加到主视图控制器代理逻辑中。

在本发明另一个具体实施例中,一种IOS中视图组织方法,所述步骤各个子视图控制器ViewClass为UIViewController的子类。

在本发明另一个具体实施例中,一种IOS中视图组织方法,所述步骤主视图控制器通过控制各子视图控制器从各子视图控制器中获取对应的UI视图类并添加到主视图控制器的UI视图类中还包括:主视图控制器通过ViewControllerFactory获取各子视图控制器,调用各子视图控制器中的UI视图类添加到主视图控制器视图VIEW中。

继承UIViewController类创建主视图控制器MainViewController,在其viewDidLoad方法(此方法是UIViewController类中处理视图加载成功之后的回调的地方,通常用来处理自定义视图的装配等逻辑,按照具体场景与功能点不同,此处构造子视图来组成界面效果的逻辑还能够放在viewWillAppear、viewDidAppear以及视图控制器中其他需要构造视图结构的地方)中通过ViewControllerFactory获取ViewController1、ViewController2、…、ViewControllerN,从视图控制器中获取对应的视图view1、view2、…、viewN,将这些视图添加到MainViewController的视图view中,并按照设计稿要求将这些视图放置到对应的位置。这里与传统方法类似,但是传统方法是主视图控制器中直接创建视图,而在本方案中是通过视图控制器来获取对应的视图。

在本发明另一个具体实施例中,一种IOS中视图组织方法,所述步骤所述主视图控制器通过调用各子视图控制器中所封装的网络请求逻辑并添加到主视图控制器网络请求逻辑中;所述主视图控制器通过调用各子视图控制器中所封装的代理逻辑并添加到主视图控制器代理逻辑中还包括:

主视图控制器通过ViewControllerFactory获取各子视图控制器,调用各子视图控制器中封装的网络请求逻辑并添加到主视图控制器网络请求逻辑中。

在MainViewController中创建用来处理network逻辑的handleNetwork方法(按照界面效果不同以及功能点不同,此处方法能够有多个,方法名不限于此名称),在此方法中进行网络请求逻辑的调度,针对视图viewX,通过ViewControllerFactory获取需要的子视图控制器ViewControllerX,由于viewX的网络请求部分逻辑已经封装在ViewControllerX中,此时只需要对ViewControllerX调用其网络请求的方法handleNetwork即可。这样在主视图控制器中只需要对网络请求逻辑进行调度,即根据具体使用场景来确定需要调用哪个子视图控制器的网络请求逻辑,代码量小,结构清晰。而在传统方案中,所有视图的网络请求逻辑和调度逻辑都挤在主视图控制器中相同部分,代码量大,逻辑混乱。

主视图控制器通过ViewControllerFactory获取各子视图控制器,调用各子视图控制器中封装的代理逻辑并添加到主视图控制器代理逻辑中。

在MainViewController中创建用来处理delegate逻辑的handleDelegate方法(按照界面效果不同以及功能点不同,此处方法能够有多个,方法名不限于此名称),在此方法中进行delegate逻辑的调度,针对视图viewX,通过ViewControllerFactory获取需要的子视图控制器ViewControllerX,由于viewX的网络请求部分逻辑已经封装在ViewControllerX中,此时只需要对ViewControllerX调用其网络请求的方法handleDelegate即可。

在MainViewController中创建用来处理other逻辑的handleOther方法(按照界面效果不同以及功能点不同,此处方法能够有多个,方法名不限于此名称),在此方法中进行delegate逻辑的调度,针对视图viewX,通过ViewControllerFactory获取需要的子视图控制器ViewControllerX,由于viewX的网络请求部分逻辑已经封装在ViewControllerX中,此时只需要对ViewControllerX调用其网络请求的方法handleOther即可。

在本发明另一个具体实施例中,一种IOS中视图组织方法,所述ViewControllerFactory还包括:继承NSObject类创建视图控制器工厂类ViewControllerFactory,在其内部封装视图控制器创建的逻辑。

继承NSObject类创建视图控制器工厂类ViewControllerFactory(在面向对象中,继承是指对某个类的扩展,此处ViewControllerFactory为NSObject的子类,具备NSObject所有属性与行为特征,NSObject是iOS中绝大部分类的基类,即绝大部分类都继承自NSObject,剩下的极少数类的基类是NSProxy,iOS开发中一般都是从NSObject继承,下同),在其内部封装视图控制器创建的逻辑,这样可以很方便的在后面将要提到的主视图控制器中通过ViewControllerFactory来获取想要的视图控制器,而不用耦合到特定的视图控制器,这样避免了主视图控制器对子视图控制器的依赖,后期如果想要修改主视图控制器中的视图结构,只需要调整ViewControllerFactory获取子视图控制器的逻辑即可,而不用修改主视图控制器。

以上,通过将界面中每个主要的子视图封装成子视图控制器,在子视图控制器内只需要处理自己的逻辑,没有混合其他视图视图的逻辑,逻辑清晰,代码量相比原来的庞大的视图控制器来说也少了很多。而在主视图控制器中,各逻辑部分只剩下调度的逻辑,阅读性相对于传统的方案来说提升了很多。一旦有需求变更,只需要修改需要变更的子视图控制器中的逻辑即可,若需要扩展,只需要将需要添加的视图封装成子视图控制器,然后像“积木”一样添加到主视图控制器中即可。

如图4,在本发明另一个具体实施例中,示出一种IOS中视图组织系统的总体结构图。整体上,包括第一模块A1、工厂模块A2和第二模块A3:

所述第一模块A1,与所述工厂模块A2相连,用于将待构建视图中各子视图的UI视图类和与其对应的各逻辑进行封装;所述工厂模块A2,分别与所述第一模块A1、第二模块A3相连,根据所述第二模块A3的调用请求,从所述第一模块A1调用相应的各子视图控制器中的UI视图类和与其对应的各逻辑;所述第二模块A3,与所述工厂模块A2相连,用于基于所述各子视图控制器组成所述待构建视图的主视图控制器;所述主视图控制器通过所述工厂模块调用各子视图控制器中的UI视图类和与其对应的各逻辑从而实现待构建视图的组织。

最后,本申请的方法仅为较佳的实施方案,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1