Open junixapp opened 5 years ago
封装时,是否能更多的使用kotlin特性,而不是仅仅是java的方法变种。例如使用kotlin的dsl、扩展属性、契约等待。 谢谢,以上是我的建议
例如SharedPref相关
,在我个人看来,封装的毫无意义。而且配置文件名只能用一个……很无语啊。
可以参考官方的KTX封装方法,采用DSL。
// 拿到任意名字的sp,
fun Context.getSP(spName: String = "shared_preferences", mode: Int = Context.MODE_PRIVATE): SharedPreferences =
getSharedPreferences(spName, mode)
// DSL扩展
@SuppressLint("ApplySharedPref")
inline fun SharedPreferences.edit(
commit: Boolean = false,
action: SharedPreferences.Editor.() -> Unit
) {
val editor = edit()
action(editor)
if (commit) {
editor.commit()
} else {
editor.apply()
}
}
使用方式(写入):
getSP().edit {
putBoolean("test", true)
putString("ok", "12")
......
}
直接使用kotlin的apply即可读取(读取):
getSP().apply {
getBoolean("test",false)
……
}
整个封装,只需要扩展2个方法,完全没必要再去自己封装putStringToSP ()
这种一堆方法,大大减少了无意义的方法数目,相对也更灵活。
@limuyang2 如果能够使用方便,会采用这些特性,但不会滥用。 上面的sp的建议不错,可以采纳下。 大括号那个不是DSL,只是lamda表达式。 契约还是实验性的哦。
@limuyang2
你的建议已采纳,在最新的0.0.14
版本重写了SharePref的使用,可以看看README。
权限请求建议增加
建议适配Androidx
建议适配Androidx
本身就是androidx实现
建议适配Androidx
权限这个没有必要重复添加了,可以直接使用AndroidUtilsCode的封装
okhttp 的封装 回调接口里onSuccess 直接返回response会不会好一点 有遇到需要解析header的需求
好像是引入了Umeng的一些库.是不是这个可以去掉
建议友盟的相关jar包依赖已gradle方式引入,而不是直接引入jar包。因为其它项目本身可以也引入友盟,例如我的项目中引入了友盟推送,也引入了com.umeng.umsdk:common,这样导致冲突不好解决,而如果AndroidKTX如果将com.umeng.umsdk:common以gradle方式引入,我这边能用 exclude group: 'com.umeng.umsdk', module: 'common'的方式排除该依赖
建议增加一个String判空扩展: fun String?.valid() : Boolean = this != null && !this.equals("null", true) && this.trim().isNotEmpty()
Android12里面 share包里面 有些activity需要android:exported="true"。并且umeng的可以做一个可选依赖
拍照上面建议加上水印,类似于水印相机那种
请描述您期望添加的功能,或者其他想法。如果有代码实例,则更好。我评估完毕后会加入到该库中。