在 iOS组件化方案调研 这篇中,对组件化的应用场景和实现方式做了简单的调研。最终在项目中采用的是 casa 的
CTMediator
这套方案。以下是CTMediator 的一个简单的使用教程。
一、普通页面跳转用法
假设我们有个页面叫 OneViewController
,当前页面为 HomeViewController
,普通情况下页面的间的跳转方式如下:
1 | #import "HomeViewController.h" |
这样做看上去没什么问题,实际也没什么问题。
但是,考虑以下情况:
- 如果
HomeViewController
里有 N 个这样的 button 事件,每个点击后的跳转都是不同的页面,那么则HomeViewController
里,需要导入 N 个这样的OneViewController.h
; - 如果
HomeViewController
是一个可以移植到其它项目的业务模块,在拖出首页HomeVC
相关的业务代码时,难道还要把 ‘HomeViewController.m’ 导入的 N 个其它XxxViewController.h
都一块拖到新项目中么?
这点就是因为代码的耦合导致了首页 HomeVC
没法方便的移植。
说这样没有问题,是因为普通情况下,我们并没有移植 HomeVC
到其它项目的需求。
至于什么时候会有这样的问题,以及,这样的问题如果解决,在 iOS组件化方案调研 这篇中,已经做过简单的讨论,这篇主要是选取了我个人较偏向的 Target-Action
这套方案,简单讲一下实现方式。
二、Target-Action 实现页面跳转
采用的是 CTMediator
这套方案
Demo地址
还是假设我们有个页面叫 NewsViewController
, 当前页面为HomeViewController
那么,我们按照CTMediator
设计的架构来写一遍这个流程
1.创建Target-Action
创建一个 Target_News
类,在这个文件里,我们主要生成 NewsViewController 实例并为其进行一些必要的赋值。例如:
1 | // Target_News.h |
这个类需要直接 #import "NewsViewController.h"
1 | // Target_News.m |
2.创建 CTMediator 的Category.
CTMediator+NewsActions.这个Category利用Runtime调用我们刚刚生成的Target_News。
由于利用了Runtime,导致我们完全不用#import刚刚生成的Target_News即可执行里面的方法,所以这一步,两个类是完全解耦的。也即是说,我们在完全解耦的情况下获取到了我们需要的NewsViewController。例如:
1 | // CTMediator+NewsActions.h |
1 | // CTMediator+NewsActions.m |
3.最终使用
由于在Target中,传递值得方式采用了去Model化得方式,导致我们在整个过程中也没有#import任何Model。所以,我们的每个类都与Model解耦。
1 | // HomeViewController.m |
4.不足
这里其实唯一的问题就是,Target_Action里不得不填入一些 Hard Code,就是对创建的VC的赋值语句。不过这也是为了达到最大限度的解耦和灵活度而做的权衡。
1 | // 1. kCTMediatorTarget_News字符串 是 Target_xxx.h 中的 xxx 部分 |
注:这篇写的较早。作者前段时间也亲自写了篇教程:在现有工程中实施基于CTMediator的组件化方案 比这篇详尽,各位还是移步原 po 的教程吧……