DownLoad模块 (四)

DownLoad模块 (四)

DownloadConfirmDialogPagerAdapter是为ViewPager所使用的PageAdapter，
直接extends自PagerAdapter<虽然使用该Adapter的ViewPager是在Fragment中，继承FragmentPagerAdapter更好，不过会紧耦合其使用场景
并且也不符合FragmentPagerAdapter适用的场合， FragmentPagerAdapter以及FragmentStatePagerAdapter还没有使用过>

<1> 该类将IndicatorView和PageView的生成都放在一个类PageProvider<因为会有多种Provider，所以该类只是一个接口,其职责是C>中，
合情合理，因为IndicatorView和PageView应该算是一个对象<下载存储方式>所有的属性。
方法有:
View createPageView();
View createIndicatorView();
String getTitle();
void onDestroy();

<2> 每种具体的 下载存储方式 都对应一种provider, 并且每种 方式 都会自己的扩展C功能。

<3> 本地存储的provider 是 localProvider, localProvider会检测本地下载目录的设置<视为M>变化，如果有setting变化，会将其反应
到V<就是create出来的view>上<通过eventBus实现listen，构造时就listen, onDestory时停止Listen>.
localProvider会维护其所提供的View上的所有子View的引用，在合适时候去修改刷新View的显示.
遵循惯例，localProvider也会直接implements一些Listener类接口作为一些子View的回调C。

<4> localProvider的getIndicatorView()可能会调用多次，因此cache起来，内部保存一个到IndicatorView的引用。

<5> LocalProvider实现了onClickListener这个C, 处理create的View的click事件，在用户点击了确定下载以后，
要将包裹Viewpager的Fragment关闭，可以通过两种方式实现:
(1)内部直接保存一个指向该Fragment的引用，然后将其从FragmentManager中pop出去
(2)发出一个event，Fragment来响应。
本质都一样。
LocalProvider构造时还接受一个外部的Listener对象，该Listener在点击了开始下载时会被调用，可以没有，作为对外的一个开放回调。
一个case是在用户点击开始下载时，界面停留在编辑下载文件名的状态，这种状态下，要将EditText的Focus清除，并且要将VKB隐藏<专门有工具类实现>。常规的文件名检查也是需要的，并以toast告知错误情况<专门工具类封装>.

<6> LocalProvider中点击下载路径会触发FolderBrowser<会将当前所在的文件路径作为构造参数>，最终选择好的新的下载路径会存在一个静态类中作为全局存储，实现Fragment之间的信息交互。

<7> LocalProvider点击了开始下载以后会触发一个下载的动画。动画的执行会在同一个线程<下一个slice开始>，要将可点击的所有View都setEnabled(false)，虽然时间很短，不过需要.

<8> LocalProvider还承担了OnFocusChange的C职责，如果文件名EditText获取了Focus，那么就自动选中下载文件扩展名之前的所有内容.

<9> LocalProvider还负责了显示要在的文件的大小<构造confirmDialog时就传入了，<=0的情况是有可能的，显示为 未知>以及可用的空间<storgae>, 通过StatFs类来得到。

<10> LocalProvider还通过实现OnEditorActionListener并return true 来截获了对EditText的key操作，有key操作，消除Focus并隐藏VKB.

<11> RemoteProvider提供了 网盘存储方式的 View, 琐碎的UI部分实现和LocalProvider基本一致，不过考虑到扩展性，并没有将这些琐碎冗余移到base class中。

<12> RemoteProvider的存储路径是不可修改写死的，比LocalProvider要简单,因此也不用监听下载存储位置setting的变化。

<13> RemoteProvider的下载文件名操作与LocalProvider一致.

<14> 对于storage的显示，如果当前已经登录的网盘，才会显示出剩余空间的大小。会有一个专门的manager类(C)负责和网盘进行交互，并及时的
回调更新V。

<15> Provider实现类的代码都是琐碎而繁多的更新UI，Provider自己处理了自己产生的View的所有交互，设计时认为Provider和其提供的
View是一对一，Provider是该View的 C, 而Provider本身又包含<或者构造时传入>了 M(就是View上显示的内容).

<16> PagerAdapter类本身只是实现了自己应该实现的几个函数:
内部维护一个Provider对象的数组(算是M吧)，目前每个provider类仅有一个对象实例在数组中。
(1) getPageTitle:通过调用相应的provider的getTitle
(2) getCount: Provider数组长度.
(3) instantiateItem: 调用与传入的position对应的Provider对象来得到相应的View，然后add到ViewPager中，
直接使用该View对象作为返回的Object对象。
(4) destroyItem: 直接从ViewPager中移除View<记住要对传入的Object对象做强制类型转换>
(5) isViewFromObject:因为instantiateItem中直接返回了View对象作为Object，因此直接判断传入的Object对象是否就是View对象<常规都是这么做>.
(6) 对外开放获取provider的接口，在某些情况下可以被用到.
(7) 还可以根据提供的Page的位置编号来判断是 本地存储 还是 网盘存储 page<这一部分的判断逻辑直接hardcode为具体数字了，不好，造成了和其他顺序的紧耦合，至少应该将这些具体数字开放出来，用符号代替>。

<17> PagerAdapter类中的Provider设计是一个工厂模式， 而开放的Provider接口和内部封闭的具体实现类又有着策略模式的影子。

<18> Provider的两个具体实现类中的冗余重复实现是可以通过拆分出通用函数来化解的，不过涉及到细节，可能最后code的复杂度会上升，通用函数也会增加这两个类的耦合。