首页 > UIScrollView里面嵌套UITableView这种结构是否合理?

UIScrollView里面嵌套UITableView这种结构是否合理?

类似网易新闻和lofter这种多标签滚动切换的效果,我以为是在scrollview上添加tableview来实现的, 但这样实现感觉会导致ViewController臃肿不堪, 实现delegate和datasource也比较混乱;想听听大家对于架构这种界面有什么样的建议,能提高代码的复用还有把代码剥离放到合适的地方;真的好想写出结构清晰美观的代码啊思密达!


每个标签对应的列表可以是一个viewController,它负责这个列表的内容和一切的交互。scrollView里装的是viewController.view。
scrollView所在的viewController可以称之为containerViewController,实际上起到了NavigationController之类的容器作用。而具体的内容,可以称之为contentViewController。
它的好处:

总的来说,这种结构可以称得上“清晰美观”,但也要看实现者的水准,做得不好反而会带来很多问题,做得好的。。。你看网易新闻多好用:)


首先你要知道,UITableView本来就从UIScrollView继承过来的。
所以你这样的思路一开始就不太正确噢。
系统可能会因为有两个UIScrollView而造成一些unexpected behaviors。

实现的话可以直接利用UIScrollView然后嵌套一个很多的画布。
又或者直接用UITableView。
具体的话要看需求咯。


uipageviewcontroller


我觉得你们反倒可以参考下Android上的viewpager组件的实现原理,和nsfish讲的很类似。


又遇到小鱼哥啦,不过这次咱俩想法是基本一致的。(基本。。

针对你的提问回复一下:

类似网易新闻和lofter这种多标签滚动切换的效果,我以为是在scrollview上添加tableview来实现的,

是的,确实一般都是这么实现的,ScrollView的ContentSize的宽度为TableView的宽度乘以数目,然后通过Page分页进行切换。

但这样实现感觉会导致ViewController臃肿不堪, 实现delegate和datasource也比较混乱;

不会臃肿的,我又要传送了。。。更轻量级的VC这个介绍了一些VC瘦身的方法,后面的文章讲了关于把DataSource和Delegate抽离的思路。这个控件是我们UI库的一部分,容器是ScrollView,然后控制器是一个director类,专门负责委托方法,比如tableview的datasource什么的,而且和数据层无缝衔接之后代码量很少的,对于单个cell的简单情况,可以直接用基类。不过每个人的想法不一样,实现的思路也不同,多个VC也是一个解决方案。

想听听大家对于架构这种界面有什么样的建议,能提高代码的复用还有把代码剥离放到合适的地方;

我觉得如果设计的好,代码复用不是问题。不过这种设计本身个人感觉不是iOS的Style。。。有种从安卓飘过来的感觉。个人想法。

真的好想写出结构清晰美观的代码啊思密达!
那就写吧!可以上github看看别人写的代码,好的代码带来的提升很快的~

然后 @LucasHuang 一下,UITableView本来就从UIScrollView继承这个没错,多个UIScrollView混用容易出问题也是没错,但是嵌套并不一定会矛盾,横滑切换tab,竖滑浏览内容。

个人观点,如有理解错误还望指正。


我上次做的这个别人是用pickviewcontroller实现的,原理我也不是很懂,但我觉得也可以用uicolltionview嵌套tableview这样的话创建的tableview始终只有两个,多余的都在内存池里面,cootionview大小就tableview大小,上部当时还有那种滑动的,我日现在想想上面也用个colltionview两个colltionview关联就蛮好

【热门文章】
【热门文章】