前言Ian Darwin

Android 是手機應用上的開放原始碼革新。至少，是部分的改革。曾經有很多手機上開放

原始碼的嘗試，範圍從快倒閉的 Openmoko Freerunner 到 QT Embedded、Moblin、LiMo、Debian Mobile、Maemo 到新加入開放原始碼的 Symbian OS 和最近剛放棄的 HP WebOs。更不用提非開放原始碼的中堅； Blackberry OS、Apple 的 iPhone 和微軟 Windows Mobile ( 這些都有開發工具包，但它們的作業系統並非開放原始碼或常有某種限制 )。

就像 Mike O'Dell 曾說過的 “現在所擁有的不一定能夠預測出你的將來”。這些眾多競爭者

之間，Android 會有一席之地嗎 ? 我們認為它是有的。這本書的知識是由 Android 開發社

群分享和貢獻。他們協助這領域的後輩，使得 Android 開發更容易。[xiv]

關於 Android

Android 是一種手持式裝置技術平台，為手機、平板電腦和其他手持裝置 ( 甚至低價筆 電 )，提供強大可攜的 Linux 作業系統，和穩定、可攜的高階語言和 API。Android 應用

程式是用 Java 語言所寫成的，開發工具如 Eclipse，使用 Android API 將程式編譯為給

Dalvik VM 使用的 bytecode。

前言

xviii　　前言

因為屬於同樣的作業系統，Android 與 Openmoko、QT Embedded、MeeGo ( Nokia Maemo與 Intel Moblin 計畫在 2010 年合併的結果 http://www.engadget.com/2010/02/15/meego-nokia-and-intel-merge-maemo-and-moblin ) OPhone、LiMo，和其他 Linux based 的手機專

案有所關聯。從使用的語言來看，Android 與 BlackBerry 和 Java ME phones，以及其他各

種 Java 應用有關係。[xiii]

Android 的銷售繼續提升，NPD ( 引領北美銷售市場研究的公司 ) 報告指出 2010 第一季

Android 裝置的銷售量超過 iPhone ( http://www.npd.com/press/releases/press_100510.html )，Android 提升至第二位 ( 雖然還落後 BlackBerry 平台 )。雖然部分是因為 Verizon 二合一的

銷售關係，但那也不完全是這個原因。

這本書的起源

這本書是由好幾十位 Android 開發者 ( Android community 佔多數 ) 所撰寫。採取開放式的

方式，在網站 http://androidcookbook.com/， 也就是我打造的一個網站，允許大家貢獻、審 視、瀏覽和評論而組成這本書。完整的列表可以在『致謝』這一節中看到。我非常感謝所

有的貢獻者，讓這本書從夢想到實現成為你現在手上 ( 或是螢幕上，假如是購買電子版 )。謝謝你們大家！

這本書適合誰？

我們假設你有 Java 語言的基礎。假如沒有的話，參照秘訣 1.2。我們也假設你知道基本的

Java 標準版本 API ( 因為這形成基本的 Android 執行期函式庫 )，也知道 Android 的基本知

識。Activity、Intent、service 和 content provider 這幾個詞，你不用晚上還做夢夢到，但至

少要很熟悉。假如不是的話，參照秘訣 1.6。

這本書裡有什麼？

第一章，入門。幫助你經由一些步驟來建立 Android 開發環境，和幾個簡單的“Hello World” 之類的應用程式。

第二章，設計成功的應用程式。涵蓋一些桌上型電腦和企業軟體開發者在手持式裝置上

會遭遇到的差異，並且討論一些手持式裝置設計 ( 特別是 Android ) 和其他環境的差別。

前言　　xix

對一些開發者來說，測試經常是最後的事。我們提早在第三章 測試 裡討論。並不是讓你

可以跳過它。而是這樣一來你可以提前讀到。我們討論了單元測試，同時也討論了在受控

制的情況下測試整個應用程式。

Android 提供各種機制，讓應用程式內部或者與其他應用程式互相溝通。在第四章，程

序內部 / 外部 ( Inter-/Intra-process ) 通訊，我們討論了 intent、廣播接收器 ( broadcast receiver )、services、AsyncTask 和 handlers。

另一種常用的溝通機制是 SQL 資料庫，可以控制資料的存取。第五章，內容提供者 ( Content Provider )。我們展示如何讓應用程式透過一些簡單但卻和網址一樣普及的方式，

讓另一個應用程式使用。『XV』

第六章，圖形。涵蓋關於圖形的議題，包括使用 Android 繪圖和組成設備，就像使用桌上

型電腦工具一樣，去開發圖形影像、圖樣、標記、和其他會被放進你所完成的應用程式中

的東西。

每一個手持式應用程式都需要圖形界面，在第七章，圖形使用者介面 ( GUI ) 討論。涵

蓋 Android 整個圖形使用者界面開發。範例包含 XML 和少數使用 Java 程式的 GUI 開發。

第八章，警告用的 GUI: Menus、Dialog、Toasts 和 Notification。 涵蓋所有彈出式選單機

制 ── 選單對話框和 Toasts，以及一個不會彈出但也會在你的應用程式之外互動的視窗 ── Android 的提醒機制 ( notification )。

第九章，GUI: ListView。主要針對 Android GUI 最重要的元件 ── ListView。

Android 有很豐富的多媒體功能。第十章，多媒體。展示如何使用最重要的功能。

第十一章，資料持久性 ( Persistence )。展示資料如何存入檔案、資料庫等等。以及將來

如何取回資料。

一開始， Android 是手機作業系統。第十二章，電話應用程式。展示如何控制和回應現今

大部分的手機裝置。

對大部分手持式裝置來說，總是維持在開機和連線狀態。這對人們怎樣使用和看待它有

很大的影響。第十三章，網路應用程式。展示傳統網路應用程式的程式。隨後，第十四 章，遊戲與動畫，以及第十五章，社群網路。

xx　　前言

現在普及的定位系統，對於手持式應用程式的發展也有重要影響。第十六章，位置與地

圖應用程式。探討如何找到你的位置，如何從 Google 和 OpenStreetMap 得到地圖資料，

並且如何讓應用程式透過本章討論的方式，知道你的位置。

第十七章，加速度感測器 ( Accelerometer )。討論關於內建在 Android 裝置中的感測器，

和如何使用它們。

第十八章，藍牙。討論有關於藍牙所支援的低耗能，近距離網路，而不只是將藍牙耳機

連結到手機。

Android 裝置的獨特在於給開發者多少控制權。在第十九章，系統與裝置控制，有一些

特別的角度來探索。因為 Android 是 Linux 為基礎，在這一章節，一些秘訣是處理傳統

Unix/Linux 命令和設備。

第二十章，其他程式語言和架構。我們探討使用其他程式語言來撰寫部分的 Android 應

用程式。範例包含有 C、Perl、Python、Lisp 和其他語言。『xvi』

雖然這本書的版本是英文，並且英文仍是世界上最通用語言，但它絕不是唯一的語言。

大部分的使用者寧願應用程式可以使用他的語言和文化圖騰。第二十一章，字串和國際 化。討論語言和文化議題，以及它們與 Android 之間的關連。

大部分 Android 開發者希望其他人使用他們的應用程式。但假若使用者找不到應用程式，

這件事就不可能發生。第二十二章，打包、部署和發佈 / 銷售應用程式。展示如何準

備應用程式，並透過 Google Play 來發佈。同時也介紹如何使用其他市集，將你的應用程

式送到有需要的人手中。

本書所使用的慣例

本書使用下列印刷體裁：

楷體字 ( Italic )

指新術語、URL、電郵信箱、檔名及副檔名。

定寬字 ( Constant width )

程式列表，文章段落中的程式元素，諸如變數、函式名稱、資料庫、資料型態、環境變

數、敘述及關鍵字。

2.1 簡介 : 設計成功的 Android 應用程式Colin Wilcox

深入探討

本章是有關如何製作富有想像力，同時又有用的 Android 應用程式設計指南。有幾個訣 竅，描述具體的成功設計。這一小節列出了一些其他的成功範例。[63]

本章節的目的之一是解釋，為什麼 Android 上的本地 ( Native ) Java 應用程式能比其他方

法提供更豐富的內容。

手機本地應用程式的需求

無論要使用的是哪個平台，有數個需求是成功的交付手機程式的關鍵 :

zz 應用程式必須容易在裝置上安裝，移除和更新。

zz 它應該以引人注目的，獨特的，優雅的方式解決用戶的需求。

zz 它應該有豐富的功能，同時不管對新手或專家來說都很容易使用。

zz 它應該讓通過其他方式 ── 如網站 ── 接觸過相同的訊息的使用者，覺得很熟悉。

zz 關鍵的功能應該要很容易的被使用。

zz 它應該與其他本地應用程式有共同的外觀和感覺，以符合平台的標準和風格指引。

設計成功的應用程式

第二章

68　　第二章

zz 應用程式應該是穩定的、可擴充的、易於使用的和回應迅速的。

zz 它應該善用平台的能力，使用戶的體驗更具吸引力。

Android 應用程式設計

本章設計的 Android 應用程式將利用 Android OS 平台的獨特功能和特性。在一般情況下，

應用程式將是一個以 Activity 為基礎的解決方案，並允許獨立和受控制的基礎上訪問一個

一個畫面的資料。這種方法有助於將潛在的錯誤侷限在本地 ( localize )，並允許部分流程

獨立於程式其他部分進行更新或加強。[64]

在應用程式中導航的方式類似於蘋果 iPhone 解決方案，所有按鍵區域都在單一的導航控

制欄。在應用程式的任何地方都可以使用導航控制欄，因此使用者可以自由地控制應用 程式。

Android 解決方案將利用 Android 設備固有的特點，支持設備的觸控螢幕，而硬體按鈕則

允許使用者將應用程式切換到背景，以及在應用程式之間切換的能力。

在 Android 的設計中，可能的情況下，可以支援讓應用程式回到它被換出的點。儘可能在

設計之時，就考慮支援這個功能。

為了達到可攜性，應用程式應該只使用標準的 Android 使用者界面控制元件。主題或自行

定義的元件的使用，並不在本章的範圍之內。

應用程式將會被設計成使用簡單的 RESTful 網頁服務，並使用 JSON 格式提供資料。這個

介面和用在 Apple iPhone，以及其他平台的程式是相同的

應用程式應盡可能採用 Android 的風格和設計規範，因此，它將會融入其他在 Android 上

的應用程式。

屬於每個 view 的本地資料，在離開這個 view 時會被自動儲存起來，並且在同一個 view 再次出現時自動將使用者介面中的元件設定成上次離開時的狀態。以下列出一些應該考慮

的，重要的裝置特性：

螢幕大小和密度。為了依照螢幕種類來分類，Android 定義了兩個螢幕特性，螢幕尺寸 ( 螢幕的物理尺寸 ) 和螢幕密度 ( 螢幕上的像素的物理密度密度，或 DPI [ 每英寸的點數 ] ) 為了簡化所有不同類型的螢幕組態，Android 將它們一般化成幾個群組，使我們更容易選定

目標。

設計成功的應用程式　　69

在設計應用程式時，設計者應考慮並選擇最合適的螢幕尺寸和密度。

預設情況下，應用程式應該可以適用於所有的螢幕尺寸和密度，因為 Android 系統會對 UI版面和圖形資源進行適當的調整。然而，藉由提供不同的版面資源，以及在應用程式資源

清單中宣告程式支援的螢幕尺寸，你將可以根據螢幕大小建立專門的版面配置，並根據螢

幕的密度提供適合的圖形。

輸入組態。許多裝置提供不同的輸入機制，例如硬體鍵盤，軌跡球或五向方向鍵。如果

應用程式需要特定的輸入裝置，必須在 AndroidManifest.xml 檔案中宣告。並注意 Google Play 將不會讓應用程式出現在缺乏該種輸入功能的裝置中。然而，只有在很少數的情況 下，應用程式才會需要特定的輸入裝置。[65]

裝置的特別功能。不同的 Android 設備提供不同的硬體或軟體功能，像是照相機、光感應

器、藍牙功能，不同版本的 OpenGL 和不同精準度的觸控螢幕。不要假設某個功能可以出

現在所有 Android 設備上 ( 除了標準 Android 函式庫是一定有的之外 )。

視情況而定，Android 應用程式提供兩種不同的選單形式 ：

zz Option 選單中包含適用於當前 Activity 或啟動相關 Activity 的主要功能。Option 選單

一般是由使用者按下標示為 Menu 的硬體按鍵來觸發。Option 選單中的命令是可用

於目前 Activity 的全區域命令。

zz Context 選單是適用於目前所選定項目的次級功能。Context 選單通常是由使用者在

某個項目上長按 ( 按住不放 ) 所觸發。和 Option 選單一樣，這些操作可以作用在目

前的 Activity 或另一個 Activity 上。

Context 選單的指令可以用在目前選定的項目上。

當你長按在項目上，將會出現 Context 選單上的指令，應該與在項目上點擊之後所取得的

activity 中出現的選項相符合。

zz 將最常用的命令放在前面。

zz 只有最重要的命令以按鍵的形式出現在螢幕上，剩下的都移到選單中。

系統將自動安排選單的版面配置，並提供標準的使用方法讓使用者存取，應確保應用程式

符合 Android 使用者界面的指導原則。意思就是說，選單是使用者熟悉和可靠的方式，用

來存取應用程式所有的功能。

70　　第二章

Android 應用程式廣泛使用 Google 的 Intent 機制，用來在 Activity 之間傳遞數據。Intent 不僅被用來在單一的應用程式的 View 之間傳遞資料，也允許資料，或要求，傳遞給外部

模組。正因為如此，Android 應用程式的許多功能可以藉由 Intent 呼叫，嵌入其他應用程

式的功能來達成。這樣可以減少開發流程，並在所有應用程式間保有相同的外觀和功能

數據傳輸與傳輸格式。直接連接到任何第三方的數據來源都不是個好主意，例如，在您的

手機應用程式中使用 Type3 的 JDBC 驅動程式，直接和伺服器上的資料庫溝通就是是一個

壞主意。正常的做法是，將多個來源的多種資料格式，透過 middleware 轉換並傳送資料

到應用程式，通過連續的 RESTful 網路服務 API，以 JSON 資料流的方式傳送。[66]

通常情況下，資料會藉由，如 XML、SOAP 或其他一些衍生的 XML 格式來提供。這些表

現方法中，像 SOAP 是重量級的，因此，以這種格式將資料從後端伺服器傳送顯著的增加

了開發所需的時間，因為將資料轉換成更易處理的格式的工作如果不是在手持裝置上做，

就是在 middleware 伺服器上進行。

藉由 middleware 伺服器來減輕資料來源的負擔，也有助於打破應用程序和資料之間的依

賴關係。這樣的依賴關係有個缺點，像是，如果因為某個原因，資料特性改變了，或者資

料沒辦法讀取了，應用程式可能會出錯或無法使用。這樣的改變可能造成應用程式必須重

新發佈更新。通過 middleware server 處理資料，不管資料來源存在與否，即使只能使用有

限的功能，應用程式仍可以繼續執行。因為這個處理過的資料和應用程式之間的連結仍然

存在。

2.2 異常狀況的處理Ian Darwin

問題

Java 有一個定義明確的異常狀況處理機制，但需要一些時間來學習如何有效地使用它，並

避免造成使用者或技術支援人員的困擾。

解決方案

正確的使用情況下，Java 為提供的異常狀況層次結構，提供了相當大的彈性。Android 則

提供了包括對話窗和 toast 訊息等幾個機制，通知使用者發生了錯誤的情況。Android 開發

者應熟悉這些機制並學習如何有效地使用它們。

設計成功的應用程式　　71

深入探討

從 Java 出現在市面上以來，Java 就有兩種例外 ( exception )：checked 和 unchecked ( 事實

上，應該是 Exception 的父類別 -Throwable )。在 Java Standard Edition 中，明顯的強迫程

式設計師面對一個事實 ── 有些事情可以在編譯時發現，其他的則不行。例如，當你要

在大量的 PC 上安裝程式，可能有些 PC 的硬碟已經快滿了，這時想要把資料寫入將會失

敗；同時，某些 PC 上，應用程式所需的檔案可能會遺失，這並不是程式設計師的錯，而

是使用者的問題，檔案系統的偶發錯誤、一隻沙鼠咬了電線、或其他各種可能的狀況。所

以 IOException 就屬於 “checked exception”。意思是，程式設計師必須檢查它，可以把有

關檔案使用的部分放在 try-catch 之中，或在定義函數時定義 throws。一般來說，受過良

好訓練的 Java 程式設計師應該記得：[67]

Throwable 是 所 有 throwable 階 層 的 root。Exception， 和 它 的 子 類 別 ( 除 了

RuntimeException 及其子類別之外 )，都是 chekced。剩下的都是 unchecked。

這意味著，Error 和它的子類都是 unchecked ( 見圖 2-1 )。例如，如果你遇到一個 VMError，這表示有一個執行期的錯誤。身為應用程式的設計師，這不是你能解決的問題。

RuntimeException 的子類別，包括一些名字過長的 ArrayIndexOutOfBoundException，類似這些都是 unchecked，因為它們是你的責任，你應該在開發的時候藉由測試 ( 見第三 章 )，來找出這些異常狀況。

RuntimeException IOException

UncheckedChecked

Exception

SQLException

Throwable

OutOfMemoryError

Error

圖 2-1 Throwable 的階層

72　　第二章

在哪裡攔截異常狀況

早期的 ( 過度 ) 使用 checked exception 造成許多早期的 Java 開發者寫出的程式碼中散布

著許多的 Try-Catch 區塊。部分的原因是一些訓練課程和書籍中並沒有及早強調 throws

的使用。由於 Java 用來完成企業級的工作，新的架構如 Hibernate 和 Spring 出現並強調

unchecked exception 的使用，這種早期的問題已得到改善。現在的共識認為，為了重複使

用所寫的程式碼，應該盡可能在接近使用者的層級去處理異常狀況 ── 在函式庫或甚至

在多個應用程式中 ── 不應該試著處理異常狀況。

它該做的是所謂的 exception translation， 也就是把很技術性 ( 通常也是 checked ) 的異常狀

況轉換成一般性的，unchecked 的異常狀況。範例 2-1 展示基本的模式。 [68]

範例 2-1 Exception translation

public String readTheFile(String f) { BufferedReader is = null; try { is = new BufferedReader(new FileReader(f)); String line = is.readLine(); return line; } catch (FileNotFoundException fnf) { throw new RuntimeException("Could not open file " + f, fnf); } catch (IOException ex) { throw new RuntimeException("Could not read file " + f, ex); } finally { if (is != null) { try { is.close(); } catch(IOException grr) { throw new RuntimeException("Error on close of " + f, grr); } } }}

請注意即使在這一小段程式碼中，checked exception 是如此雜亂 : is.close() 幾乎不可能

失敗。但是，由於我們希望將它放在 finally 區塊中 ( 確保檔案開啟之後卻又有發生錯誤 時，程式會試著去關閉檔案 )。又必須在旁邊多加一個 try-catch。因此 checked exception ( 往往都是 ) 不好的做法。應該避免在新的 API 中使用。必要時應該以 unchecked exception覆蓋 ( pave over ) 他們。

設計成功的應用程式　　73

不過也有反對意見，Oracle 官方網站和其他的擁護者。在孕育本書的網站的評論中， Al Sutton 指出如下的意見 :

Checked exception 的存在是強迫開發者確知某個錯誤情況可能會發生，他們必須

想清楚如何處理錯誤。很多情形中，除了做 log 和回復之外並沒有甚麼可以做 的。但這仍是開發者確認他們已經想過該如何處理這類型的錯誤。這個例子顯

示…。停止呼叫一個命令，有可能是當一個檔案不存在時 ( 檔案可能要重新取 得 )，也可能是讀取一個檔案卻發現有問題時 ( 檔案存在，但沒辦法讀取 )。其實

是兩種不一樣的錯誤情況。

Android，為了忠於 Java API，也有許多 checked exception ( 包括我們在例子中看到的 ) 所以也應該以同樣的原則處理。

怎麼處理異常狀況

異常狀況幾乎都應該要有報告。當看到程式碼攔截異常狀況卻甚麼也不做，我就覺得很絕

望。但是，它們只應該被報告一次 ( 不要寫到 log 之後又翻譯 / 往上傳遞！ )。一般來說

異常狀況就是用來指出，如同它的名字，一個異常的情形。由於 Android 裝置沒有系統管

理員或主控台。異常情況必須報告給使用者知道。[69]

你應該思考要用對話窗 ( dialog ) 或是 toast 做回報。在手機上的異常狀況處理和在桌上型

電腦是不同的。使用者可能在開車，操作機械，和其他人互動等等，所以你不該期望他

很專注。記得 toast 只會出現在螢幕上幾秒鐘；眨個眼可能就漏看了。如果使用者必須做

些動作來更正這個錯誤，就應該使用對話窗。本書中大部分的例子都是用 toast， 因為比

起對話窗它只需要一點點程式碼。( 相反的例子，BlackBerry 的 API 讓 Dialog 變得很簡單 : Dialog.altert(“message”); )。Toast 簡單的出現一下然後就消失了。對話窗則要使用

者確認他們已經知道者個異常狀況，並且，去做或給應用程式權限去做某些需要付錢的事

( 像是啟動網路連線，因為應用程式需要下載地圖 )。

用 toast 提示不重要的訊息 ; 用對話窗顯示重要訊息並確認使用者看到。

74　　第二章

2.3 以 Singleton 方式存取 Android 的 Application物件

Adrian Cowham

問題

需要在 Android 應用程式中存取全域資料。

解決方案

最理想的解決方法是使用 android.app.Application 的子類別，並且把存取程序宣告為

static。用 singleton 的方法取存取這個子類別。在每個 Android 應用程式的生命週期內

都保證只會有唯一一個 android.app.Application 的實體。如果你建立了 android.app.

Application 的子類別，Android 就會用這個子類別去產生一個實體並透過這個子類別的

實體呼叫 android.app.Application 中的函數。由於並沒有任何實際的限制讓你沒有辦法

再建立另一個實體，所以這個方法並不是真正的 singleton。但也相去不遠了。

擁有在整個程式都可以存取的物件，例如連線的 handler，網頁伺服器 gateway 或其他在程

式中任何只需要單一物件的東西，都會大幅簡化程式。有時候這些物件可以以 singletion的方式實現，有時候不行，因為它們需要有 Context 才能被正確的初始化。不論哪一種狀

況，為你的 android.app.Application 子類別加上一個 static 的存取程序都是很值得的。

因為你可以將所有的存取都統一在同一個地方，保證一定可以存取到 Context 實體，並且

可以輕易地寫出 “正確的” singleton 程式而不用擔心同步的問題。[70]

深入探討

當你開發 Android 應用程式時，可能會發現有需要在不同的 activity 之間分享資料或服 務。舉例來說，如果應用程式有連線階段的資料 ( session data )，例如目前已登入的使

用者，就很有可能需要揭露這個資訊。在 Android 平台上開發程式時，解決這個問題最

常見的模式就是在 android.app.Application 的實體中加上所有的全區域資料，然後把

Application 實體當作 singleton 看待，通過 static 的存取程序取得這些資料和服務。