关闭

关闭

封号提示

内容

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

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

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

上传者: gongbingqing 2011-08-29 评分 5 0 153 21 697 暂无简介 简介 举报

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

應用框架原理與程式設計技適用於Android版本書完整範例程式碼請到網站下載:wwwmisoocom或tomkaoblogspotcom高煥堂著(年月第三版)misootwgmailcomAndroid應用框架原理與程式設計技著作權聲明:z本書已於年月出版發行。z著作權屬於高煥堂所擁有。z本ebook可整份免費自由複製流傳。z但非經作者書面同意不可以加以切割、剪輯及部分流傳。z任何商業用途皆需得到作者的書面同意。書內範例原始程式碼請到tomkaoblogspotcom或wwwmisoocom下载。第三版序言由於Android正式()版和HTCAndroid實體手機皆已經上市了因之本書也針對Android版的出爐而即時修訂成為本書的第三版。大家幾乎都聽過愚公移山的故事但是大家常把焦點擺在愚公和移山而忽略了畚「箕」的角色。禮記學記篇上有言:良弓之子必學為箕。其意思是欲做出優良的弓必先好好研究其模子(即箕)。最近許多人知道Google推出轟動武林、驚動萬教的Android手機平台。但是幾乎都只關心如何在該新平台上開發應用程式卻忽略了Android是個框架(Framework)而框架裡含有成百上千個「箕」類(註:基類是大陸對SuperClass的譯詞)。基於「良弓之子必學為箕」的精神本書先教您正確認識框架(箕)之原理然後才介紹如何善用畚箕來開發出優良的Android應用程式(良弓)。本書共分為篇:※第一篇:介紹應用框架概念、原理和特性。※第二篇:闡述應用框架之設計技巧。亦即如何打造應用框架。(註:如果你的職務是「使用」Android框架來開發應用程式的話可以跳過本篇直接進入第三篇。)※第三篇:說明及演練Android應用程式設計的技。※第四篇:介紹Android框架與硬體之間C組件的開發流程及工具。筆者並不是說Android的應用程式師是愚公而旨在說明手機軟體領域的三個主要分工角色:z做畚箕者:如Andriod開發團隊。z畚箕買主:如Google公司。z挑畚箕者:如Android應用程式師。本書也不把您設定為應用程式師單一角色而是盼望能協助您開拓更寬廣的未來無論在上述的任何角色都能如魚得水輝煌騰達。於此誠摯地祝福您!高煥堂謹識於tomkaoblogspotcomAndroid應用框架原理與程式設計技目錄第一篇良弓之子必學為箕(框架)~禮記學記~第章認識應用框架,何謂應用框架框架的起源框架的分層框架的「無用之用」效果框架與OS之關係:常見的迷思第章應用框架魅力的泉源:反向溝通,前言認識反向溝通主控者是框架而不是應用程式現代應用框架:採取廣義IoC觀念框架的重要功能:提供預設行為第二篇無之(抽象)以為用~老子:無之以為用~第章如何打造應用框架,基礎手藝:抽象(無之)與衍生(有之)打造框架:細膩的抽象步驟基本步驟細膩的手藝(一):比較資料成員細膩的手藝(二):比較函數成員細膩的手藝(三):將抽象類別轉為介面第三篇有之(繼承)以為利~老子:有之以為利~第章應用程式設計的基礎手藝技,#:如何建立Menu選單#:如何呈現按鈕(Button)之#:如何呈現按鈕(Button)之#:如何進行畫面佈局(Layout)#:如何呈現List選單之#:如何呈現List選單之#:如何運用相對佈局(RelativeLayout)#:如何運用表格佈局(TableLayout)#:如何動態變換佈局#:如何定義自己的View#:如何定義一組RadioButton#:一個Activity啟動另一個Activity第章UseCase分析與畫面佈局之規劃,善用UseCase分析以Android實踐UseCase分析之策略第章UseCase分析的實踐(策略A):技,#:使用Menu和starActivity()實踐之#:使用starActivityForResult()替代startActivity()#:使用ListView替代Menu#:以ListActivity替代Activity父類別#:改由xml檔案定義畫面佈局#:使用onResume()函數Android應用框架原理與程式設計技第章UseCase分析的實踐(策略B):技,#:一個Activity支持兩個畫面佈局#:將兩個畫面佈局合併為一第章介紹關聯式資料庫與SQLite,何謂關聯式資料庫建立一個表格(Table)從表格中查詢資料關聯資料模型關聯的種類兩個表格之互相聯結SQL子句:加總及平均SQL子句:分組第章資料庫手藝:技,#:SQLite基本操作#:讓SQLite披上ContentProvider的外衣#:細說SQLite與ContentProvider#:讓SQLite配合onCreate()、onResume()而來去自如#:如何實現商業交易(Transaction)第章進階手藝技,#:如何定義BroadcastReceiver子類別#:如何撰寫Service子類別#:如何使用ProgressDialog物件#:如何捕捉按鍵的KeyEvent#:善用UMLStatechart嚴格控制系統的狀態#:如何使用MapView#:如何使用WebView#:如何自動化操作畫面輸入#:如何活用COR設計樣式#:如何活用State設計樣式第四篇第三十六技:為箕是上策第章如何撰寫框架與硬體間之C組件,#:如何撰寫框架與硬體間之C組件發展AndroidC組件的經濟意義附錄A:A如何安裝Windows平台的AndroidSDK版及EclipseA如何離線安裝AndroidSDK版及EclipseA如何著手撰寫Android應用程式A如何執行Android應用程式A如何安裝LinuxUbuntu平台的AndroidSDK版及EclipseA如何安裝CCCrossCompiler附錄B:B高煥堂於Omia行動應用服務聯盟會議上演講的講義B歡迎一起推動「百萬個小Google計畫」B迎接IT第三波:移(行)動時代B高煥堂教你最先進的「現代軟體分析與設計」B認識Android模擬器的操作EclipseAndroid應用框架原理與程式設計技本書由Misoo團隊創作與出版Misoo技術團隊介紹由高煥堂領軍的Misoo團隊與大陸、俄羅斯、日本專家所組成的跨國嵌入式聯合設計(Codesign)團隊。Misoo的開放合作態度贏得國際的好感和商機。ƒ位於風景秀麗的Voronezh,Russia例如跨國團隊成功地將俄羅斯研發多年的頂級Linter嵌入式資料庫系統納入Android手機裡執行成為Android的嫡系成員之一。此外Misoo團隊開發的Android遊戲應用程式也順利外銷歐美諸國如下圖:Russia還有手機線上遊戲等等如下圖:Android應用框架原理與程式設計技跨國團隊經驗豐富、技術精湛嵌入式開發成功經驗包括:ƒ客製化影音播放器(videoplayer)開發ƒ嵌入式資料庫管理引擎(DBMS)開發ƒ行動平台GPS系統開發(Blackberry,WinCE,JME)ƒ電信業的專屬無線協定(wirelessprotocol)的開發ƒ學習內容播放系統開發(Flashbased)基於Misoo的開放精神高煥堂將本書製作成ebook供大家免費閱讀希望本書在這千載難逢的大好機會裡能陪伴諸位的成長與茁壯。此外高煥堂又把一些跨國團隊的實務經驗和技術加以編輯並出版成書或成為企業培訓課程的講義將進一步與大家分享。如何與Misoo跨國團隊技術合作呢開發專案(項目)合作:z歡迎直接與Misoo團隊聯絡:TEL:()Email:misootwgmailcom公開教育訓練課程或企業團隊內訓:z台北地區歡迎與Misoo團隊聯絡:TEL:()Email:misootwgmailcomz上海地區歡迎與祝成科技洽詢:TEL:Email:svsoftcompasscom歡迎多多指教Misoo網頁:tomkaoblogspotcom或wwwmisoocomAndroid應用框架原理與程式設計技歡迎報名參加高煥堂主講的GoogleAndroid技術教育訓練課程詳細課綱與日期請上網wwwmisoocom服務電話:()Email:misootwgmailcom高煥堂的第本Android暢銷書籍(天瓏網路書局熱賣中)***詳細目錄請看第頁或上網wwwandroidnet***第章認識應用框架第一篇良弓之子必學為箕(框架)~~禮記學記~~良弓來自好的框架(箕)。優良的應用程式來自美好的應用框架。優秀的Android程式師必先學習應用框架的原理。Android應用框架原理與程式設計技第章認識應用框架何謂應用框架框架的起源框架的分層框架的「無用之用」效果框架與OS之關係:常見的迷思第章認識應用框架何謂應用框架顧名思義應用框架是某特定應用領域(Domain)中程式間的共同結構。讓該領域中的程式師們依共同結構來發展程式使程式間具有一致性增加了程式的清晰度以降低程式的設計與維護費用。所謂「共同結構」包括了通用的類別、物件、函數及其間的穩定關係。由於框架是通用的大家能共享(Share)之增加了工作效率提升了軟體師的生產力(Productivity)。茲拿個簡單例子來說吧兩個長方形分別為直角及圓角如下首先分辨它們的異同點然後將其共同部分抽離出來如下我們稱這過程為「抽象」(Abstraction)。並稱此圖形為「抽象圖」其只含共同部分而相異部分從缺。原有的直角及圓角方形為完整圖形稱為「具體圖」。一旦有了抽象圖就可重複使用(Reuse)它來衍生出各種具體圖且事半功倍例如用途衍生直角方形。拷貝一份抽象圖在圖之四角分別加上、、及就成為直角方形了如下Android應用框架原理與程式設計技用途衍生圓角方形。拷貝一份抽象圖在圖之四角分別加上、、及就成為圓角方形了如下用途衍生球角方形。拷貝一份抽象圖在圖之四角各加上就成為上述簡單例子中說明了兩個重要動作抽象從相似的事物中抽離出其共同點得到了抽象結構。衍生以抽象結構為基礎添加些功能成為具體事物或系統。同樣地在軟體方面也常做上述動作抽象在同領域的程式中常含有許多類別這些類別有其共同點。程式師將類別之共同結構抽離出來稱為抽象類別(AbstractClass)。衍生基於通用結構裡的抽象類別加添些特殊功能成為具體類別再誕生物件。第章認識應用框架所以「抽象類別」存在之目的是要衍生子類別而不是由它本身來誕生物件。由於抽象類別本身不誕生物件所以有些函數並不完整。反之如果類別內之函數皆是完整的而且要用來誕生物件就稱它為具體類別(ConcreteClass)。上述簡單例子中說明了兩個重要動作抽象從相似的事物中抽離出其共同點得到了抽象框架。衍生以抽象框架為基礎添加些功能成為具體事物。其中「抽象」結果的好壞決定於程式師的領域知識及其敏銳觀察力。這是個複雜的動作其過程愈精細愈能得到穩定而通用的框架。一旦有了穩定且彈性的框架衍生具體類別的動作就輕而易舉了。框架中除了抽象類別外還有類別間之關係。未來衍生出子類別並誕生物件其物件就會依循既定的關係來溝通、協調與合作。因之框架說明了物件的溝通與組織方式就如同「食譜」敘述著食物料理方法。不過食譜並不能完全比喻框架只比喻一部分而已。食譜只敘述料理方法並無真正的蔥、牛肉等。然而框架含有類別、函數、以及物件等真正的程式。因之有人拿「未插完的花盆」來比喻框架似乎更傳神插花老師先插上背景花並留下空間任學生發揮繼續插完成。框架設計師提供了基本類別也預留空間讓您發揮繼續衍生出子類別。從上所述可知框架包括了一群抽象類別類別內有函數函數內有指令但有些函數內的指令從缺預留給應用程式師補充之。抽象類別間之穩定關係。然而現在市面上的框架不只含抽象類別且含有具體類別、函數、及物件。實際上框架已涵括了傳統類別庫(ClassLibrary)之功能使得大家不易區分框架與類別庫之差別了。只能在理論上區分兩者如下Android應用框架原理與程式設計技應用框架類別庫目的讓應用程式師衍生出具目的讓程式師拿現成類別來誕體類別衍生時可修正生物件類別並未預留空類別才誕生物件。間給程式師來修正。應用框架中的類別的函數常應用程式的函數只能呼叫類別庫呼叫應用程式中的函數。中的函數反之不可。含有類別間之關係其預設了類別是獨立的並未設定物件間物件間的互助合作關係。的溝通方式。物件常含預設計行為(Default物件的行為皆是固定的無法修Behavior)預設行為可讓應正之。用程式師修正之。在實用上許多人已將它們混為一談了。框架的起源框架(Framework)的歷史已經有多年了可追溯到代Smalltalk語言的MVC到了AppleMacintosh時代的MacApp框架開始大放異彩。逐步演進到今天的NetFramework其應用範圍愈來愈大已經成為資訊服務系統的共通核心框架了。多年來框架的基本原理一直都沒有改變其基本結構也沒有太多變化其基本用法也是老樣子只是應用的場合及範圍不斷地擴大經驗不斷累積中。在框架的發展過程中最具有代表性的是年代初期Smalltalk的MVCFramework年代中期Macintosh電腦的MacAppFramework年代初期VisualC的MFCFramework年代中期IBM的SanFranciscoFramework年Microsoft的NetFramework第章認識應用框架年Google的Android框架茲簡介如下:Smalltalk的MVC框架應用框架的起源中大家最熟悉的是Smalltalk語言中的MVC(ModelViewController)框架。其讓Samlltalk程式師迅速建立程式的使用者介面(UserInterface)。從年代的Smalltalk到年代SmalltalkV其使用者介面皆依循這個著名的框架。典型的MVC框架包括三個抽象類別Model、View及Controller。應用程式從這些抽象類別衍生出具體類別並誕生物件。其物件間的關係如下圖著名的MVC框架model物件負責管理資料或文件它可對應到數個view物件每個view物件顯示出model物件的某一方面每個view物件有個相對應的controller物件其負責解釋使用者輸入的訊息如移動滑鼠等等。使用者輸入訊息時controller依訊息去要求model處理文件資料也會要求view物件更新畫面。一旦model物件中的資料更動了model物件會通知各controller及view物件各view物件會向model取得新資料然後更新畫面。因之典型MVC框架是由一群model、view及controller物件互助合作做為使用者與應用程式的溝通介面。Android應用框架原理與程式設計技MacApp框架年代中期已有多種商業性的應用框架上市其中最流行的是Apple公司的MacApp框架其能協助發展Macintosh電腦上的應用程式。這應用程式包括個部分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物件要求它們採取進一步的行動。第章認識應用框架雖然MacApp框架中定義了許多類別來誕生上述的物件然而應用程式中通常可直接使用現成的window、frame及command等類別和物件。至於application、document及view物件常須加以修正才能合乎特定的應用場合。因之應用程式必須分別由TDocument、TView及TApplication抽象類別衍生出具體子類別然後才誕生document、view及application物件。MacApp框架成功地結合了螢幕視窗功能並提供親切的軟體發展環境其應用程式呈現可塑性能隨需求而不斷修正。這成功經驗對後來的應用框架的發展產生了極大的影響。VisualC的MFC框架在年~年之間BorlandC上市並提供了OWL應用框架隨後MicrosoftCC及VisualC上市提供了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等基本類別。應用程式必須從這些類別衍生出具體子類別並誕生物件互相溝通與合作。其物件間的關係如下:Android應用框架原理與程式設計技圖MFC的DocumentView框架Windows將使用者所輸入的訊息傳給mainfrm物件由mainfrm再轉達給view、app或document物件。當document物件內的資料有所異動時document會通知view(程式可含許多view)物件來取得新資料以便更新視窗內容。IBM的SanFrancisco框架上述的MVC、MacApp及MFC皆是擔任系統層次的核心任務如電腦網路、分散式資料庫的管理工作。到了年代中期框架開始擴展到商業資訊服務的層面就是俗稱的應用框架(即ApplicationFramework)又稱為商業的領域框架(即BusinessDomainFramework)。其中最著名的是IBM公司的SanFrancisco框架。IBM的SanFrancisco含有商業服務的企業核心流程如ERP的訂單循環、會計的應收應付循環等如下圖所示。此外也含有像「客戶」及「帳戶」等核心的企業物件及物件之間的關係。第章認識應用框架應用程式核心企業流程BusinessFinancialsOrderManagement共同企業物件基礎服務JavaVMUnix、NT等平台圖IBM的SanFrancisco元件框架IBM的SanFrancisco框架所提供的是非客製化的商業核心服務讓其它資訊服務廠商進行開發客製化的商業應用服務。微軟的NetFramework到了年微軟所推出的NetFramework其格局更擴大到整個企業(Enterprise)的分散式框架甚至包括以Webservice為核心的靠企業大型分散式框架。例如它提供XMLWebService、MSMQ非同步的訊息服務、Security服務等。在NetFramework裡含有上千個既有的類別能透過繼承或介面委託方式使用這些類別的功能或服務。Google的Android框架於年月Google推出的Android應用框架其適用於「手機網路」的新市場上。除了它是一個新的應用之外更珍貴的是其程式碼採開放策略讓大家能一窺其全貌給予軟體開發者很好的學習機會。Android應用框架原理與程式設計技框架的分層由於框架介於應用程式與系統程式之間能大量地重複使用(Reuse)並可不斷修正之因而提升了應用程式之彈性也能提升系統程式之彈性。它本身也可分為兩個層級如下圖:圖應用框架之層次例如在多平台(Multiplatform)系統上彈性是極重要的。在這個層次裡框架提供了支援性的服務通稱為支援性框架讓人們不但能使用作業系統的API函數也可以修正之裨更符合企業的需要。這種支援性的框架其觀念與一般應用框架相同只是它負責系統層次的任務如電腦網路、分散式資料庫的管理工作。一般應用程式師並不直接修正支援性框架而是由系統維護人員來修正之。在應用層次上許多企業已著手創造自己的專業框架整合公司裡的軟體系統。如果您把應用框架比喻為「食譜」則不難想像到各領域(Domain)的產業都可能發展出應用框架了。例如歐洲汽車廠就聯合發展出AUTOSAR應用框架它們就如同食譜配方是餐廳賺錢的祕方。因之在支援性框架的協助下許多專精於某領域的公司設計出各式各樣的應用框架像貿易、運輸、醫療、手機第章認識應用框架等例如Android就是手機網路的應用框架讓各手機廠商可經由修正及補充來創造出「獨家」的應用系統成為自己公司中的重要資源。例如Android就包含了支援性框架和手機專業應用框架。框架的「無用之用」效果小樹的用途少人們不理睬它、不砍伐它、才有機會長成有用之巨木此為「無用」之用老子說過:「人皆知有用之用而莫知無用之用」這與框架觀念是一致的。數千年前老子提出了這「有、無」哲理從無為狀態中創造出有為的積極效果。像房子的中間、門、窗皆是空的才能供人們進出、居住與透透空氣。其積極效果是日後依新環境的條件而加以調整、充實創造出多樣化的用途。例如畚箕的中間是空、虛的才能裝泥土、垃圾等各式各樣的東西。此外畚箕的空無創造了畚箕的重複使用性(Reusability)裝完了泥土倒掉之後還可拿來裝垃圾等不斷重複使用之一直到壞掉為止。不僅上述的樹木、房子、畚箕等東西深含虛無之用哲理在人們的精神修養上也常見同樣哲理。例如古之賢者常教導年輕人應該「虛」懷若谷才能不斷虛心求教不斷吸收新知識不斷充實與成長成為有用之人。反之志得意滿的年輕人常不願虛心吸收新知識常在不知不覺中變為新環境中的古典人物為不斷變化的潮流所淘汰。應用框架中的主角抽象類別並非具體的類別不能用來誕生物件看似無用的東西。可是它可衍生出無數個具體子類別可誕生出無數種物件來抽象類別中的「抽象(abstract)」函數常是空虛的讓抽象類別能虛懷若谷讓應用程式師不斷充實它其子孫類別就個個精明能幹抽象類別發揮無用之用的效果應用框架則更進一步地發揮這種效果。人們易於得意驕傲不易虛懷若谷。同樣地易於創造具體類別而不易創造出抽象類別。不過當您懂得藉由眼前的「無用」來換取長遠的「有用」時創造與使用抽象類別就易如反掌了。Android應用框架原理與程式設計技框架與OS之關係:常見的迷思迷思許多人從空間角度去想像OS與應用框架之間的關係。的確OS(如Linux或Windows)像木板床應用框架像彈簧床墊其擺在木版床上。而應用程式則像睡在床墊上的人。這個觀點是對的(如圖所示)。然而許多人順勢推論他們之間的互動關係如下圖:圖常見的迷思乍看之下似乎蠻合理的其實是個迷思。請你換個角度採取另一個觀點如下圖更容易體會框架的角色和涵意此新觀點如下圖所示。回想一下您寫傳統程式時主控權掌握在程式手中其決定如何呼叫庫存函數就像棒球比賽的「投手」一樣。反之使用框架時您的程式則擔任「捕手」之角色。盼您在使用框架時能有這種心理準備(Mindset)。第章認識應用框架圖較合理的觀點藉生活實例來闡述在LinuxWindows的事件驅動觀念中OS會不斷與應用程式溝通不斷修正其慣例裨對外界的事件提供迅速反應與服務。所以OS頻繁地主動跟應用程式溝通。如下圖:圖較合理的觀點(相當於上圖)在日常生活中也常見這種溝通情形。例如大飯店(Hotel)的溝通如下Android應用框架原理與程式設計技圖OS相當於服務生再如一般商店的溝通圖OS也相當於店員當客人問道今天打幾折這是個小問題店員按慣例(即按公司規定)來回答折。當客人討價還價而問道可否打折店員請教經理但經理並未給予特別指示店員就依照慣例回答滿元打折。圖店員與經理溝通第章認識應用框架假如經理有所特別指示則店員修正慣例如下圖經理的回覆從上述生活實例中可體會出應用框架之角色了。與顧客互動的細節幾乎都由店員處理掉了有必要才會打擾(呼叫)經理所以經理較輕鬆了。以此類推OS與框架之關係也相當於框架與應用程式之關係。如下圖:圖輕鬆的總裁與店員的互動細節幾乎都由經理人員處理掉了有必要才會打擾(呼叫)總裁所以總裁就非常輕鬆了。因此有了像Android的框架(即經理)手機應用程式(即總裁)就簡單許多了。Android應用框架原理與程式設計技平台(Platform)的迷思一談到平台許多人就聯想到地基當然又聯想到漂亮的房子囉!持著這個觀點是沒錯但是堅持這單一觀點常導致多項迷思:z引導我們的眼光聚焦於漂亮的房子。z既然聚焦於房子就只會以『用』態度去對待平台就如同一位女生以『用』的態度去對待男生男生就不會愛她了。z既然聚焦於房子就希望買來好地基縮短建房子的工期就如同依賴雀巢的咖啡包、奶精逐漸地競相開咖啡廳造咖啡包的工業就式微了。為了提供給您另一個觀點筆者把Android平台比喻為漢堡:芝麻:Android應用程式(房子)上層麵包:Android框架(平台)牛肉和Cheese:框架與硬體之間的C組件底層麵包:硬體組件每一個觀點都沒有錯但是多了一些觀點讓我們的判斷更精準而已。如果您想進一步了解漢堡觀點可先閱讀本書第章。第章應用框架魅力的泉源:反向溝通第章應用框架魅力的泉源:反向溝通(IoC:InversionControl)前言認識反向溝通主控者是框架而不是應用程式現代應用框架:採取廣義IoC觀念框架的重要功能:提供預設行為Android應用框架原理與程式設計技前言上章裡您已知道應用框架之目的也瞭解它在軟體設計上之角色。本章裡將專注於框架之主角抽象類別上說明抽象類別之特性分析「抽象」與「具體」類別之間的雙向溝通方法。應用框架中最令人著迷之處是:框架裡的函數能呼叫應用程式的函數。﹌﹌﹌﹌﹋﹌﹌﹋﹌﹌﹌﹌﹌﹋﹌﹌﹋﹋這是框架與一般類別庫(或程式庫)的極重要區別。使用一般程式庫時程式中的函數呼叫了現成的庫存函數但庫存函數不能反過來呼叫您所寫的函數。由於庫存函數設計在先而您寫程式在後所以您的函數呼叫庫存函數這種晚輩呼叫前輩的傳統溝通情形是您已非常熟悉的了。應用框架除了能進行傳統溝通外還提供新潮方法:前輩呼叫晚輩。雖然前輩(應用框架)誕生時晚輩(應用程式)尚未誕生但是前輩有時候可預知晚輩中的函數就可呼叫它。這種功能具有下述效果:框架能事先定義許多「預設」(Default)函數。預設(default)函數就是依慣例而設定之函數。慣例是自動化科技的基本觀念也是應用框架的重要機制。例如搭計程車時您只要告訴計程車司機:「到士林夜市」司機會依照其經驗習慣而選取路線讓您舒適抵達夜市。更重要的是您可特別指示司機他會按照您(即應用程式)的意思而「修正」其慣例。應用程式師的主要工作是:設計函數供框架來呼叫。這些函數可修正或取代框架中的函數。如果程式中的函數已修正或取代預設函數框架就呼叫程式中的函數反之則呼叫預設函數。這些效果正滿足當令流行的「事件驅動」(EventDriven)軟體的需要如下圖所示。第章應用框架魅力的泉源:反向溝通使用者OS(LinuxWindows)事件事件事件應用框架預設f()預設f()預設f()abstractf()應用程式f()f()f()訊息(呼叫)訊息訊息訊息訊息訊息訊息圖應用框架與事件驅動軟體這是在Linux或Windows等作業系統下應用框架的典型雙向溝通情形茲將上述種呼叫情形說明如下:框架中預設了f()程式中也定義了f()。此時優先呼叫晚輩的f()函數。框架「虛」設了f()亦即f()是個抽象(abstract)函數。此時您務必Android應用框架原理與程式設計技定義f()來充實之並供LinuxWindows或其它函數呼叫。例如f()呼叫f()。框架預設了f

精彩专题

职业精品

上传我的资料

热门资料

资料评价:

/ 359
所需积分:1 立即下载

意见
反馈

返回
顶部

Q