HarmonyOS鸿蒙Next中关于对文件管理的选择器模块归类的建议
HarmonyOS鸿蒙Next中关于对文件管理的选择器模块归类的建议 目前API-9版本把文件管理中的选择器模块分为三类：PhotoViewPicker、DocumentViewPicker、AudioViewPicker。视频归类在PhotoViewPicker模块中，在使用中可能有些不便之处。例如，在一个音视频播放器设计中，如果利用AvPlayer，那么用户可能是播放音频，也可能是播放视频，而应用要求用户必须首先确定是打开音频还是视频，以便拉起PhotoViewPicker或AudioViewPicker界面。另外，播放视频时也可能要同时打开视频和外挂字幕文件，现行版本必须分别打开PhotoViewPicker和DocumentViewPicker，拉起两个不同的界面。
建议两种改进方法。（1）把音频和视频合在一起，作为如MediaViewPicker模块，以便与AvPlayer功能一致，选项中除了音频和视频外，还包括字幕类型选项（如.srt和.vtt等），这样便于在一个拉起界面中让用户同时选择视频和字幕文件。（2）把现有三个模块合并为一个模块，采用微软文件浏览器那样的方法增加一个文件类型选项，允许用户指定类型，默认为“所有”。
本人刚开始从Windows UWP开发转向鸿蒙系统开发，熟悉HarmonyOS参考能力，考虑不可能周到，请见谅。
更多关于HarmonyOS鸿蒙Next中关于对文件管理的选择器模块归类的建议的实战教程也可以访问 https://www.itying.com/category-93-b0.html
社区跟僵尸社区差不多
更多关于HarmonyOS鸿蒙Next中关于对文件管理的选择器模块归类的建议的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
追述：
笔者更倾向于上述建议改进的第二种方法。现有的三个模块，看似以用户为本，方便用户选择文件，实则束缚了用户的手脚。正如笔者在前文提到的，播放视频和显示外挂字幕，用户必须分两次选择。播放音频同样可能同时显示字幕（如播放Audiobook及其脚本）或歌词。应用场景是不断发展的，谁能预测某一天又有新的应用需要同时打开不同类型的文件呢？要解决“后顾之忧”的最好方法，就是采用“开放式”的理念，即把自由留给用户，让用户去决定取舍。把目前的三模块设计这种“进步”，退回到经典的Windows所采用的文件浏览器方法，让用户决定picker类型或显示所有类型文件。
另外，选择器还应该允许选择文件夹，而非仅仅文件。这同样有应用场景（笔者在多个Windows UWP应用开发中就使用）。
HarmonyOS从API8的分立的AudioPlayer和VideoPlayer，演进到API9合并的AVPlayer，把共性问题进行归并，这是一大进步，希望把这种进步理念也能用到文件管理的Picker的设计上。
诚然，现今的AVPlayer提供的功能，比起iOS、Android和Windows开发平台的支持还远远不够。以笔者之见，短期内需要增加的，或许是增加一个PlayerSession类，并允许封装进AVPlayer中的音视频源和TimedData（字幕）。建议参考Windows API的设计思路，提供给开发者的接口灵活而使用方便。
在HarmonyOS鸿蒙Next中，文件管理选择器模块的归类应基于其功能和使用场景进行划分。该模块主要用于用户选择和管理文件，涉及文件浏览、筛选、排序等操作。根据鸿蒙系统的架构设计，文件管理选择器模块可归类为“系统服务”或“应用框架”中的“文件管理”子模块。具体归类取决于其在系统中的定位和与其他模块的交互关系。若该模块主要服务于应用层，提供文件选择接口，则更适合归入“应用框架”；若其功能更偏向系统底层的文件操作和管理，则归入“系统服务”更为合适。
