撸了个生成操作 Shared Preference 的代码生成器。方便生成配置,解放懒人!

2016-06-29 09:13:06 +08:00
 holmesabc

其实主要就是因为懒,不想每次为了一条配置,写一堆, get/set 接口,注释, key 的常量。 现在直接生成代码,一条配置也就一行代码搞定。还方便以后配置项的管理。

基本用法

建一个 java 的 gradle 项目后,加入依赖,

compile 'z.hol.spgen:sp-gen:1.0.1'

编写相应的规则,执行 gradle :run, 即可。

具体说明,可见 https://github.com/holmeszyx/sp-gen

9941 次点击
所在节点    Android
13 条回复
cedared
2016-06-29 09:24:49 +08:00
虽然不知道是什么 但是好厉害的样子
hinkal
2016-06-29 12:09:46 +08:00
个人觉得你没有理解 get/set 的用意吧。 Shared Preference 的 get , set 可以通过封装,带有一些别的操作啊。譬如可以自己做个配置缓存
String settings1;
getSettings(){
return settings1==null?PreferenceManager.getDefaultSharedPreferences(context).getString("settings1", null):;
}
setSettings1(String settings1){
PreferenceManager.getDefaultSharedPreferences(context).editor().putString("settings1",this.settings1=settings1);
}
这不是面向对象思想吗。而楼主这个库,则是方便程序员使用面向结构的思想调用 Shared Preference 。所以我觉得是楼主思想觉悟不够...
fashioncj
2016-06-29 12:25:26 +08:00
让我想起了 greendao
29995270
2016-06-29 12:27:04 +08:00
@hinkal 我倒觉得这 类似 ORM 的思想很好,类似 Fragment 的 getArgument , activity 的 intent 参数 ,都有类似楼主这种库,真看不出来跟思想觉悟有什么关系
hinkal
2016-06-29 12:33:17 +08:00
@29995270 并不觉得这和 orm 可以类比, hibernate 可以直接免去 sql 操作,表面是避免了了两种语言操作纠缠不清的麻烦,实则是让所有操作都面向对象。
hinkal
2016-06-29 12:40:18 +08:00
@29995270 事实上真的说起来 Shared Preference 本身自己的思想就是通过 xml 配置文件来进行操作的,这个 xml 文件时安卓系统生成的。楼主的库等于是生成该系统 xml 配置文件的配置文件,没有必要搞这么多层。譬如,你可以直接写这样一个库:程序员直接自己手动编写 SharedPreference.xml 文件,程序安装时直接把该文件拷贝到安卓程序根目录 Shared Preference 文件夹。这样不就和楼主的库一样的效果了吗。
Bown
2016-06-29 12:54:25 +08:00
最近喜欢用 @StringDef 处理 sp ,加入新的 key 依旧极简配置
hinkal
2016-06-29 13:30:32 +08:00
如图 http://image.prntscr.com/image/96f8cd0dcee44a4ebfa8fca9cabe221b.png
觉得楼主的库处在一个尴尬的位置。如果觉得 sharePreference 不好用,楼主应该直接对 sharePreference.xml 进行操作,重新继承 android.content.SharedPreferences 并新增方法。
holmesabc
2016-06-29 14:09:51 +08:00
@cedared
就是你应用里面那些什么设置啊,减少手打大量的重复代码。
还有一些其它的需要持久化的小东西,
比如你加了个需求,要多长时间找服务器更新一下,或者一个页只显示多次啊,我是不是要在本地记录一下这些时间点和次数什么的,这此用代码生成就不用为了这些小东西,又要写那多代码来了。
holmesabc
2016-06-29 14:10:11 +08:00
@fashioncj 就是 GreenDao 。
holmesabc
2016-06-29 14:38:33 +08:00
@hinkal

代码生成工具,最大的做用就是减小人工手写的工作量,附带的好处就是减小人为出错,方便管理。
所一般只会面向最原始最基本的需求进行封装。

这个工具其实就是对 SharePreference 最原始包了一层。
SharePreference 没有什么不好用的,它提供的就是个最基本的接口,有这个就足够了。

至于 get/set, 这个东西,代码生成只能根据一定的规范。实际中,极大部分情况下,数据 A <--> sp.put(A),
当然也有小部分 A <--> [B <--> sp.put(B)], 当这种使用极小,估计 10%不到。

对于这些输入与输出的结果要做映射的,我一般都是再单独处理。比如配合 Rx,做读与写 Observable 或 map 或 action 。
这样的话,想用 sp 输出的原始数据也行,不想用,就去掉 rx 调用的那行 map 都 ok 。


您所说的缓存那个例子,单纯例子来说, sp 本来自带缓存,不会老去 io 。如果没有其它的例子,可以考虑一下我说的这个处理 带映射中间层 的玩法,我感觉这个比缓存来说,应该能更好的表达你要说的问题。


最后,对于代码生成来说,很多接口只是个约定,不可能多智能,要不就真有 BetaCat 了,不然 protobuf, thrift 这些里面的 get/set 都思想不对喽,但 google 和 facebook 肯定不会烂写是吧。
cedared
2016-06-29 15:03:02 +08:00
@holmesabc 哦 哦 懂了
hinkal
2016-06-29 15:25:35 +08:00
嗯,理解你的需求了,觉得重写 sharedpreference 太麻烦(?)。还有我的举例的确不当。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/289013

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX