Android 項目開發 基於Web Service 服務的中英翻譯軟體（四）

羅嗦

　　從Android手機誕生並且大踏步的邁向商業領域的開始，就吸引了無數智能終端發燒友與開發人員，博主就是這個群體中的成員之一（雖然還很菜，但卻一直保持著這份熱情）。就像博主一樣，能擁有一台屬於自己的愛機是多麼幸福的一件事情（公司的不算）~，於是乎經過了2個星期的“市場調研”，決定勇闖中關村！經過幾番周折終於拿到了自己心儀的機子，並且第一時間開通了3G業務，相信所有拿到智能機的朋友第一件事情就是要安裝上幾款NB且酷的軟體。一來是慶賀自己終於趕上了科技的步伐，二來也要看一下這無線網路的上網功能，那麼隨之而來的“煩惱”也就出現了。就博主來說，博主辦的3G業務每月有300M的流量可以使用，超出要另外算錢。大家都知道，因為無線上網與PC上網的付費方式是不同的，PC網包年、包月也好，都是不計流量的，而無線就不同了。雖然安裝了一些主流的流量統計軟體即時監控自己的流量支出，但這個心裡還是不放心，總覺的某些軟體的某些操作是不是“必要”的，是不是某些軟體為了賺取流量或者點擊率而沒有為使用者節省開銷呢？

從使用者的角度思考問題——如何減少使用者流量的開銷？

在設計這款軟體時，我就為“查詢”（翻譯，顯樣本句，顯示單詞本，語音等……）操作提供了兩種擷取資料的方案。

第一種方案：

　　訪問Web Service，因為是居於調用Web Service的軟體，訪問互連網是必不可少的，上面前言提到，訪問互連網的頻率與次數和流量支出有著重要的聯絡，同樣也會牽動消費者的神經與使用者體驗，所以在設計軟體的時候要加設一個“倉庫”（Sqlite），用來儲存使用者從互連網擷取到的資訊，當使用者下次訪問互連網時，首先訪問資料庫中有沒有相對應的資訊，如果有，那麼直接存取資料庫，如果沒有才會去訪問互連網，通過這種方式，無形中可以為使用者省去很多的流量開銷。

 

第二種方案：

　　此方案與第一種沒有任何衝突，他們是同時存在的。還是從使用者的角度去考慮問題。”查詢”操作可以翻譯單詞，顯示出翻譯過後的文字和音標（拼音），同時中英翻譯服務還提供了“例句”供開發人員使用，還有單詞的語音發音，還有中文的國際碼，偏旁部首，筆畫等。雖然提供的內容很豐富，但是這些都是使用者想要的嗎？首先看一下中英雙向翻譯服務為我們提供的文檔中對一個方法的描述：

　　這個名為Translator的方法，可厲害啦，為什麼這麼說，因為他是此服務提供的方法中的“鼻祖”，它返回了所有的資訊，比如我要翻譯work這個英文單詞，當使用Translator方法後，我會得到3個DataTable，DataTable0是關於word單詞的一些基本資料，比如音標，如果是中文會有國標碼，還有對word的翻譯，還有發音的Mp3檔案名稱，好吧，我承認DataTble0中這些資料可以說是必要的，但看一下DataTable1和DataTable2，相關詞條，例句，像這些“額外資訊”並不算是必要的，但卻是有需求的。把這些額外資訊提供顯示給使用者會讓他們覺得軟體的功能豐富，但只能作為後備。等使用者感興趣的時候再去顯示，這樣一來會為不感興趣的使用者節省了這部分“額外資料”所帶來的流量支出。那就不能直接使用Translator，通過查看文檔，發現中英翻譯服務還為大家提供了3個方法，他們將Transltor分解了：

　　TranslatorString：返回的內容與上面的DataTable0中的內容一直，是一個String[]

　　TranslatorReferString：相關詞條。

　　TranslatorSentenceString:例句。

　　當我點擊查詢按鈕時，我只會執行TranslatorString方法，並且將結果顯示同時執行儲存的資料庫操作，這個時候如果使用者想使用發音功能，才會執行GetMp3方法擷取byte[]，當使用者想查看例句，才會執行TranslatorSentenceString方法，並且將結果顯示同時執行儲存的資料庫操作，這樣“分開”訪問互連網，對流量的開銷得到了很好的控制，而不是一次全部將這些資訊擷取到，造成不必要的浪費。（中音標有亂碼，我會再後面講解亂碼的問題）

　　當我提到如何節省流量開銷，大家會以為我會為大家提供什麼好的技術，其實不是，我想說的是：多用心，多為使用者考慮才會做出好的軟體，技術只是工具，只是輔助。

　　下一篇：Sqlite使用中出現的一些“小問題”，和編碼

摘自：One Kid Sky