keeganlee对开发规范的一些心得体会
目录:
Android项目重构之路:架构篇
Android项目重构之路:界面篇
Android项目重构之路:实现篇
这几篇文章要设计完成的事: 开发一个电商app的部分功能, 实现登录以及获取优惠卷的功能.
http://keeganlee.me/post/android/20150619
Android项目重构之路:界面篇
变量的命名规范
举个id命名的例子，看到有些团队喜欢将一些控件缩写，比如TextView缩写为tv，ListView缩写为lv，这种缩写倒是挺简洁的，但是并不能一眼就能看出它是什么，对于不熟悉的人来说，谁知道tv和lv是什么啊，还不如用text和list更明确些。我喜欢的id命名结构为：控件范围功能，例如：edit_login_password，这是一个登录页的密码输入框。
id命名结构为：控件+范围+功能
文字大小的单位应该统一用sp，其他元素用dp。因为这两个单位是与设备分辨率无关的，能够解决在不同分辨率设备上显示效果不同的问题。
单位, 文字用sp， 其他元素用dp, 以保证和屏幕分辨率无关.
包和类的单一
有些人习惯将adapter写在Activity里，因为觉得这个adapter只在这个Activity里用到，没必要再把它独立出来。以前我也是这么干的，这么做了一段时间之后，觉得实在糟糕透了，重复的代码无法复用，界面上的一点小需求调整时，很多代码需要跟着调整。后来，进行了一番重构，将所有adapter独立了出来，并抽象出了一个adapter的基类
把Adapter作为内部类写在Activity中， 是不好的编码习惯.
包的组织
按照组件类型来分包，而不是按业务模块来分包。业务有可能会变，但组件类型是基本不变的。另外，新加入的开发人员，对业务不熟悉，但对组件是很清楚的，理解快，入手也快。
包的命名以组件做划分， 相对来说比较的清晰.
类和接口的命名
组件类的命名添加该组件的后缀，例如：Activity类命名添加Activity后缀，Fragment类命令添加Fragment后缀，适配器添加Adapter后缀，等等。实体类则可添加BO的后缀名称，工具类添加util后缀，接口的实现类添加Impl的后缀。接口的命名也一样，比如，我的项目中，接口层的接口后缀都带上了Api，核心层的接口后缀都带Action。
这里讲的类的命名规范， 有很好的实践指导意义. 接口类统一后缀Api, 接口的实现类统一后缀Impl.
资源文件的分类
strings.xml中
页面标题，命名格式为：title_{页面}
按钮文字，命名格式为：btn_{按钮事件}
对字符串资源的命名， 可以调整为: 业务名_控件名, 这样的形式.
<string name="menu_container_exit">退出</string>
http://keeganlee.me/post/android/20150629
Android项目重构之路:实现篇
这篇文章中值得借鉴的一点是: 对Activity, BaseAdapter等一些基础组件进行一定的封装， 减少项目中的重复多余代码.
KBaseAdapter<T> extends BaseAdapter {
/**
* 设置为新的数据，旧数据会被清空
*
* @param itemList
*/
public void setItems(List<T> itemList) {
this.itemList.clear();
this.itemList = itemList;
notifyDataSetChanged();
}
/**
* 清空数据
*/
public void clearItems() {
itemList.clear();
notifyDataSetChanged();
}
/**
* 在原有的数据上添加新数据
*
* @param itemList
*/
public void addItems(List<T> itemList) {
this.itemList.addAll(itemList);
notifyDataSetChanged();
}
@Override
abstract public View getView(int i, View view, ViewGroup viewGroup);
}
他对BaseAdapter进行了抽象， 在里面把设置数据， 追加数据， 清空数据等这样的通用操作进行了实现， 这样项目中每个具体的适配器类只要再实现各自的getView方法就可以了.
善于抽象基础类的想法， 很值得学习.
项目的开源地址:
https://github.com/keeganlee/kandroid
---DONE.------
