转载地址:http://chirs1012f.iteye.com/blog/939322
一、Tab初印象
看图中画的框和椭圆,并对照着右边的文字说明,尽量看懂图中的包含关系。二、Tab相关类的介绍及它们之间的关系
在这一小节里,继续以图解的方式针对上一节中描述的包含关系和Tab构建过程进行阐述。
1.TabActivity
2.TabHost
3.TabHost.TabSpec
TabSpec主要负责去生成所需要添加进TabWidget和FrameLayout 布局当中的View,但是TabSpec不会直接与它们两个进行协作,而是只与TobHost来完成这一组装过程。按我的理解这个像是一个MVC模型,TabHost是控制器,TabSpec是模型,TabWidget和FrameLayout是视图展示层。
下面两幅图是组装的过程展示,整体过程均在TabHost.addTab()完成。
组装Indicator
组装Content
三、剖析Tab控件的源码实现
1.TabHost
在第二节提到过一个方法setup (LocalActivityManager), 按照API文档上所说,仅在以Intent方式构建TabSpec时,才要显示调用这个方法,前提是你未继承TabActivity;换个简单的说法,继承了TabActivity,我们就不需要显式地调用这个方法。
其实在setup (LocalActivityManager)版本中调用了它的重载版本setup(),也就是说真正的初始化工作是由setup来完成的。
两者有个共特点就是一般都不会显示的调用它们,当它们不是以getTabHost()方式来创建的或者说就根本没继承TabActivity的话,则需要显示调用。比如下面的代码示例:
- TabHost mTabHost = (TabHost)findViewById(R.id.tabhost);
- mTabHost.setup();//或者setup (getLocalActivityManager());
- mTabHost.addTab(…);
造成这种繁琐细节的主要原因是在于继承与不继承TabActivity。那么TabActivity已经为我们完成了这么的繁琐工作,那我们为什么不领这个情呢?
2.TabHost.TabSpec
在第二节中提到了TabHost.TabSpec的用途,就是用来构建View的,并只与TabHost打交道。它负责构建两种View,一个是indicator view,另一个则是content view。观其源码,很容易地看出来针对这两种View,都采用了策略模式。
从实际用途的角度来考虑,创建Tab控件有共三种方式,这三种方式就对应着content view的三种策略,那么就先介绍它吧。
- //TabHost.TabSpec 部分源码
- //content view 构建策略引用
- private ContentStrategy mContentStrategy;
- //通过资源ID构建View
- public TabSpec setContent(int viewId) {
- //该策略直截了当地调用findViewById()方法返回指定的视图
- mContentStrategy = new ViewIdContentStrategy(viewId);
- return this;
- }
- //通过资源Intent构建View
- public TabSpec setContent(Intent intent) {
- //该策略LocalActivityManager.startActivity(String tabName, Intent intent)方法返回的Window,并通过Window的getDecorView() 返回最终的视图。
- mContentStrategy = new IntentContentStrategy(mTag, intent);
- return this;
- }
- //通过资源TabContentFactory构建View,它可以让你自由定制View
- public TabSpec setContent(TabContentFactory contentFactory) {
- // FactoryContentStrategy,其内部维护着一个TabContentFactory引用,并调用createTabContent(tagName)方法返回定制化的视图。
- // 这个地方淋漓尽致地诠释了那句耳熟能详的名言,“将具体实现延迟到子类”,现在已经深有感触了。
- // 就拿这个例子来说,一开始不要想模式,先根据业务需求来考虑,这个content view会跟根据indicator而变化,所以要做一些if else的处理;为了考虑代码的可维护性和健壮性,代码写的一定要优雅,慢慢地慢慢地就重构成非常满意的效果了,一看,嘿!这不是工厂模式么。
- // 还有另外一种思考方式:当具备了一定的编码经验和设计经验之后,遇到该做活的地方一定要有一个意识,就好比提取出一个方法,我往这个方法传递各种参数已达到灵活的目的,慢慢地培养这种意识,代码就会越写越舒服了。
- mContentStrategy = new FactoryContentStrategy(mTag, contentFactory);
- return this;
- }
我不得不感叹TabHost.TabSpec中的策略模式设计得如此巧妙,仅仅通过重载方法就能够自由切换不同策略来构建View,继续往下看,我们回到TabHost. setCurrentTab(int index) 方法上,
- // 仅用一行代码就获取了content view,非常优雅。
- // mCurrentView是TabHost的成员变量,意指当前的content view。
- // spec是通过index获取到的TabHost.Tabspec。
- // mContentStrategy就是上面看到的策略接口引用。
- // spec.mContentStrategy内部类的特性。
- mCurrentView = spec.mContentStrategy.getContentView();
接下来我们看下indicator策略,如下:
- //TabHost.TabSpec 部分源码
- //indicator view 构建策略引用
- private IndicatorStrategy mIndicatorStrategy;
- //设置了indicator名,直接调用了TextView.setText()
- public TabSpec setIndicator(CharSequence label) {
- mIndicatorStrategy = new LabelIndicatorStrategy(label);
- return this;
- }
- //设置了indicator名和indicator图片,直接调用了TextView.setText()和ImageView. setImageDrawable(),图片是icon类型的。
- public TabSpec setIndicator(CharSequence label, Drawable icon) {
- mIndicatorStrategy = new LabelAndIconIndicatorStrategy(label, icon);
- return this;
- }
- //设置定制化的indicator view,API没有明确说明个方法,而只提到了上面的两个策略,不过定制view的思想还是值得提倡的。
- public TabSpec setIndicator(View view) {
- mIndicatorStrategy = new ViewIndicatorStrategy(view);
- return this;
- }
通过观察,indicator view策略与content view策略如出一辙,但后者更为实用一些。
我们回到TabHost.addTab()方法上,
- //也是仅用一行代码完成了获取indicator view的操作。
- //由此看出来,学习设计模式固然重要,但写出优雅的代码势在必行!
- View tabIndicator = tabSpec.mIndicatorStrategy.createIndicatorView();