【文章內容簡介】 啟動，調用 ()來結束，這種方式無論調用了多少次 startService()方法，都只需要調用一次 stopService()方法來停 止服務。第二種方式是建立一個到服務對象的鏈接，通過調用這個鏈接來獲得服務 。 這 個 鏈 接 通 過 () 方 法 建 立 ， 并 通 過 調 用()方法來關閉。多個用戶可以綁定至同一個服務提供對象。 一個 Service 也具有一定的生命周期，如圖 27 所示 。 圖 27 service 的生命周期 從上圖可以看出， service 主要有以下兩個循環(huán)過程： 12 1） 完整的生命周期 ： 從 onCreate()開始到 onDestroy()結束，在 onCreate()函數中完成初始化，在 onDestroy()函數中釋放所有的資源。例如一個音樂播放程序，可以在 onCreate()中創(chuàng)建音樂播放線程，在 onDestroy()中終止這個線程。 2） 活躍的生命周期 ： 從 onStart()開始，在這個函數中處理傳遞給 startService()的 Intent 對象。例如對于一個音樂播放程序，會在 Intent 中找到需要播放的音樂曲目。 （三） BroadcastReceiver： 用來接收廣播信息，并給出相應的處理結果。這些廣播信息也許來自于系統(tǒng)自身，如電池電量低、拍攝照片、來電 話或短信等 ； 也許來自應用程序，比如下載完成時發(fā)送通知來告知用戶。每個應用程序擁有的廣播接收器沒有限制，并且可以對任意感興趣的通知進行響應，廣播接收器也不具有用戶界面。廣 播接 收器 的生 命周 期很短 ，只 有在 廣播 消息抵 達接 收器 并且 接收 器中的onReceive()函數被調用時處于活躍狀態(tài)，一旦 onReceive()函數返回后，廣播接收器就處于失活 狀態(tài)。 （四） Intent：協(xié)助前面提到的三種組件完成通信過程，一個 Intent 由動作(Action）、數據 (Data)、分類 (Category)、類型 (Type)、組件 (Component)和擴展信息 (Extra）等內容組成，系統(tǒng)根據 Intent 中所攜帶的不同描述信息來決定將此 Intent交給哪個組件以及該組件獲得 Intent 后要采取的動作。 （五） Content Provider：為應用程序之間共享數據提供了一個統(tǒng)一的接口并隱藏了具體的數據來源， Android 系統(tǒng)中為一些常見的應用 (如聯系人、音樂、圖像等 )定義了相應的 Content Provider，調用者通過相應的 URI來對數據進行訪問。通常 Content Provider 將一個應用程序的數據封裝，并向需要使用該數 據的其他應用程序賦予權限，這樣就可以使得數據在多個程序之間共享。需要注意的是， Content Provider 是基于權限控制的，這種做法可以提高數據的安全性。 程序界面開發(fā) Android 系統(tǒng)為開發(fā)者提供了豐富的可視化界面設計組件，包括菜單、對話框、按鈕、文本框等，其中最主要的界面元素包括以下三類 。 1） 視圖組件 (View： 是基類 的一個實例，用來存儲屏幕上特定矩形內的布局和內容屬性，由視圖又衍生出了一個子類 Widgets(窗體 控件 )，用來處理屏幕 區(qū)域的測量和繪制，常用的 Widget 包括 Text， EditText， Button，CheckBox 和 ScrollView 等。 2） 視圖容器 (ViewGroup： 是基類 的一個實例，用來承載和管理一組下層的視圖和其他視圖組，通常稱為 View 的容器。 3） 布局管理 ： Android 使用布局管理器來管理應用程序中各用戶界面的組件，這樣做的好處是可以避免因手機分辨率、尺寸等的差異導致編寫的應用程序無法移 13 植，因為布局管理器能根據運行平臺調整組件的大小。所有的布局管理器都是ViewGroup 的子類，圖 28 表示布局管理器中各類的關系。 圖 28 Android 布局管理器的類圖 1） LinearLayout(線性布局 )： 該布局中元素之間成線性排列，常用的布局有水平布局和垂直布局。 2） RelativeLayout(相對布局 )： 該布局中元素之間根據相對位置排列，即在指定一個元素位置時往往會以它的父元素或其它元素的位置作為參照，來決定當前元素的位置，這種布局方式相對隨意，沒有規(guī)律性，但必須保證在使用之前其參照物己經存在。 3） AbsoluteLayout(絕對布局 )： 該布局中元素之間根據坐標排列，即將整個手機劃分成坐標系，通過指定坐標系中的兩個偏移量來決定元素的位置。 4） FrameLayout(幀布局 )： 該布局為每個加入的組件都創(chuàng)建了一個空白區(qū)域 (一幀 )，這些幀會根據 gravity 屬性自動對齊，這樣會形成組件疊加的效果。 5） TableLayout(表格布局 )： 該布局中元素之間的排列由表格決定，表格的行和列通過添加 TableRow 或其他組件來控制，通常加入一個 TableRow 或是一個組件都代表一行，表格的寬度取決于父容器的寬度，這種布局只是 實現方式與表格類似，但元素之間并沒有實際的分界線。 Android 中提供了兩種方式來利用上面的組件設計布局，一是在 XML布局文件中通過設置 XML 屬性進行控制，二是在 Java 程序中通過調用函數進行控制，也可以將這兩種方法組合起來使用。 Android 推薦使用 XML 布局文件的方式來控制用戶界面的顯示，這樣做不僅簡單明了，還可以將視圖控制邏輯從代碼中剝離出來，放入一個單 14 獨的文件中進行控制，更好的體現了 MVC 原則。 Android 系統(tǒng)數據存儲方式 Android系統(tǒng)一共提供了四種數據存儲方式，分別是 SharedPreferences(通過鍵值二元組存儲簡單數據 )、文件 (存儲較大規(guī)模的數據 )、 SQLite數據庫 (存儲結構化數據 )和 ContentProvider(用于應用程序之間的數據共享 )，下面詳細介紹每一種方式的具體使用方法和使用場合。 1） SharedPreferences： 用鍵 /鍵值形式的二元組來存儲數據，支持的數據類型有 Boolean， string， float， long和 integer，通常用來存儲默認值、實例變量、 UI狀態(tài)和用戶設置等。每個應用程序 Context均有一個 SharedPreferences對象，通過 getSharedPreferences()函數來獲取該對象，通過 getBoolean()， getFloat()和 getInt()等函數讀取該對象中存儲的數據，這些函數一共有兩個參數，第一個參數為鍵 /鍵值對中的鍵，第二個參數為指定鍵對應的鍵值，如果該鍵值不存在則以默認的函數返回值代替。修改 SharedPreferences對象中的內容需要用到 putBoolean() ，putFloat()和 putInt()等函數，并且在修改完后還要調用 mit()函數，否則修改無效。 2） 文 件操作 ： Android上層應用程序是用 Java語言編寫的，在 Java的 I/O包中提供了大量的文件讀寫函數，如 ， ， ， Android對這些函數都有良好的支持，除此之外，Android還提供了 openFileInput和 openFileOutput這兩個函數用來簡化對文件的讀寫操作，與 Java I/O包中的函數所不同的是，這兩個函數只能操作當前應用程序所在目錄的文件。 3） SQLite數據庫 ： SQLite是一種開源的、與底層無關的，輕量級的數據庫，最大支持 2048GB的數據存儲，與其它大多數 SQL數據庫不同的是， SQLite沒有獨立的服務進程。 SQLite中的數據庫文件是跨平臺的，可以在 32位和 64位系統(tǒng)之間，甚至BigEndian和 LittleEndian兩種不同的架構之間自由的拷貝數據， SQLite數據庫被用在大量的消費類電子產品中。 SQLite數據庫具有以下特點 ： 1） 無需配置 ： 直接解壓可執(zhí)行文件即可運行。 2） 沒有服務進程 ： 不需要提交到服務器處理后再返回結果。 3） 單個數據文件 ： 將用戶數據存儲在一個文件中。 4） 數據文件可跨平臺移植 ： 不受操作系統(tǒng)位數和架構的限制。 5） 緊湊 ： 不需要系統(tǒng)提供太大的資源，占用不到 1M的內存空間就可運行。 6） 事務性 ： 采用獨立事物處理機制，遵守 ACID (Atomicity， Consistency，Isolation， Durability)原則。使用數據庫的獨占性和共享鎖處理事務，這樣既允許多個進程并發(fā)讀取數據庫中的數據，又能保證最多只有一個進程寫數據，可以有 15 效地防止讀臟數據、不可重復讀、丟失修改等異常的發(fā)生。 3 基于 Android 平臺的教學點名軟件設計 需求分析 需求分析的任務是調查應用領域，對應用領域中各種應用的信息要求和操作要求進行詳細分析，形成需求分析說明書。需求分析的目標是給出應用領域中的數據項、數據項之間的關系和數據操作任務的詳細定義，為數據庫的概念設計、邏輯設計和物理設計奠定堅實的基礎，為優(yōu)化數據庫的邏輯結構和物理結構提供可靠依據。 點名系統(tǒng)的主要特點和要求 本點名系統(tǒng)主要是針對學校點名而研發(fā)的。學校點名不同于普通的企業(yè)單位點名。其特點是體系龐大，班級眾多，上課時間各不相同。而且有時會由于臨 時原因調課，而且在非上課時間學生的流動性比較大，容易在非上課時間或由非點名對象對點名造成干擾。由于學生的出勤情況是和期末的成績掛鉤，因此點名記錄的時效性比較長。任課教師需要隨時了解自己的課程學生的出勤情況，同時管理人員也要能快速夠統(tǒng)計學生們的出勤情況，為了讓學生們能夠改正不規(guī)范的學習態(tài)度，要及時給予學生們缺勤的警告和處理。 學校點名系統(tǒng)的主要要求就是能夠考察記錄學生的上課出勤、曠課、早退、請假的情況。首先點名系統(tǒng)應具有區(qū)間劃分功能，能夠準確的劃分上課班次、時間從而對不同的課時進行點名 。其次是不能占用上課時 間對學生進行點名，為了提高效率節(jié)約時間，對點名的速度也是由要求的 。然后就是能對學生進行準確識別，杜絕代點名現象 。由于非正常出勤在時間上有一定的相似度，因此點名系統(tǒng)必須能區(qū)分學生的曠課、遲到、早退、請假情況，遇到學生請假的情況，教師可以在系統(tǒng)中提前輸入請假信息不予點名，或者如果請假學生己經被記錄為缺勤，老師可以視具體情況更改出勤信息，同樣，如果遇到節(jié)假口或者特殊事件造成的集體缺勤、遲到或者早退的情況，系統(tǒng)管理員能在事前或者事后進行記錄修改 。在非點名時間不記錄任何點名輸入，以排除非點名時間的輸入對點名的干擾，同 時要求能分辨出數據庫中不存在的指紋，排除非點名對象對點名的干擾 。保存以往點名記錄，可供管理員查詢，任課教師可查詢本人課程學生以往的出勤情況，被點名的學生可以查詢本人以往的點名情況。 技術方面的難點在于，由于高校非固定教室的教學模式，造成需要在各個上課點前，服務器將給定教室內上課學生的指紋在課前分發(fā)到各教室，點名后又需要將點名情況傳回服務器，通信要求、并發(fā)要求、及異常處理問題。 設計目標及原則 1） 系統(tǒng)設計目標 學生上下課方便直觀地掃描二維碼進行點名 。簡捷處理請假、審核，節(jié)口設置等 16 相關事項 。如實反映每個人的點名情況，杜絕舞弊 。管理員可隨時查詢點名記錄與課表檔案 。管理員可方便地統(tǒng)計、打印或導出點名統(tǒng)計結果 。經濟合理的運營成本。 2） 系統(tǒng)設計原則 先進性 :采用當前先進的技術和成熟穩(wěn)定的設備 。 安全性 :數據的安全性與課表資料的安全性 。 實用性 :合理的配置，合適的功能使整個系統(tǒng)運行穩(wěn)定、可靠并且成本最省 。 方便性 :功能完善，軟件操作清晰簡單 。 可擴展性及易維護性原則 :系統(tǒng)在容量和功能上考慮了用廣將來的需求增長，可以隨意地增加新的設備或新的系統(tǒng)，并保證使用的一致性 。 開放性 :為保證其他設備 的協(xié)同運行，同時考慮到投資者的長遠利益，本系統(tǒng)必須是開放系統(tǒng)，并結合相關的國際標準或工業(yè)標準執(zhí)行。 系統(tǒng)體系結構分析 管理信息系統(tǒng)的平臺體系結構發(fā)展歷史從單機單用戶發(fā)展到文件 /服務器 (F/S)模式，再到客戶機 /服務器 (C/S)模式和瀏覽器 /服務器 (B/S)模式。 在本系統(tǒng)中，結合實際使用情況，采用 C/S和 B/S結合的體系結構，以數據庫為服務器端，其它均為客戶端。數據庫服務器主要為點名資料，點名數據的存取提供服務。 Web服務器為請假管理、點名數據的查詢輸出提供服務。需要對數據庫進行頻繁操作例如 添加、修改資料的人員使用 C/S客戶端，這樣客戶端功能比較強、安全系數也高。查詢模塊中則使用 B/S，客戶端進行數據的查詢，這樣客戶端比較靈活，有 IE瀏覽器，就可以通過網絡查詢每個人的點名情況，可以不受環(huán)境限制。如此處理，可充分發(fā)揮各種模式的優(yōu)越性，避免