Android工具箱之組織你的代碼文件

這是一個系列，咱們將其命名爲工具箱，若是你尚未看以前的文章：

Android工具箱之Context解析

Android工具箱之文件目錄

Android工具箱之理解app資源文件

Android工具箱之Activity生命週期

Android工具箱之遷移到AppCompat

Android工具箱之Android 6.0權限管理

概覽

Android應用須要有良好的包結構定義，這會使得你的代碼更易被閱讀，一般來講，恰當的命名規範可以保證你的代碼更易被維護和整潔。

命名規範

針對Java代碼

下列規則對於Java代碼很重要：

• 變量 規範：全部變量都必須爲小寫字母開始，且駝峯式。例如：incomeTaxRate

• 常量 規範：因此常量都必須爲大寫字母。例如：DAYS_IN_WEEK

• 方法 規範：全部變量都必須爲小寫字母開始，且駝峯式。例如：convertToEuroDollars

• 方法參數 規範：全部參數必須小寫字母開始，且駝峯式。例如：depositAmount

針對Android類

Android類的命名規則有其本身的一套規範，以使得其類做用更加明顯。好比全部的activity都會以activity結尾。

• Activity 規範：CreateTodoItemActivity。繼承於：AppCompatActivity，Activity。

• List Adapter 規範：TodoItemsAdapter。繼承於：BaseAdapter，ArrayAdapter。

• 數據庫幫助類 規範：TodoItemsDbHelper。繼承於：SQLiteOpenHelper。

• 網絡客戶端 規範：TodoItemsClient。

• Fragment 規範：TodoItemDetailFragment。繼承於：Fragment。

• Service 規範：FetchTodoItemService。繼承於：Service, IntentService。

你在命名Android類以前，最好思考下，目標是任何Android類都須要特殊定義的前綴。

包結構定義

包結構的定義分歧很大，可是基本維持在兩種模式：

按照種類分類

其含義爲：將app的每一個特性都應該區分開。

• com.example.myapp.activities - 包含全部的activity類

• com.example.myapp.adapters - 包含全部的adapter類

• com.example.myapp.models - 包含全部的數據模型

• com.example.myapp.network - 包含全部的網絡代碼

• com.example.myapp.fragments - 包含全部的碎片

• com.example.myapp.utils - 包含全部的幫助類

• com.example.myapp.interfaces - 包含全部的接口

按照app應用特性區分

• com.example.myapp.service.* - 包含全部的後臺服務類

• com.example.myapp.ui.* - 包含全部的UI相關類

• com.example.myapp.ui.mainscreen - 包含全部的主屏幕相關類

• com.example.myapp.ui.detailsscreen - 包含全部的其餘屏幕相關類

這必定義，可讓你將DetailsActivity, DetailsFragment, DetailsListAdapter, DetailsItemModel放在一個包中。

DetailsListAdapter和DetailsItemModel類能夠將其屬性定義爲protected，這樣其餘包中的代碼須要經過get/set訪問屬性。

這使得建立實例更加簡單和直觀，由於對象在包外是不可改變的。

結論

這兩種模式均可以，取決於哪個更加適合你的項目，然而，一般在Java代碼中，第二種模式即按照特性劃分更加有利和被推薦。

參考

• http://blog.smartlogic.io/2013/07/09/organizing-your-android-development-code-structure

• http://stackoverflow.com/questions/5525872/android-project-package-structure

• http://www.javapractices.com/topic/TopicAction.do?Id=205