首页 > > > Android_应用框架原理与程序开发_高焕堂.pdf

Android_应用框架原理与程序开发_高焕堂.pdf

Android_应用框架原理与程序开发_高焕堂.pdf

上传者: gongbingqing 2011-08-29 评分1 评论0 下载43 收藏10 阅读量697 暂无简介 简介 举报

简介:本文档为《Android_应用框架原理与程序开发_高焕堂pdf》,可适用于手机软件领域,主题内容包含應用框架原理與程式設計技適用於Android版本書完整範例程式碼請到網站下載:wwwmisoocom或tomkaoblogspotcom高煥堂著(年符等。

1 應用框架原理與程式設計 36 技 適用於 Android 1.0 版 本書完整範例程式碼請到網站下載: www.misoo1.com 或 tom-kao.blogspot.com 高煥堂 著 (2008 年 10 月第三版) misoo. tw@gmail .com 2 Android 應用框架原理與程式設計 36 技 著作權聲明: z 本書已於 2008 年 4 月出版發行。 z 著作權屬於 高煥堂 所擁有。 z 本 e-book 可整份免費自由複製流傳。 z 但非經作者書面同意,不可以加以切割、剪輯及部分流傳。 z 任何商業用途皆需得到作者的書面同意。 書內範例原始程式碼,請到 tom-kao.blogspot.com 或www.misoo1.com下载。 3 第三版序言 由於 Android 正式(1.0)版和 HTC/Android 實體手機皆已經上市了,因之本書 也針對 Android 1.0 版的出爐而即時修訂,成為本書的第三版。 大家幾乎都聽過愚公移山的故事,但是大家常把焦點擺在愚公和移山,而忽 略了畚「箕」的角色。禮記.學記篇上有言:良弓之子,必學為箕。其意思是,欲 做出優良的弓,必先好好研究其模子(即箕)。最近許多人知道 Google 推出轟動武 林、驚動萬教的 Android 手機平台。但是幾乎都只關心如何在該新平台上開發應 用程式,卻忽略了 Android 是個框架(Framework),而框架裡含有成百上千個「箕」 類(註:基類是大陸對 Super Class 的譯詞)。基於「良弓之子,必學為箕」的精神, 本書先教您正確認識框架(箕)之原理,然後才介紹如何善用畚箕來開發出優良的 Android 應用程式(良弓)。本書共分為 4 篇: ※ 第一篇:介紹應用框架概念、原理和特性。 ※ 第二篇:闡述應用框架之設計技巧。亦即,如何打造應用框架。 (註:如果你的職務是「使用」Android 框架來開發應用程式的 話,可以跳過本篇,直接進入第三篇。) ※ 第三篇:說明及演練 Android 應用程式設計的 36 技。 ※ 第四篇:介紹 Android 框架與硬體之間 C 組件的開發流程及工具。 筆者並不是說 Android 的應用程式師是愚公,而旨在說明手機軟體領域的三個主 要分工角色: z 做畚箕者:如 Andriod 開發團隊。 z 畚箕買主:如 Google 公司。 z 挑畚箕者:如 Android 應用程式師。 本書也不把您設定為應用程式師單一角色,而是盼望能協助您開拓更寬廣的未 來,無論在上述的任何角色,都能如魚得水,輝煌騰達。於此誠摯地祝福您! 高煥堂 謹識於 2008.10.3 tom-kao.blogspot.com 4 Android 應用框架原理與程式設計 36 技 目 錄 第一篇 良弓之子,必學為箕(框架) ~禮記.學記~ 第 1 章 認識應用框架, 14 1.1 何謂應用框架 1.2 框架的起源 1.3 框架的分層 1.4 框架的「無用之用」效果 1.5 框架與 OS 之關係:常見的迷思 第 2 章 應用框架魅力的泉源:反向溝通, 31 2.1 前言 2.2 認識反向溝通 2.3 主控者是框架,而不是應用程式 2.4 現代應用框架:採取廣義 IoC 觀念 2.5 框架的重要功能:提供預設行為 第二篇 無之(抽象)以為用 ~老子:無之以為用~ 第 3 章 如何打造應用框架, 54 3.1 基礎手藝:抽象(無之)與衍生(有之) 3.2 打造框架:細膩的抽象步驟 3.2.1 基本步驟 3.2.2 細膩的手藝(一):比較資料成員 3.2.3 細膩的手藝(二):比較函數成員 3.2.4 細膩的手藝(三):將抽象類別轉為介面 5 第三篇 有之(繼承)以為利 ~老子:有之以為利~ 第 4 章 應用程式設計的基礎手藝 12 技, 82 4.1 #1:如何建立 Menu 選單 4.2 #2:如何呈現按鈕(Button)之 1 4.3 #3:如何呈現按鈕(Button)之 2 4.4 #4:如何進行畫面佈局(Layout) 4.5 #5:如何呈現 List 選單之 1 4.6 #6:如何呈現 List 選單之 2 4.7 #7:如何運用相對佈局(Relative Layout) 4.8 #8:如何運用表格佈局(Table Layout) 4.9 #9:如何動態變換佈局 4.10 #10:如何定義自己的 View 4.11 #11:如何定義一組 RadioButton 4.12 #12:一個 Activity 啟動另一個 Activity 第 5 章 Use Case 分析與畫面佈局之規劃, 141 5.1 善用 Use Case 分析 5.2 以 Android 實踐 Use Case 分析之策略 第 6 章 Use Case 分析的實踐(策略-A):6 技, 149 6.1 #13:使用 Menu 和 starActivity()實踐之 6.2 #14:使用 starActivityForResult()替代 startActivity() 6.3 #15:使用 ListView 替代 Menu 6.4 #16:以 ListActivity 替代 Activity 父類別 6.5 #17:改由.xml 檔案定義畫面佈局 6.6 #18:使用 onResume()函數 6 Android 應用框架原理與程式設計 36 技 第 7 章 Use Case 分析的實踐(策略-B):2 技, 179 7.1 #19:一個 Activity 支持兩個畫面佈局 7.2 #20:將兩個畫面佈局合併為一 第 8 章 介紹關聯式資料庫與 SQLite , 193 8.1 何謂關聯式資料庫 8.2 建立一個表格(Table) 8.3 從表格中查詢資料 8.4 關聯資料模型 8.5 關聯的種類 8.6 兩個表格之互相聯結 8.7 SQL 子句:加總及平均 8.8 SQL 子句:分組 第 9 章 資料庫手藝:5 技, 201 9.1 #21:SQLite 基本操作 9.2 #22:讓 SQLite 披上 ContentProvider 的外衣 9.3 #23:細說 SQLite 與 ContentProvider 9.4 #24:讓 SQLite 配合 onCreate()、onResume()而來去自如 9.5 #25:如何實現商業交易(Transaction) 第 10 章 進階手藝 10 技, 237 10.1 #26:如何定義 BroadcastReceiver 子類別 10.2 #27:如何撰寫 Service 子類別 10.3 #28:如何使用 ProgressDialog 物件 10.4 #29:如何捕捉按鍵的 KeyEvent 10.5 #30:善用 UML Statechart 嚴格控制系統的狀態 10.6 #31:如何使用 MapView 7 10.7 #32:如何使用 WebView 10.8 #33:如何自動化操作畫面輸入 10.9 #34:如何活用 COR 設計樣式 10.10 #35:如何活用 State 設計樣式 第四篇 第三十六技:為箕是上策 第 11 章 如何撰寫框架與硬體間之 C 組件, 307 11.1 #36:如何撰寫框架與硬體間之 C 組件 11.2 發展 Android C 組件的經濟意義 附錄 A:327 A-1 如何安裝 Windows 平台的 Android SDK 1.0 版及 Eclipse A-2 如何離線安裝 Android SDK 1.0 版及 Eclipse A-3 如何著手撰寫 Android 應用程式 A-4 如何執行 Android 應用程式 A-5 如何安裝 Linux/Ubuntu 平台的 Android SDK 1.0 版及 Eclipse A-6 如何安裝 C/C++ Cross Compiler 附錄 B:336 B-1 高煥堂於 Omia 行動應用服務聯盟會議上演講的講義 B-2 歡迎一起推動「百萬個小 Google 計畫」 B-3 迎接 IT 第三波:移(行)動時代 B-4 高煥堂教你最先進的「現代軟體分析與設計」 B-5 認識 Android 模擬器的操作 Eclipse 8 Android 應用框架原理與程式設計 36 技 本書由 Misoo 團隊創作與出版 Misoo 技術團隊介紹 由高煥堂領軍的 Misoo 團隊與大陸、俄羅斯、日本專家所組成的跨國嵌入式聯合 設計(Co-design)團隊。Misoo 的開放合作態度,贏得國際的好感和商機。 ƒ 位於風景秀麗的 Voronezh, Russia 例如,跨國團隊成功地將俄羅斯研發 20 多年的頂級 Linter 嵌入式資料庫系統納入 Android 手機裡執行,成為 Android 的嫡系成員之一。此外,Misoo 團隊開發的 Android 遊戲應用程式也順利外銷歐美諸國,如下圖: Russia 9 還有,手機線上遊戲等等,如下圖: 10 Android 應用框架原理與程式設計 36 技 跨國團隊經驗豐富、技術精湛,嵌入式開發成功經驗,包括: ƒ 客製化影音播放器(video player)開發 ƒ 嵌入式資料庫管理引擎(DBMS)開發 ƒ 行動平台 GPS 系統開發 (Blackberry, WinCE, J2ME) ƒ 電信業的專屬無線協定(wireless protocol)的開發 ƒ 學習內容播放系統開發(Flash-based) 11 基於 Misoo 的開放精神,高煥堂將本書製作成 e-book 供大家免費閱讀,希望 本書在這千載難逢的大好機會裡,能陪伴諸位的成長與茁壯。此外,高煥堂又把 一些跨國團隊的實務經驗和技術加以編輯,並出版成書,或成為企業培訓課程的 講義,將進一步與大家分享。 如何與 Misoo 跨國團隊技術合作呢? 開發專案(項目)合作: z 歡迎直接與 Misoo 團隊聯絡: TEL: (02) 2739-8367 E-mail: misoo.tw@gmail.com 公開教育訓練課程,或企業團隊內訓: z 台北地區 歡迎與 Misoo 團隊聯絡: TEL: (02) 2739-8367 E-mail: misoo.tw@gmail.com z 上海地區 歡迎與 祝成科技洽詢: TEL: 400-886-0806 E-mail: sv@softcompass.com 歡迎多多指教 Misoo 網頁: tom-kao.blogspot.com 或 www.misoo1.com 12 Android 應用框架原理與程式設計 36 技 歡迎報名參加 高煥堂 主講的 Google Android 技術教育訓練課程 詳細課綱與日期,請上網 www.misoo1.com 服務電話:(02)2739-8367 E-mail: misoo.tw@gmail.com 高煥堂的第 2 本 Android 暢銷書籍(天瓏網路書局熱賣中) *** 詳細目錄 請看第 308 頁 或上網www.android1.net *** 第 1 章 認識應用框架 13 第一篇 良弓之子,必學為箕(框架) ~~禮記.學記~~ 良弓來自好的框架(箕)。 優良的應用程式來自美好的應用框架。 優秀的 Android 程式師,必先學習應用框架的原理。 14 Android 應用框架原理與程式設計 36 技 第 1 章 認識應用框架 1.1 何謂應用框架 1.2 框架的起源 1.3 框架的分層 1.4 框架的「無用之用」效果 1.5 框架與 OS 之關係:常見的迷思 第 1 章 認識應用框架 15 1.1 何謂應用框架 顧名思義,應用框架是某特定應用領域(Domain)中,程式間的共同結構。 讓該領域中的程式師們,依共同結構來發展程式,使程式間具有一致性,增加了 程式的清晰度,以降低程式的設計與維護費用。 所謂「共同結構」,包括了通用的類別、物件、函數,及其間的穩定關係。由於框 架是通用的,大家能共享 (Share) 之,增加了工作效率,提升了軟體師的生產力 ( Productivity)。茲拿個簡單例子來說吧兩個長方形,分別為直角及圓角,如下 首先分辨它們的異同點,然後將其共同部分抽離出來,如下 我們稱這過程為「抽象」(Abstraction) 。並稱此圖形為「抽象圖」,其只含 共同部分,而相異部分從缺。原有的直角及圓角方形,為完整圖形,稱為「具體 圖」。一旦有了抽象圖,就可重複使用(Reuse) 它來衍生出各種具體圖,且事半功 倍例如 用途 1 衍生直角方形。 拷貝一份抽象圖,在圖之四角分別加上、、及,就成為直角 方形了,如下 16 Android 應用框架原理與程式設計 36 技 用途 2 衍生圓角方形。 拷貝一份抽象圖,在圖之四角分別加上、、及,就成為圓 角方形了,如下 用途 3 衍生球角方形。 拷貝一份抽象圖,在圖之四角各加上 就成為 上述簡單例子中,說明了兩個重要動作 抽象從相似的事物中,抽離出其共同點,得到了抽象結構。 衍生以抽象結構為基礎,添加些功能,成為具體事物或系統。 同樣地,在軟體方面,也常做上述動作 抽象 在同領域的程式中,常含有許多類別,這些類別有其共同點。程式 師將類別之共同結構抽離出來,稱為抽象類別(Abstract Class)。 衍生 基於通用結構裡的抽象類別,加添些特殊功能,成為具體類別,再 誕生物件。 第 1 章 認識應用框架 17 所以「抽象類別」存在之目的,是要衍生子類別,而不是由它本身來誕生物 件。由於抽象類別本身不誕生物件,所以有些函數並不完整。反之,如果類別內 之函數,皆是完整的,而且要用來誕生物件,就稱它為具體類別 (Concrete Class)。上述簡單例子中,說明了兩個重要動作 抽象從相似的事物中,抽離出其共同點,得到了抽象框架。 衍生以抽象框架為基礎,添加些功能,成為具體事物。 其中,「抽象」結果的好壞,決定於程式師的領域知識,及其敏銳觀察力。 這是個複雜的動作,其過程愈精細,愈能得到穩定而通用的框架。一旦有了穩定 且彈性的框架,衍生具體類別的動作,就輕而易舉了。 框架中除了抽象類別外,還有類別間之關係。未來衍生出子類別,並誕生物 件,其物件就會依循既定的關係來溝通、協調與合作。因之,框架說明了物件的 溝通與組織方式,就如同「食譜」敘述著食物料理方法。 不過,食譜並不能完全比喻框架,只比喻一部分而已。食譜只敘述料理方 法,並無真正的蔥、牛肉等。然而框架含有類別、函數、以及物件等真正的程 式。因之,有人拿「未插完的花盆」來比喻框架,似乎更傳神插花老師先插上 背景花,並留下空間,任學生發揮,繼續插完成。框架設計師提供了基本類別, 也預留空間讓您發揮,繼續衍生出子類別。 從上所述,可知框架包括了 一群抽象類別,類別內有函數,函數內有指令,但有些函數內的指令從缺, 預留給應用程式師補充之。 抽象類別間之穩定關係。 然而,現在市面上的框架,不只含抽象類別,且含有具體類別、函數、及物 件。實際上,框架已涵括了傳統類別庫(Class Library) 之功能,使得大家不易區 分框架與類別庫之差別了。只能在理論上,區分兩者如下 18 Android 應用框架原理與程式設計 36 技 應用框架 類別庫 目的讓應用程式師衍生出具 目的讓程式師拿現成類別來誕 體類別,衍生時可修正 生物件,類別並未預留空 類別,才誕生物件。 間給程式師來修正。 應用框架中的類別的函數,常 應用程式的函數只能呼叫類別庫 呼叫應用程式中的函數。 中的函數,反之不可。 含有類別間之關係,其預設了 類別是獨立的,並未設定物件間 物件間的互助合作關係。 的溝通方式。 物件常含預設計行為(Default 物件的行為皆是固定的,無法修 Behavior) ,預設行為可讓應 正之。 用程式師修正之。 在實用上,許多人已將它們混為一談了。 1.2 框架的起源 框架(Framework)的歷史已經有 20 多年了,可追溯到 1980 代 Smalltalk 語言的 MVC,到了 Apple Macintosh 時代的 MacApp 框架開始大放異彩。逐步演進到今 天的.Net Framework,其應用範圍愈來愈大,已經成為資訊服務系統的共通核心 框架了。20 多年來,框架的基本原理一直都沒有改變,其基本結構也沒有太多變 化,其基本用法也是老樣子,只是應用的場合及範圍不斷地擴大,經驗不斷累積 中。在框架的發展過程中,最具有代表性的是 1980 年代初期 ----- Smalltalk-80 的 MVC Framework 1980 年代中期 ----- Macintosh 電腦的 MacApp Framework 1990 年代初期 ----- Visual C++ 的 MFC Framework 1990 年代中期 ----- IBM 的 San Francisco Framework 2000 年 -------------- Microsoft 的.Net Framework 第 1 章 認識應用框架 19 2007 年 -------------- Google 的 Android 框架 茲簡介如下: 1.2.1 Smalltalk-80 的 MVC 框架 應 用 框 架 的 起 源 中 , 大 家 最 熟 悉 的 是 Smalltalk-80 語 言 中 的 MVC(Model-View-Controller)框架。其讓 Samlltalk 程式師迅速建立程式的使用者 介面(User Interface)。從 1980 年代的 Smalltalk-80 到 1990 年代 Smalltalk-V ,其 使用者介面皆依循這個著名的框架。典型的 MVC 框架包括三個抽象類別 Model、View及 Controller。應用程式從這些抽象類別衍生出具體類別,並誕生物 件。其物件間的關係如下 圖 1-1 著名的 MVC 框架 model 物件負責管理資料或文件,它可對應到數個 view 物件,每個 view 物 件顯示出 model 物件的某一方面每個 view 物件有 1 個相對應的 controller 物 件,其負責解釋使用者輸入的訊息,如移動滑鼠等等。使用者輸入訊息時, controller 依訊息去要求 model 處理文件資料,也會要求 view 物件更新畫面。一 旦 model 物件中的資料更動了,model 物件會通知各 controller 及 view 物件,各 view 物件會向 model 取得新資料,然後更新畫面。因之典型 MVC 框架是由一群 model、view 及 controller 物件互助合作,做為使用者與應用程式的溝通介面。 20 Android 應用框架原理與程式設計 36 技 1.2.2 MacApp 框架 1980 年代中期,已有多種商業性的應用框架上市,其中最流行的是 Apple 公司的 MacApp 框架,其能協助發展 Macintosh 電腦上的應用程式。這應用程式 包括 3 個部分 application 負責啟動程式、解釋使用者的訊息與命令。 document 管理與儲存應用程式的文件資料。 view 顯示與輸出文件資料。一個程式常含有數個 view,裨從不同 角度來瀏覽文件資料。 Macintosh 電腦具有視窗畫面。在螢幕畫面上,view 依偎在 window 中,且 view 的外圍有個 frame。當使用者選取視窗選擇表中的項目時,會產生 command 來要求更新 document 或 view 之內容。因之,由 MacApp 框架所產生的介面, 含有下述物件 application 物件 負責啟動程式、誕生 document 物件,顯示視窗選擇表,並傳遞訊息與命令 等。 document 物件 負責誕生有關的 view、window 及 frame 等物件。當 document 中的資料異動 時,document 物件會通知 view 物件來取得新資料,並更正視窗中的內容。 window 物件負責視窗的開關、移動、及通知 frame 物件來協助改變視窗大 小及捲動等。 frame 物件 負責將視窗分割為小區域,每區域可擺入一個 view,也負責捲動及改變窗 之大小。 view 物件 負責顯示資料、記錄滑鼠的位置、以及改變游標的形狀。 command 物件 當使用者藉滑鼠、選擇表及鍵盤來發出命令時,由 command 物件來轉送給 document 或 view 物件,要求它們採取進一步的行動。 第 1 章 認識應用框架 21 雖然 MacApp 框架中,定義了許多類別來誕生上述的物件,然而應用程式中 通常可直接使用現成的 window、 frame 及 command 等類別和物件。至於 application 、document 及 view 物件,常須加以修正,才能合乎特定的應用場 合。因之,應用程式必須分別由 TDocument 、TView 及 TApplication 抽象類別 衍生出具體子類別,然後才誕生 document、view 及 application 物件。 MacApp 框架成功地結合了螢幕視窗功能,並提供親切的軟體發展環境,其 應用程式呈現可塑性,能隨需求而不斷修正。這成功經驗,對後來的應用框架的 發展,產生了極大的影響。 1.2.3 Visual C++ 的 MFC 框架 在 1990年~1993年之間,Borland C++ 上市並提供了 OWL 應用框架,隨後 Microsoft C/C++ 及 Visual C++上市,提供了 MFC 應用框架。OWL 及 MFC 的 目的和功能大致相同皆為了將 Windows 的 API 介面函數包裝起來,使得 C++ 應用程式師能依循一致的框架,迅速發展 Windows 應用程式。初期的 MFC 包含 兩部分: 與 Windows 有關的類別 用來包裝 Windows 的介面函數。 通用性的類別 例如 List、Array 、Date 等與常用資料結構有關的類 別。 後來逐漸增加了更多組件,例如: OLE 類別 協助應用程式經電腦網路而連結到分散各地的物件。 ODBC 類別 協助應用程式以統一的 SQL 敘述來存取各式資料庫(如 Oracle、Sybase 等)之內容。 MFC 的物件組織與合作方式,類似於 MacApp 的物件群組關係。MFC 含有 CWinApp 、CMainFrame、CView 及 CDocument 等基本類別。應用程式必須從 這些類別衍生出具體子類別,並誕生物件,互相溝通與合作。其物件間的關係如 下: 22 Android 應用框架原理與程式設計 36 技 圖 1-2 MFC 的 Document/View 框架 Windows 將使用者所輸入的訊息傳給 mainfrm 物件,由 mainfrm 再轉達給 view、app 或 document 物件。當 document 物件內的資料有所異動時,document 會通知 view(程式可含許多 view)物件來取得新資料,以便更新視窗內容。 1.2.4 IBM 的 San Francisco 框架 上述的 MVC、MacApp 及 MFC 皆是擔任系統層次的核心任務,如電腦網 路、分散式資料庫的管理工作。到了 1990 年代中期,框架開始擴展到商業資訊 服務的層面,就是俗稱的應用框架(即 Application Framework),又稱為商業的領 域框架 (即 Business Domain Framework)。其中最著名的是 IBM 公司的 San Francisco 框架。 IBM 的 San Francisco 含有商業服務的企業核心流程,如 ERP 的訂單循環、 會計的應收應付循環等,如下圖 1-3 所示。此外也含有像「客戶」及「帳戶」等 核心的企業物件及物件之間的關係。 第 1 章 認識應用框架 23 應用程式 核心企業流程 Business Financials Order Management 共同企業物件 基礎服務 Java VM Unix、NT 等平台 圖 1-3 IBM 的 San Francisco 元件框架 IBM 的 San Francisco 框架所提供的是 非客製化 的商業核心服務,讓其它 資訊服務廠商進行開發客製化的商業應用服務。 1.2.5 微軟的 .Net Framework 到了 2001 年,微軟所推出的 .Net Framework,其格局更擴大到整個企業 (Enterprise)的分散式框架,甚至包括以 Web service 為核心的靠企業大型分散式框 架。例如它提供 XML Web Service、MSMQ 非同步的訊息服務、Security 服務 等。在 .Net Framework 裡含有上千個既有的類別,能透過繼承或介面委託方式 使用這些類別的功能或服務。 1.2.6 Google 的 Android 框架 於 2007 年 11 月,Google 推出的 Android 應用框架,其適用於「手機+網路」 的新市場上。除了它是一個新的應用之外,更珍貴的是其程式碼採開放策略,讓 大家能一窺其全貌,給予軟體開發者很好的學習機會。 24 Android 應用框架原理與程式設計 36 技 1.3 框架的分層 由於框架介於應用程式與系統程式之間,能大量地重複使用(Reuse) ,並可 不斷修正之,因而提升了應用程式之彈性,也能提升系統程式之彈性。它本身也 可分為兩個層級,如下圖: 圖 1-4 應用框架之層次 例如,在多平台(Multi-platform) 系統上,彈性是極重要的。在這個層次裡, 框架提供了支援性的服務,通稱為支援性框架,讓人們不但能使用作業系統的 API 函數,也可以修正之,裨更符合企業的需要。這種支援性的框架,其觀念與 一般應用框架相同,只是它負責系統層次的任務,如電腦網路、分散式資料庫的 管理工作。一般,應用程式師並不直接修正支援性框架,而是由系統維護人員來 修正之。 在應用層次上,許多企業已著手創造自己的專業框架,整合公司裡的軟體系 統。如果您把應用框架比喻為「食譜」,則不難想像到各領域(Domain)的產業都 可能發展出應用框架了。例如,歐洲汽車廠就聯合發展出 AUTOSAR 應用框架, 它們就如同食譜配方,是餐廳賺錢的祕方。因之,在支援性框架的協助下,許多 專精於某領域的公司,設計出各式各樣的應用框架,像貿易、運輸、醫療、手機 第 1 章 認識應用框架 25 等,例如Android就是手機+網路的應用框架,讓各手機廠商,可經由修正及補充 來創造出「獨家」的應用系統,成為自己公司中的重要資源。 例如,Android 就包含了支援性框架和手機專業應用框架。 1.4 框架的「無用之用」效果 小樹的用途少,人們不理睬它、不砍伐它、才有機會長成有用之巨木,此為 「無用」之用老子說過:「人皆知有用之用,而莫知無用之用」,這與框架觀 念是一致的。 數千年前,老子提出了這「有、無」哲理,從無為狀態中創造出有為的積極 效果。像房子的中間、門、窗皆是空的,才能供人們進出、居住與透透空氣。其 積極效果是日後依新環境的條件而加以調整、充實,創造出多樣化的用途。例 如畚箕的中間是空、虛的,才能裝泥土、垃圾等各式各樣的東西。此外,畚箕的 空無,創造了畚箕的重複使用性(Reusability),裝完了泥土,倒掉之後,還可拿 來裝垃圾等,不斷重複使用之,一直到壞掉為止。 不僅上述的樹木、房子、畚箕等東西深含虛無之用哲理,在人們的精神修養 上也常見同樣哲理。例如古之賢者常教導年輕人應該「虛」懷若谷,才能不斷虛 心求教,不斷吸收新知識,不斷充實與成長,成為有用之人。反之,志得意滿的 年輕人,常不願虛心吸收新知識,常在不知不覺中變為新環境中的古典人物,為 不斷變化的潮流所淘汰。 應用框架中的主角抽象類別,並非具體的類別,不能用來誕生物件,看 似無用的東西。可是它可衍生出無數個具體子類別,可誕生出無數種物件來抽 象類別中的「抽象(abstract)」函數常是空虛的讓抽象類別能虛懷若谷,讓應用程 式師不斷充實它,其子孫類別就個個精明能幹抽象類別發揮無用之用的效果, 應用框架則更進一步地發揮這種效果。人們易於得意驕傲,不易虛懷若谷。同樣 地,易於創造具體類別,而不易創造出抽象類別。不過,當您懂得藉由眼前的 「無用」來換取長遠的「有用」時,創造與使用抽象類別就易如反掌了。 26 Android 應用框架原理與程式設計 36 技 1.5 框架與 OS 之關係:常見的迷思 1.5.1 迷思 許多人從空間角度去想像 OS 與應用框架之間的關係。的確,OS(如 Linux 或 Windows)像木板床,應用框架像彈簧床墊,其擺在木版床上。而應用程式則像睡 在床墊上的人。這個觀點是對的(如圖 1-4 所示)。 然而,許多人順勢推論他們之 間的互動關係如下圖: 圖 1-5 常見的迷思 乍看之下,似乎蠻合理的,其實是個迷思。請你換個角度,採取另一個觀 點,如下圖,更容易體會框架的角色和涵意,此新觀點如下圖 1-6 所示。 回想一下,您寫傳統程式時,主控權掌握在程式手中,其決定如何呼叫庫存 函數就像棒球比賽的「投手」一樣。反之,使用框架時,您的程式則擔任「捕 手」之角色。盼您在使用框架時,能有這種心理準備(Mindset) 。 第 1 章 認識應用框架 27 圖 1-6 較合理的觀點 1.5.2 藉生活實例來闡述 在 Linux / Windows 的事件驅動觀念中,OS 會不斷與應用程式溝通,不斷修 正其慣例,裨對外界的事件提供迅速反應與服務。所以 OS 頻繁地主動跟應用程 式溝通。如下圖: 圖 1-7 較合理的觀點(相當於上圖 1-6) 在日常生活中,也常見這種溝通情形。例如,大飯店(Hotel) 的溝通如下 28 Android 應用框架原理與程式設計 36 技 圖 1-8 OS 相當於服務生 再如一般商店的溝通 圖 1-9 OS 也相當於店員 當客人問道今天打幾折這是個小問題,店員按慣例(即按公司規定)來 回答8 折。當客人討價還價而問道可否打 7 折店員請教經理,但經理並未 給予特別指示,店員就依照慣例回答滿 1000 元打 7 折。 圖 1-10 店員與經理溝通 第 1 章 認識應用框架 29 假如,經理有所特別指示,則店員修正慣例如下 圖 1-11 經理的回覆 從上述生活實例中,可體會出應用框架之角色了。與顧客互動的細節幾乎都 由店員處理掉了,有必要才會打擾(呼叫)經理,所以經理較輕鬆了。以此類推, OS 與框架之關係,也相當於框架與應用程式之關係。如下圖: 圖 1-12 輕鬆的總裁 與店員的互動細節幾乎都由經理人員處理掉了,有必要才會打擾(呼叫)總 裁,所以總裁就非常輕鬆了。因此,有了像 Android 的框架(即經理),手機應用 程式(即總裁)就簡單許多了。 30 Android 應用框架原理與程式設計 36 技 平台(Platform)的迷思 一談到平台,許多人就聯想到地基,當然又聯想到漂亮的房子囉!持著這個 觀點是沒錯,但是堅持這單一觀點,常導致多項迷思: z 引導我們的眼光聚焦於漂亮的房子。 z 既然聚焦於房子,就只會以『用』態度去對待平台;就如同一位女生以『用』 的態度去對待男生,男生就不會愛她了。 z 既然聚焦於房子,就希望買來好地基,縮短建房子的工期;就如同依賴雀 巢的咖啡包、奶精,逐漸地競相開咖啡廳,造咖啡包的工業就式微了。 為了提供給您另一個觀點,筆者把 Android 平台比喻為漢堡: 芝麻:Android 應用程式(房子) 上層麵包:Android 框架(平台) 牛肉和 Cheese:框架與硬體之間 的 C 組件 底層麵包:硬體組件 每一個觀點都沒有錯,但是多了一些觀點,讓我們的判斷更精準而已。如果 您想進一步了解漢堡觀點,可先閱讀本書第 11 章。 第 2 章 應用框架魅力的泉源:反向溝通 31 第 2 章 應用框架魅力的泉源: 反向溝通(IoC: Inversion Control) 2.1 前言 2.2 認識反向溝通 2.3 主控者是框架,而不是應用程式 2.4 現代應用框架:採取廣義 IoC 觀念 2.5 框架的重要功能:提供預設行為 32 Android 應用框架原理與程式設計 36 技 2.1 前言 上章裡,您已知道應用框架之目的,也瞭解它在軟體設計上之角色。本章 裡,將專注於框架之主角抽象類別上,說明抽象類別之特性,分析「抽象」與 「具體」類別之間的雙向溝通方法。應用框架中最令人著迷之處是: 框架裡的函數,能呼叫應用程式的函數。 ﹌﹌﹌﹌﹋﹌﹌﹋﹌﹌﹌﹌﹌﹋﹌﹌﹋﹋ 這是框架與一般類別庫(或程式庫)的極重要區別。使用一般程式庫時,程 式中的函數呼叫了現成的庫存函數,但庫存函數不能反過來,呼叫您所寫的函 數。由於庫存函數設計在先,而您寫程式在後所以,您的函數呼叫庫存函數, 這種晚輩呼叫前輩的傳統溝通情形,是您已非常熟悉的了。 應用框架除了能進行傳統溝通外,還提供新潮方法:前輩呼叫晚輩。雖然前 輩(應用框架)誕生時,晚輩(應用程式)尚未誕生但是前輩有時候可預知晚 輩中的函數,就可呼叫它。這種功能,具有下述效果: 框架能事先定義許多「預設」(Default)函數。預設(default) 函數就是依 慣例而設定之函數。慣例是自動化科技的基本觀念,也是應用框架的 重要機制。例如,搭計程車時,您只要告訴計程車司機:「到士林夜 市」,司機會依照其經驗習慣而選取路線,讓您舒適抵達夜市。更重要 的是,您可特別指示司機,他會按照您(即應用程式)的意思而「修正」 其慣例。 應用程式師的主要工作是:設計函數供框架來呼叫。這些函數可 修正或取代框架中的函數。 如果程式中的函數已修正或取代預設函數,框架就呼叫程式中的 函數反之則呼叫預設函數。 這些效果正滿足當令流行的「事件驅動」(Event-Driven)軟體的需要,如下圖 2-1 所示。 第 2 章 應用框架魅力的泉源:反向溝通 33 使用者 OS(Linux/Windows) 事件 1 事件 2 事件 3 應用框架 預設 f1() 預設 f3() 預設 f4() abstract f2() 應用程式 f1() f2() f4() 訊息(呼叫) 訊息 訊息 訊息 訊息 訊息 訊息 圖 2-1 應用框架與事件驅動軟體 這是在Linux 或Windows等作業系統下,應用框架的典型雙向溝通情形,茲 將上述 4 種呼叫情形說明如下: 1. 框架中預設了 f1(),程式中也定義了 f1()。此時優先呼叫晚輩的 f1() 函數。 2. 框架「虛」設了 f2(),亦即 f2()是個抽象(abstract)函數。此時您務必 34 Android 應用框架原理與程式設計 36 技 定義 f2()來充實之,並供 Linux/Windows 或其它函數呼叫。例如 f3() 呼叫 f2()。 3. 框架預設了 f3

该用户的其他资料

  • 名称/格式
  • 评分
  • 下载次数
  • 资料大小
  • 上传时间

用户评论

0/200
    暂无评论
上传我的资料

相关资料

资料评价:

/ 359
所需积分:1 立即下载
返回
顶部
举报
资料
关闭

温馨提示

感谢您对爱问共享资料的支持,精彩活动将尽快为您呈现,敬请期待!