構建無縫的Android程序

不要使你的數據丟失 腦海裡面要時刻保持這樣一種看法：android是一個移動的平台。這很明顯，但是你也要注意：任何Activity（例如有人給你打電話）在你運行自己Activity的時候都有可能會突然彈出來，這將會調用onSaveInstanceState() 和onPause()方法，很有可能你的進程會終止（kill）。 如果用戶正在編輯數據的時候，其他的Activity出現了，你的程序可能因為被終止而丟失一些數據。當然如果你事先保存了就不會丟失。Android的編程思路也是這樣做的：那些接受或編輯輸入的android程序應該重載onSaveInstanceState()方法，把程序的當前狀態保存下來。當第二次訪問該程序的時候，就會使數據復原。 一個使用這的經典例子就是郵件程序。如果用戶正在編輯一個信件，這個時候寧外一個Activity出現了，那麼程序應該自動的把當前郵件保存到草稿本中。 沒有人喜歡看你裸露的數據 你是不能穿著內褲在街上裸奔的，那麼你的數據也同樣是這樣。你的程序有些東西是可能被其他程序訪問的，那麼這樣做就不是很專業了。其他的程序很有可能看不懂那些暴露的原始數據，如果你可以改變數據形式，你的程序就會在這點上比那些不會升級的程序好得多。 android的處理方法是：創建一個ContentProvider通過一個干淨的深思熟慮的可維護的API把你的程序數據暴露給其他應用程序。使用一個ContentProvider就好象嵌入了一個Java的接口到兩片代碼之間，讓它們能夠相互交流。這意味著，你可以改變你內部的形式而不用修改ContentProvider暴露的接口，並且這不會影響應用程序的執行。. 不要打斷正在說話的用戶 如果你的用戶正在運行一個程序（例如正在打電話），他肯定不要其他程序干擾。除了需要從當前Activity獲得用戶輸入的Activity外，這就是為什麼你應該避免纏身不恰當的Activity。 這就是說，不要從運行在後台的BroadcastReceivers或 Services中調用startActivity() ，這樣做會打斷任何當前運行的應用程序，就會使用戶很不舒服。或許更糟糕的，你的Activity變成了一個“鍵盤強盜”，它會把一些用戶原本准備給前一個Activity的輸入截取過來。取決於你的應用程序做了些什麼，反正這一般都不是一個好事情。 我們這裡沒有直接從後台運行Activity，而是使用NotificationManager去設置通告消息。這將會在狀態欄中顯示，用戶有空時就會在能夠點擊它，看看程序要什麼什麼東西。 (注意：當你的Activity已經運行在前台，而用戶想把當前輸入給下一個Activity時，這種方法就不適用了。) 很復雜嗎? 交給線程吧 如果你的應用程序有一些代價很大或者需要長時間運行的處理過程時，你應該把它們移到線程裡面。這樣就避免了彈出ANR對話框，讓你的程序能夠順暢的運行。 一般來說，Activity中的所有代碼和所有的VIEw類都是運行在相同的線程下面。同時這個線程也會處理用戶的輸入。例如，用戶按下一個按鈕，一個按鈕消息就會添加到Activity的主線程的消息列表中。這個事件消息需要從列表速度的提取出來處理，如果沒有速度的處理掉，幾秒鐘之後，系統就會認為該應用程序掛起了，就會開始結束進程。 如果你有長時間運行的代碼嵌入到你的Activity中，那麼在事前處理的過程中會運行該代碼，這樣就會使事件處理阻塞，這樣延緩了你的輸入進程，並且導致ANR的產生。為了避免這些，將你的運算放入一個線程裡面。 避免Activity Screen殺手 任何有用的應用程序都會有幾個不同的Screen對象。當切換你的用戶界面是，確保你可以不受限制的使用Activity。 取決於你的開發背景，你可能認為Activity和Java Applet一樣，在那裡面它是你的程序入口。即使是這樣，但這還不夠准確：Applet的子類是Java Applet的唯一程序入口，而Activity只是一個潛在的程序入口之一。主Activity和其他Activity之間唯一的不同就是：在你的android配置的XML文檔中，主Activity有"android.intent.action.MAIN" 這樣一項。 因此當你設計你的程序時，把你的程序當做是幾個Activity的聯合。這樣會使你的代碼在長期的運行中更容易維護，並且，通過利用android程序的歷史記錄和 "backstack"模式，你的程序會更容易編寫。 主題擴展 當我們開始觀察和感覺用戶界面的時候，一些細節作用很大。和他們期待的界面相比，用戶會感到很震驚。在設計你的用戶界面的時候，你應該盡量的避免使用你自己的方式，取而代之的是使用一個主題。再有必要的時候你能夠重載或者擴展你的主題，但是你的主題擴展都要有一個同樣的UI基礎。