DownLoad模块 (五)

DownLoad模块 (五)

DownloadItemView代表DownloadFragment上每一个Download对应的View，展示该Download的进度，状态，名称等信息。
设计为base abstarct class。
DownloadItemView直接extends LinearLayout, 又承担一部分的C，实现<其实是其非abstarct子类实现>了onClickListener和 onLongClickListener.

<1> DownloadItemView内会维护一个Download(M)的引用，这是必须的，两者天然联系, 互相影响， 不过可以是空.

<2> DownloadItemView 有两种状态，Normal和InEdit,状态切换由外部出发，并且会更新相应子View

<3> DownloadItemView 内含很多View， view的是否可见根据 当前状态决定。

<4> 在构造DownloadItemView时，就会通过layoutInflater.inflate(layout<此layout的root是relativeLayout>, this, true)来将inflate出来的View直接加入到该DownloadItemView<LinearLayout>中.然后就是找到内部各个子view的引用并保存，为以后更新V。

<5> DownloadItemView被设计为 可以set DownLoad, DownloadItemView可以不一直绑定一个Download，可以通过setter来换，
在更换了Download以后，要更新相关的View<典型的M 通过 C 影响 V>

<6> override了setSelected方法<在InEdit模式下>，更新某些V.<外部操作 通过 C 影响 V>
同样相对的override了isSelected()。

<7> 一个重要的抽象方法 updateByStatus(), 不同的子View可以选择自己的update View的方式，基类只是将相关的子View引用以及M相关
信息的获取实现，至于大部分如何更新View的逻辑<C>，则交给了子View来实现。

<8>通过Download中的信息<M>来获取Icon更新ItemView上的ImageView<V> (M -> V)

<9>该abstract class 实现的一个操作V的方法是 设置当前的 progress状态<这一部分逻辑是通用的，因此放在基类中>，该函数也是琐碎的一堆View状态设置逻辑.

<10> trivial:
(1) DownloadItemView的一个浪费在于它多套了一层LInearLayout，在构造时，inflate出来的view理论上将已经足够，但是有被add到了extends自LinearLayout的DownloadItemView中，多了一层LInearLayout，不得不这么做的原因是，DownloadItemView是不断动态生成的，
虽然inflate可动态的生成View，但是也只能生成一个View，这个特有的view的一些逻辑不可能封装在layout的xml文件里面，因此只能通过
这种多套一层的方式将 逻辑封装 和 灵活生成 同时实现. 还是可以接受的, 而这也是android 提倡Fragment的一个原因，但是显然，我们在
这里使用Fragment是不合适的。
还有一种办法： 这个类的逻辑和实现保持不变，只不过要做一个新的layout xml文件，其rootView就是该view，然后直接包裹各种子view<不要使用include，否则还是多一层>。但是这样做的话，就要求DownloadItemView必须是一个可以实例化的类，而其扩展子类也要定义layout xml，根本不能满足这里的需求。