EhViewer
EhViewer copied to clipboard
seven332
新增加字典的功能
很抱歉，这么久才看到你的commit （很奇怪我的gmail跟在github上的notification都没有看到这些commit）
提出的关于加快导入的字典和修改字典格式的建议都很好，有时间加进去。
intent-filter的话还要在看一看，我开始的mimeType设成*/*也是不行的。
这次的提交将查询操作放到了后台处理（使用了AsyncTask），这样就不会卡Ui
还增加了关键词的查询方式 能更便利的搜索
（因为使用正则区分不了繁简体，所以会出现繁简体同在的情况）
有个疑问：我看到我的提交是meged状态，但pull下来的代码似乎看不到我的提交
我把之前的你的代码还有我做的一些修改放到 dict 分支了，我建议你基于 dict 分支上修改，这样的话合并起来就不会那么麻烦了。
我做的修改主要就是使用 fts 表，修改字典添加方法。
AsyncTask 在使用 fts 表后没必要了，因为已经足够快了。
关于 filter 的话，我不觉得根据手机当前语言来进行过滤有什么帮助。搜索支持语言也就是英语和日语，使用中文关键字执行搜索并不会产生预期的结果。那么使用手机当前语言进行过滤，只能让用户了解关键字的意思。 想要让用户和服务器都能了解所关键字的意思，就可能需要两种语言，所以可以修改搜索建议条目的布局，使其显示两行文字，一行是用户手机当前语言，一行是服务器所能识别的英语或者日语。点击后再搜索框内填充服务器所能识别的英语或者日语。
了解fts表之后感觉AsyncTask可以去掉，不过建议还是保留吧，数据库方面其实我不是很擅长，AsyncTask的做法其实是查询网络的做法，以后查询改为其他方式也可以轻松的移植过去。
filter的目的是为了实现关键字的补全查询，初步完成字典的查询后我发现记住一个角色或动漫全名很困难（特别是有不同的译名，而且使用的字很相近），所以想做一个补全的查询，通过记住少量关键字来查询对应的角色名。因为我数据库里面没有对语言做区分（主要因为实现起来比较简单，扩展性也好一点）所以有了filter这个东西。然后根据手机语言是因为EhViewer可能还有国外的用户（恩。。）所以用filter来做限制（不然他们查询出来的只有中文）
当然还考虑到字典可能有其他的语言，如韩语等，所以我感觉filter这个东西还是有必要的
我觉得还是要区分用户所能识别的关键字与服务器所能识别的关键字，两者同时显示。
如图：
这样就没必要弄 filter 来区分中文日文韩文阿拉伯文了。因为显示关键字的语言种类是依赖用户输入的，而用户输入的语言当然是用户能够识别的。
问题在于字典的格式并不是中英日一一对应的关系 一个关键词可能对应着两个阿拉伯文翻译，而且他们并没有主次关系 还有一个问题就是简体中文和繁体中文和日语会有些词重复，查询出来的结果可能会有好几种语言，像 香风智乃->香風智乃，都应该被展示出来的 当然这个问题也可以通过对字典格式做限制来解决
还有就是其实我们不关心服务器所能识别的关键字是什么啦，放在建议选项里占空间也没什么做用
字典的目的不就是让用户找到自己所需要的画廊吗？如果服务器不能识别这个关键字，那么这个关键字不能帮助用户找到自己所需要的画廊，这个关键字对 EhViewer 而言又有什么意义呢？ 这个关键字的作用只是让用户得知自己所要输入的关键字在其语言下的完整写法，这并不是字典的作用。
两种查询方式是并存的，点击完整的关键词后会去查询对应的阿拉伯文翻译 查询逻辑 关键词->完整关键词->罗马音翻译 虽然要点击两次，但逻辑比较清晰，实现也简单一点
我还是觉得不用针对语言进行筛选。 目前筛选的方式是选择设备当前语言，不过国内有些人把语言设为英文，对他们而言，中文的角色名称是要更熟悉一些的。当然可以把筛选方法改为用户自定义语言，但这又多了项设置。还有方法就是提供不同语言的字典，但这会让字典创建更加麻烦了。
对于某一关键字同时产生简体中文与繁体中文建议的问题，我想筛选也不太好解决，必须针对每个词条，分辨出简体中文建议或者繁体中文建议或者共有建议(两者完全相同)或者日语。当然如果使用不同语言的字典，这个问题也就直接解决了，而且查找也会更快。
总而言之，我还是倾向于我之前提出的方案。对于一个词条，有一个可供服务器识别的英文写法，以及一系列的其他语言写法。用户输入关键字后，在英文与其他语言中搜索，若匹配到英文，则直接显示英文，若匹配到其他语言，则同时显示英文与其他语言。用户点击建议后再搜索框填充英文写法。
简体中文与繁体中文的问题还是存在的，这样会让建议数量变多甚至翻倍。或许可以单独针对此问题进行筛选，当然这又引出很多其他问题，譬如如何确定到底保留简体中文还是繁体中文或者是不进行筛选，如何判断建议为简体中文还是繁体中文还是日语。