體能評定軟件開發總結

1、基本狀況

（一）出發點

最新體能考覈大綱已經出臺，有評定手冊，須要翻閱查找，很不方便，並且此手冊通常人都見不到，如何讓你們可以對本身的體能水平有所瞭解？如何讓你們掌握自身體能素質水平？如何讓你們查找自身體能短板？如何讓你們提升成績？這一系列的思考，催生出了我製做本軟件的想法。

（二）構想

採用文件查詢的方式，對於輸入的體能結果進行查詢，並返回分數，作出評判。

2、具體實現

主要是三個界面兩個類的實現以及數據文件的存儲。如圖：

（一）主界面

其界面以下圖所示：

主界面的設計沒有什麼技術含量，能提一提的就是SPINNER及其ADAPTER與LISTENER了，經過偵聽來實現更換TEXTVIEW內容。而後是清除和肯定按鈕的LISTENER的實現了。由於TEXTVIEW會變，因此每個EDITTEXT裏的成績在不一樣SPINNER狀態下表明不一樣含義，具備多態性。在算分數時，我經過傳遞參數的改變實現了不一樣科目的計算。

（二）幫助界面

其界面以下：

幫助界面在用戶首次使用時會彈出，點擊之後再也不提示後每次啓動都不會再彈出，固然在菜單裏面仍能把它找回來。 主要是WEBVIEW控件，提早用HTML寫好文件放入assets/，WEBVIEW本地讀取就可以很好的顯示了。
須要重點提的是：如何實現首次開啓提醒？我在MainActivity裏面新建了一個Intent，經過在SharedPreferences查詢標誌位是否爲TRUE來決定是否在MainActivity中啓動HelpActivity。若是點擊了之後再也不顯示，則把這個標誌位變成false值寫進SharedPreferences。最後是它的顯示主題，我採用繼承dialog的方式。

（三）關於界面

如圖：

設計很簡單，只提一提反饋按鈕。它的功能是給我發郵件。只須要一個Intent類就能夠，主要是請求Android的郵件服務，在網上能夠查到方法，因此說java很強大。

（四）自定義Calculator類

它的功能就是傳遞一個通過原始數據給它，而後去/res/raw下查詢對應項目的分數標準而後返回。也是同樣把傳遞過來的參數轉換一下就可以去提早定義好的文件ID數組取相應的文件地址而後讀取相應的數據，這樣用「地址數組」就解決了多態的問題。

（五）自定義UnoData類

它是把原始數據轉換成對應文件中相同進制數據的類。好比我輸入的原始數據是11：20，它既能夠表明11分20秒，也能夠表明11秒20，一個是60進制，一個是100進制。這在內插時對於成績有影響，因此對於不一樣項目，我會選擇讓原始數據轉換成不一樣進制的數。

3、好的方面

（一）定義常量數組，對文件地址的查詢就轉化爲對數組的查詢，實現了一個語句的多態性，壓縮了代碼量。
（二）統一了數據格式。一樣是減小了代碼量，不用根據不一樣項目去寫相應的處理函數（但也正是這個緣由，致使了不一樣項目耦合性增長，影響了編寫速度，增長了複雜性）。

4、不足之處

（一）耦合性過大。正如上文所說，代碼量和耦合性不可兼得，代碼量小了勢必會增長各類各樣的標誌位，致使代碼難以讀懂。我應該針對不一樣項目編寫不一樣的類，每一個類裏面編寫相應的處理函數，最後再抽象出一個接口來實現多態，代碼量大點，但結構簡單，容錯性好。
（二）文件存儲方式很差。具體體如今我是按照項目內容對文件做以命名的，這就致使了一我的考覈多項課目就須要對多個文件進行讀取，每次都是讀取其中的一小段，而文件讀取操做是個耗時操做。其實，若是一開始考慮到這種問題，我就會按年齡、性別對文件做以命名了，這樣只用經過一個文件就能把全部課目成績都算出來了。這樣的時間效率是可觀的。

5、體會

• 每一次編程都是一次學習的過程，由於有了新想法，因此須要不停地去學習、實現，編程的迭代模型在個人一次次實踐中，體會愈來愈深入。因此咱們編程須要耐心和毅力，由於一次次的修改都是對前期的批判，但只有批判才能更好，若是沒有一顆追求更好的心，那會是一種煎熬。

• 編程重點不是代碼，而是其背後的思想，這包括頂層設計、數據結構、設計模式等等。

  鳴謝：感謝每個支持個人朋友！