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

[holmesabc]

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

基本用法

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

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

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

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

[cedared]

虽然不知道是什么 但是好厉害的样子

[hinkal]

个人觉得你没有理解 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]

让我想起了 greendao

[29995270]

@hinkal 我倒觉得这 类似 ORM 的思想很好，类似 Fragment 的 getArgument ， activity 的 intent 参数 ，都有类似楼主这种库，真看不出来跟思想觉悟有什么关系

[hinkal]

@29995270 并不觉得这和 orm 可以类比， hibernate 可以直接免去 sql 操作，表面是避免了了两种语言操作纠缠不清的麻烦，实则是让所有操作都面向对象。

[hinkal]

@29995270 事实上真的说起来 Shared Preference 本身自己的思想就是通过 xml 配置文件来进行操作的，这个 xml 文件时安卓系统生成的。楼主的库等于是生成该系统 xml 配置文件的配置文件，没有必要搞这么多层。譬如，你可以直接写这样一个库：程序员直接自己手动编写 SharedPreference.xml 文件，程序安装时直接把该文件拷贝到安卓程序根目录 Shared Preference 文件夹。这样不就和楼主的库一样的效果了吗。

[Bown]

最近喜欢用 @StringDef 处理 sp ，加入新的 key 依旧极简配置

[hinkal]

如图 http://image.prntscr.com/image/96f8cd0dcee44a4ebfa8fca9cabe221b.png
觉得楼主的库处在一个尴尬的位置。如果觉得 sharePreference 不好用，楼主应该直接对 sharePreference.xml 进行操作，重新继承 android.content.SharedPreferences 并新增方法。

[holmesabc]

@cedared
就是你应用里面那些什么设置啊，减少手打大量的重复代码。
还有一些其它的需要持久化的小东西，
比如你加了个需求，要多长时间找服务器更新一下，或者一个页只显示多次啊，我是不是要在本地记录一下这些时间点和次数什么的，这此用代码生成就不用为了这些小东西，又要写那多代码来了。

[holmesabc]

@fashioncj 就是 GreenDao 。

[holmesabc]

@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]

@holmesabc 哦 哦 懂了

[hinkal]

嗯，理解你的需求了，觉得重写 sharedpreference 太麻烦(？)。还有我的举例的确不当。