第一篇：安卓學習心得
android學習心得
-----093380117計算機應用（1）張峯
1.關於activity
1. 在一個activity中使用多個view
如果把activity看作mvc中的control？它負責管理ui和接受事件（包括用户的輸入），雖然説一個activity通常對應一個屏幕，但事實上，我們是可以只用一個activity管理多個不同的view來實現簡單的邏輯。
首先，我們增加一個新的資源描述layout/。
除了一個“hello中國”以外，增加一個按鈕可以返回前一個界面。然後，在代碼中我們要為hellotwo增加兩個方法，setviewonecommand和setviewtwocommand，分別處理一下在不同界面時，從資源里加載組件併為組件綁定一個事件處理器最後，我們需要在oncreate的時候，也就是啟動後的main界面上設置一下按鈕事件處理器。
2. 還是回到正道上，多個activity之間的跳轉
android中提供一個叫intent的類來實現屏幕之間的跳轉，按文檔的説法，似乎他們也建議採用這種方法，intent的用法比較複雜，現在我先看看它最簡單的用法。
這裏的跳轉功能用intent來操作，它的最簡單用法就是用函數setclass()設置跳轉前後兩個activity類的實例，然後調用activity自己的startactivity(intent)即可。最後一句finish()表示將當前activity關掉（如果不關掉會如何？你可以自己試一下看效果，事實上有時我們是不需要關掉當前activity的）。
然後，我們同樣弄一個activity類hellothreeb，代碼與前面的差不多，只是將setclass的兩個參數反一下，這樣就可以簡單地實現在兩個activity界面中來回切換的功能了。
2.關於 intent的使用
intent分為兩大類，顯性的（explicit ）和隱性的（implicit）。一般來説，intent要定位事件的目的地，無外乎需要以下幾個信息：
1.種類（category），比如我們常見的 launcher_category 就是表示這是一類應用程序。
2.類型（type），在前面的例子中沒用過，表示數據的類型，這是隱性intent定位目標的重要依據。
3.組件（component），前面的例子中用的是setclass，不過也可以用setcomponent來設置intent跳轉的前後兩個類實例。
4.附加數據（extras），在contenturi之外還可以附加一些信息，它是bundle類型的對象。
其實，如果是在一個應用內部，這種隱性的intent實在有點彆扭，個人覺得，這種鬆藕合的實現方法，只適用於那些較大的系統或者多個不同的應用之間的調用，可手機上又有什麼“較大”的系統呢？無非是可以與不同來源的多個應用之間方便地互操作而已，那麼會是什麼樣的場景呢？比如，給qq好友發送gmail郵件，用googlemap查找qq好友所在的位置？看上去挺不錯的。
關於這個contentprovider，其實還有話説，它主要是的那些看似數據庫操作的方法我們都沒真正去實現呢。不過今天就到這裏了，等下回再去研究吧。
3.關於listactivity
準備一個list對象並藉助adapter就可以構造出一個列表。重載onlistitemclick方法可以響應選擇事件，利用第一個參數可以訪問到這個listview實例以得到選中的條目信息。這裏有一點要説明的，就是如果更簡單的話，其實連那個setcontentview都可以不要了，android也會自動幫我們構造出一個全屏的列表。但是本例中我們需要一個textview來顯示選中的條目，所以我們需要一個layout.mainb描述一下這個列表窗口。
這裏需要注意的是那個listview的id，是系統自定義的android:list，不是我們隨便取的，否則系統會説找不到它想要的listview了。然後，在這個listview之外，我們又增加了一個textview，用來顯示選中的條目。
再來説説這裏用到的arrayadapter，它的構造函數中第二個參數是一個資源id，arrayadapter的api文檔中説是要求用一個包含textview的layout文件，平台用它來顯示每個選擇條目的樣式，這裏的取值是r.layout.list_row，所以，我們還有一個list_row.xml文件來描述這個佈局，相當簡單。
從arrayadapter上溯到baseadapter，發現還有幾個同源的adapter也應該可以使用，象simpleadapter和cursoradapter，還是做個例子來實驗一下吧。
然後，在hellotw(請你繼續關注本站：www.HaOwoRd.coM)ob中的oncreate函數中，修改代碼，有幾個不同：items的元素是hashmap實例，這是一點變化，然後構造函數除了要求items以外，還要求提供一個string[]來説明用hash表中的哪個字段顯示在列表中，而後是一個資源id的數組。
因為單純的cursoradapter是抽象類，所以我用的是它的子類simplecursoradapter，很好理解，先用contentresolver查詢通訊簿得到一個遊標，然後告訴simplecursoradapter要用其中的people.name作為顯示項來構造出一個adapter即可。
4.關於dialog
注意到android.app包下除了dialog（可用於製作複雜的對話框）以外，還包括了幾個系統定義好的對話框類，如datepickerdialog、timepickerdialog及alertdialog。
其中alertdialog我上回用過一次，基本上就那樣子了，今天看看另外兩個對話框的使用吧。
很簡單的，無非是需要一個ondatesetlistener接口的實現而已，在它裏面的dateset方法中就可以得到選擇的日期了。而timepickerdialog與datepickerdialog使用如出一轍。
看看另一個progressdialog的用法吧，這個類與alertdialog一樣包含了多個static的方法，所以使用起來是非常方便的。比如説，如果我們需要用它來表示一個長時間的操作。
5.關於service和notification
大略地看了一下android.app下的service類，覺得它與activity非常相似，只是要注意幾個地方：
1.生命週期，service的從oncreate()->onstart(int,bundle)->ondestroy()顯得更為簡單。但是它的onstart是帶參數的，第一個id可用來標識這個service，第二個參數顯示是用來傳遞數據的了。比較activity，傳遞數據的bundle是在oncreate就帶進入的。
2.service的啟動由context.startservice開始，其實activity或者service都是context的派生類。結束於context.stopservice()或者它自己的stopself()。
3.service還有一個與activity不一樣的是它可以由另一個context去綁定一個已存在的service。就是這個方法context.bindservice()，被綁定的service要求是已經oncreate了但可以沒有onstart。在service類中有個抽象方法getbinder()可以得到這個ibinder對象。關於這方面的細節，以後再看，這裏只做個記錄罷。
4.與service有關的還有一個安全的問題，可以在androidmanifest.xml中用<uses-permission>標籤來聲明一個service的訪問權限，關於android的安全問題也留待以後再解決吧。
6．gridview與imageview
簡單一點吧，就瞧瞧那個grid的效果，android提供了一個gridview，不過從apidemo中看來，它似乎與pc上的grid差別還是挺大的，更像那個iconview的感覺。不知道android中如何實現表格界面？雖然在移動終端上，表格一般不會有誰使用，大家似乎更傾向於使用listview，而android對於listview則有更簡單的實現listactivity。
很簡單，只要重載幾個方法就可以了，關鍵是那個getview方法，它負責構建出每個單元格中的對象實例。這裏我們構造的是一個imageview實例。
然後就是同樣的將這個adapter賦給gridview即可，大家可以看看效果，注意在做這個例子前，先放幾個小圖片到res/drawable目錄下，buildproject一下就可以得到那個r.drawable.a了（這裏的a是圖像文件名，如a.png）。
在getview方法中我們使用了imageview類，這又是一個widget。除了上面用到的幾個方法以外，還有以下幾個方法值得注意：
與圖像來源有關的方法，我們只用了資源文件的方式。
還是習慣性跑題了，其實，我是想通過我對這個類的無數次debugger跟進，説説它的多線程異步處理的解決策略的。他的基本策略如下：
1. 當你實例化一個asyncqueryhandler類時（包括其子類...），它會單件構造一個線程（後面會詳述...），這個線程裏面會構建一個消息循環。
2. 獲得該消息循環的指針，用它做參數實例化另一個handler類，該類為內部類。至此，就有了兩個線程，各自有一個handler來處理消息。
3. 當調用onxxx的時候，在xxx函數內部會將請求封裝成一個內部的參數類，將其作為消息的參數，將此消息發送至另一個線程。
4. 在該線程的handler中，接受該消息，並分析傳入的參數，用初始化時傳入的contentresolver進行xxx操作，並返回cursor或其他返回值。
5. 構造一個消息，將上述返回值以及其他相關內容綁定在該消息上，發送回主線程。
6. 主線程默認的asyncqueryhandler類的handlemessage方法（可自定義，但由於都是內部類，基本沒有意義...）會分析該消息，並轉發給對應的onxxxcomplete方法。
7. 用户重寫的onxxxcomplete方法開始工作。
這就是它偷偷摸摸做過的事情，基本還是很好理解的。我唯一好奇的是它的線程管理方式，我猜測他是用的單件模式。第一個asyncqueryhandler的實例化會導致創建一個線程，從此該線程成為不死老處男，所有的contentresolver相關的工作，都由該線程統一完成。個人覺得這種解決方式很贊。本來這個線程的生命週期就很難估量，並且，當你有一個contentprovider的請求的時候，判斷你會做更多的類似操作並不過分。就算錯了，花費的也只是一個不死的線程（與進程同生死共存亡...），換來的卻是簡單的生命週期管理和無數次線程生死開銷的節約。同時另外一個很重要的問題，他並會涉及到單件中數據同步的問題，每個類都有各自的handler類，彼此互不干擾，分發可以分別進行。當多個數據請求的時候，在同一個contentresolver上進行的可能微乎其微，這就避免了堵塞。總而言之，這套解決辦法和android的整體設計算是天作之合了。
所以建議，如果你有什麼非contentprovider操作，卻需要異步多線程執行的話，模擬一套，是個不錯的策略，當然，具體情況具體分析，生搬
硬套是學不好馬列主義的。
7.顯示控件使用
android的界面顯示同樣也是基於控件的。通常是用view（包括viewgroup）控件配上xml的樣式來做的。具體細節不想説了，可以參考 samples裏的apidemos/view，和view的doc，以及implementing a ui這篇doc。其他還有很多，感覺算是sdk講述的最多的內容。
從控件的使用上，和網頁的設計類似，儘量用parent_width之類的抽象長度，用theme來做風格，抽取所有的字串等信息做本地化設計。相關內容參看implementing a ui就好。
一類比較重要的是數據綁定控件。如果做過會從中看到很多類似的地方。一個支持數據綁定的控件，比如listview。可以通過一個 listadapter綁定到一個數據源上。listadapter是一個抽象類，主要的實現類包括simpleadapter和 simplecursoradapter。前者是綁定一個靜態的array，後者是綁定一個動態的cursor。cursor前面説過，是一個指向數據源的隨機迭代器，將view綁定到cursor通常要設置這樣幾個參數。一個是每一行的樣式，稱作row layout，其實就是一個普通的layout的xml文件。還有就是一個列和現實控件的對應關係。那個控件顯示哪個列的值，這是需要配置的。為了定製一個良好的數據顯示控件，最簡單你可以定製很pp的row layout，複雜一點就是可以重載綁定控件view，或者是適配器listadapter。如果是一個數據顯示密集的應用，且你對ui有些追求，這個工作估計是必不可少的。
一個主要用於顯示數據內容的activity，可以選擇派生自listactivity。它提供了一個具有listview 的layout，還有simple_list_item_1, simple_list_item_2, two_line_list_item等默認的row layout，還有一些比較不錯的api，和可供響應選擇item的事件。可以滿足你比較基礎的需求。如果你覺得只有一個listview的界面太突兀，你可以為這個listactivity指定一個layout，需要注意的是，你需要提供一個id為@android:id/list的listview控件，避免activity在內部偷偷尋找該控件的時候失敗。
除了這些要求，做好ui還有注意易用性和效率。快捷鍵是一個比較不錯的選擇，在 activity中調用setdefaultkeymode(shortcut_default_keys)，可以開啟快捷鍵模式，然後你可以將菜單綁定到指定快捷鍵上就ok了。個人覺得tip也是一個比較重要的東西，但目前觀察看來，這個東西只能夠自己提供了。界面的動態性有時候是不可避免的，比如説菜單就是一個需要經常根據光標位置提供不同的選項。這個東西android很人道的考慮到了，你可以參看nodelist這個sample。它採取的應該是一個靜態模擬動態的方式，這樣有助於提高速度。你也可以利用viewinflate，動態從一個xml創建一個控件。成本據doc説很大，不到萬不得已不要使用。
nt消息傳遞
在前面寫android的contentprovider時候，可以看到那是基於觀察者模式的一個消息傳遞方法。每一個cursor、contentresolver做為一個小的註冊中心，相關觀察者可以在這個中心註冊，更新消息由註冊中心分發給各個觀察者。而在mfc或winform中，都會形成一個消息網，讓消息在網中流動，被各節點使用、吃掉或者在出口死掉。
相比之下，我個人覺得基於intent的android核心消息傳遞機制是有所不同的。它應該會有一個全局性的註冊中心，這個註冊中心是隱性的，整個android系統中就那麼一個。所有的消息接收者，都被隱形的註冊到這個中心。包括activity，service和intentreceiver。其實説隱形註冊是不確切的，所有註冊都還是我們手動告訴註冊中心的，只是與傳統的方式不一樣，我們通常不是通過代碼，而是通過配置文件來做。在應用的manifest中，我們會為一些activity或service添加上intent-filter，或在配置文件中添加<receiver></receiver>項。這其實就相當於向系統的註冊中心，註冊了相關的intent-filter和receiver（這個事情完全可以通過代碼來做，只是這樣就失去了修改的靈活性）。
當程序有一個消息希望發出去的時候，它需要將消息封裝成一個intent，併發送。這時候，應該是有一個統一的中心（恩，有可能android底層實現的時候不是，但簡單這樣看是沒問題的...）接受到這個消息，並對它進行解析、判定消息類型（這個步驟降低了耦合...），然後檢查註冊了相匹配的filter或receiver，並創建或喚醒接收者，將消息分發給它。這樣做有很多好處。雖然這種傳遞有的時候不如點對點的傳遞快（這有些需要速度的地方，我們看到android會通過直接通信來做），但有時候又因為它只經過一跳（姑且這麼叫吧...），比複雜的流動又要更快。更重要的是，它耦合性低，在手機平台這種程序組件多變的條件下使用十分適合。並且它可以很容易實現消息的精確或模糊匹配，彈性很大。（我個人曾想在開發一個c++二次平台的時候引入這樣的機制，但在c++中，建立一套完整的數據marshal機制不容易，相比之下，用java來做會簡單很多...）
恩，廢話説了很多，具體講講android中intent的使用。當你有一個消息需要傳遞，如果你明確知道你需要哪個activity或者其他class來響應的話，你可以指定這個類來接受該消息，這被稱為顯性發送。你需要將intent的class屬性設置成目標。這種情況很常見，比如startactivity的時候，會清楚當前activity完了應該是哪個activity，那就明確的發送這個消息。
但是，有的時候你並不確定你的消息是需要具體哪個類來執行，而只是知道接收者該符合哪些條件。比如你只需要有一個接收者能顯示用户所選的數據，而不想制定某個具體的方法，這時候你就需要用到隱形發送（傳統上，我們可能會考慮用多態，但顯然這種方式更為靈活...）。在android中，你可以為intent指定一個action，表示你這個指令需要處理的事情。系統為我們定義了很多action類型，這些類型使系統與我們通信的語言（比如在activity裏面加一個main的filter，該activity就會做成該應用的入口點），當然你也可以用於你自己的應用之間的通信（同樣當然，也可以自定義...）。強烈建議，在自己程序接收或發出一個系統action的時候，要名副其實。比如你響應一個view動作，做的確實edit的勾當，你發送一個pick消息，其實你想讓別人做edit的事，這樣都會造成混亂。當然只有action有時候是不夠的，在android中我們還可以指定catalog信息和type/data信息，比如所有的顯示數據的activity，可能都會響應view action。但很多與我們需要顯示的數據類型不一樣，可以加一個type信息，明確的指出我們需要顯示的數據類型，甚至還可以加上一個catalog信息，指明只有你只有按的是“中鍵”併發出這樣的消息才響應。
從上面可以看出，android的intent可以添加上class, action, data/type, catalog等消息，註冊中心會根據這些信息幫你找到符合的接收者。其中class是點對點的指示，一旦指明，其他信息都被忽略。intent中還可以添加key/value的數據，發送方和接收方需要保持統一的key信息和value類型信息，這種數據的marshal在java裏做，是不費什麼力氣的。
android的intent發送，可以分成單播和廣播兩種。廣播的接收者是所有註冊了的符合條件的intentreceiver。在單播的情況下，即使有很多符合條件的接收者，也只要有一個出來處理這個消息就好（恩，個人看法，沒找到確切條款或抉擇的算法，本來想實驗一下，沒來得及...），這樣的情況很容易理解，當你需要修改某個數據的時候，你肯定不會希望有十個編輯器輪流讓你來處理。當廣播不是這樣，一個receiver沒有辦法阻止其他receiver進行對廣播事件的處理。這種情況也很容易理解，比如時鐘改變了，鬧鐘、備忘錄等很多程序都需要分別進行處理。在自己的程序的使用中，應該分清楚區別，合理的使用。
entprovider數據模型
數據庫操作
從我目前掌握的知識來看，sqlite比較輕量（沒有存儲過程之類的繁雜手段），用起來也比較簡單。實例化一個sqlitedatabase類對象，通過它的apis可以搞定大部分的操作。從sample中看，android中對db的使用有一種比較簡單的模式，即派生一個 contentproviderdatabasehelper類來進行sqlitedatabase對象實例的獲取工作。基本上， contentproviderdatabasehelper類扮演了一個singleton的角色，提供單一的實例化入口點，並屏蔽了數據庫創建、打開升級等細節。在contentprovider中只需要調用contentproviderdatabasehelper的opendatabase方法獲取sqlitedatabase的實例就好，而不需要進行數據庫狀態的判斷。
uri
像進行數據庫操作需要用sql一樣，對contentproivder進行增刪改查等操作都是通過一種特定模式的uri來進行的（ig：content: //provider/item/id），uri的能力與url類似，具體細節可以查看sdk。建立自己的contentprovider，只需要派生 contentproivder類並實現insert, delete, update等抽象函數即可。在這些接口中比較特殊的是gettype(uri)。根據傳入的uri，該方法按照mime格式返回一個字符串（==!沒聽過的詭異格式...）唯一標識該uri的類型。所謂uri的類型，就是描述這個uri所進行的操作的種類，比如content://xx/a與 content://xx/a/1不是一個類型（前者是多值操作，後者是單值），但content://xx/a/1和content://xx/a/2 就會是一個類型（只是id號不同而已）。
在contentprovider通常都會實例化一個contenturipraser來輔助解析和操作傳入的uri。你需要事先（在static域內）為該contenturipraser建立一個uri的語法樹，之後就可以簡單調用 contenturipraser類的相關方法進行uri類型判斷（match方法），獲取加載在uri中的參數等操作。但我看來，這只是在使用上簡化了相關操作（不然就需要自己做人肉解析了...），但並沒有改變類型判定的模式。你依然需要用...對uri的類型進行判斷，並進行相關後續的操作。從模式來看，這樣無疑是具有強烈的壞味道，類似的...代碼要出現n此，每次一個 contentprovider做uri類型的增減都會需要遍歷修改每一個...，當然，如果你使用模式（策略模式...）進行改造對手機程序來説無疑是崩潰似的（類型膨脹，效率降低...），所以，只能是忍一忍了（恩，還好不會擴散到別的類中，維護性上不會有殺人性的麻煩...）。
增刪改查
contentprovider 和所有數據源一樣，向外提供增刪改查操作接口，這些都是基於uri的指令。進行insert操作的時候，你需要傳入一個uri和 contentvalues。uri的作用基本就限於指明增減條目的類型（從數據庫層面來看就是table名），contentvalues是一個 key/value表的封裝，提供方便的api進行插入數據類型和數據值的設置和獲取。在數據庫層面上來看，這應該是column name與value的對應。但為了屏蔽contentprovider用户涉及到具體數據庫的細節，在android的示例中，用了一個小小的模式。它為每一個表建一個基於basecolumn類的派生類（其實完全可以不派生自basecolumn，特別當你的表不基於默認的自動id做主鍵的時候），這個類通常包括一個描述該表的contenturi對象和形如 public static final title = "title"這樣的column到類數據的對應。從改變上角度來看，你可以修改column的名字而不需要更改用户上層代碼，增加了靈活性。 insert方法如果成功會返回一個uri，該uri會在原有的uri基礎上增加有一個row id。對於為什麼使用row id而不是key id我想破了腦袋。到最後，我發現我傻了，因為contentprovider不一定需要使用數據庫，使用數據庫對應的表也可以沒有主鍵，只有row id，才能在任何底層介質下做索引標識。
但，基於row id在刪除和修改操作是會造成一定的混亂。刪除和修改操作類似。刪除操作需要傳入一個uri，一個where字串，一組where的參數（做條件判定...），而修改操作會多一個contentvalues做更新值。着兩個操作的uri都支持在末尾添加一個row id。於是混亂就出現了。當在where參數中指明瞭key id，而在uri中提供了row id，並且row id和key id所指函數不一致的時候，你聽誰的？示例代碼中的做法是完全無視row id（無語...），如此野蠻的方式我估計也只能在示例中出現，在實際中該如何用，恩，我也不知道。幸運的是，我看了下上層對 contentprovider的刪除操作，其實都不會直接進行，而是通過調用cursor的delete方法進行，在這前提下，我想cursor會處理好這些東西吧。
最後一個操作是查詢操作，可以想見，查詢的參數是最多的，包括uri和一組條件參數。條件參數類型和標準的sql類似，包括 sort, projection 之類的。從這些參數到sql語句的生成，可以尋求querybuilder類的幫助，它提供了一組操作接口，簡化了參數到sql的生成工作，哪怕你不懂 sql都完全沒有問題（這話説的我自己都覺得有點懸...）。查詢返回一個cursor。cursor是一個支持隨機讀寫的指針，不僅如此，它還提供了方便的刪除和修改的api，是上層對contentprovider進行操作一個重要對象，需要仔細掌握（cursor還可以綁定到view上，直接送顯，並與用户進行交互，真是程序越往上，封裝越好，工作越機械沒有複雜性了...）。
數據模型
在與界面打交道的cursor、contentresolver等數據操作層中，大量採用觀察者模式建立數據層與顯示層的聯繫。一個顯示層的視圖，可以做成某一種觀察者註冊到cursor或contentresolver等數據中間層中，在實現底層contentprovider中，我們需要特別注意在對數據進行修改操作（包括增刪改...）後，調用相應類型的notify函數，幫助表層對象進行刷新（還有一種刷新方式是從一個view發起的）。可以看到 android的整體數據顯示框架有點像mvc的方式。cursor、contentresolver相當於控制層，數據層和顯示層的交互通過控制層來掌管，而且控制層很穩定不需要特別定製，通常工作只在定製數據層和顯示層空間，還是比較方便和清晰的。
10.學習感想
通過這學期對安卓的學習，大概瞭解了以上一些知識，對安卓有了初步的瞭解，這幾個月給我的東西我想用有形的和無形的兩部分概敍，形的當然就是技術水平的長進，雖然其中肯定有很多的不足，相信慢慢會體會到。
第二篇：安卓 課程學習心得
學號：姓名：班級：
一開始接觸 android 是從自己的手機開始的，覺得它很酷，是我喜歡的風格，然後我就通過了一些網絡渠道去了解android。在選課的時候發現有這個課程，於是我就報名了。剛開始接觸 android開發時感覺到它很有意思，在界面開發上和 web 也可以形成了相通的架構，更加方便，視覺上也是非常的酷。android作為新興的手機操作系統，適應潮流的發展，在一定程度上迎合了現代人們最求效率和最求完美的心態，再加上的它的先進之處，所以 android 的發展很快，android 的應用資源也越來越廣泛，現在的 android 正在快速形成一個只能手機王國，給人們提供日常娛樂和辦公的平台，無論在哪些方面，android 的表現總是能夠讓人滿意， 它正在快速地佔領手機終端，未來的智能手機領域將是 android 的天下，越來越多的人選用 android 平台的手機。如果説追求蘋果是因為蘋果的高端與美感，那麼追求 android 則是因為它的先進性開源性，也正是因為 android 這些吸引人們矚目的特點，才會有越來越多的人對 android 充滿激情，android 的發展也才能這樣的迅猛，所以在這裏要先謝謝 goolge，以及那些充滿激情的開發者們。首先在界面上，我們同樣可以通過不同佈局進行設計非常酷的界面，這些界面可以通過 include 進行引入，我們可以通過一些公用的方法寫個 baseactivity 這個基類，通過繼承方式比較不錯的實現了 activity 的界面， 因為這樣你可以 header(頭部)和 footer(尾部)進行處理一些觸發事件或者特效等。佈局模式以相對模式為主，線線佈局模式可以在比較簡單的 include 進行完成，最重要的一點就是：我們可以自己通過重寫方法或者通過實現 view 或者 layout 等類進行擴充項目需要的佈局(或者控件) ,在學習界面中，android 為我們提供了很好的類似反射機制，通過 layout 文件夾下的配置文件，可以快速的形成界面，在配置文件可以設置屬性或者樣式都是很快捷方便。對比較特殊的界面也可以通過處理嵌入到指定的界面，同樣可以通過java 代碼直接創建view 進行添加，不過這種方式比較複雜。對一些點擊、選中、按鍵等處理的事件，界面之間的 跳轉 intent 管理，通過 bundle 對數據在界面之間進行傳輸。其次在手機交互式通信服務中，學習了 android 手機之間進行短信發送、廣播、對廣播的監聽、服務等。
這次的課程我們主要學習了航班系統的設計，首先我們要建立航班查詢：旅客就可通過網絡訪問該系統客户端網址，可根據旅客提供的出發時間、出發地點和目的地、艙位要求等，查詢滿足旅客要求的航班。通過檢索可得到航班的相關信息，從而可以方便旅客訂票並掌握所需信息，同時可減少工作人員的工作量。
第二，我們要建立旅客訂票：旅客將訂票的相關信息通過工作人員輸入系統客户端。客户端將旅客的訂票信息通過網絡傳送給服務端，服務端根據接收
到的信息由航班安排系統為旅客安排座位並返回相應的確認信息給該客户端。訂票信息生成後，存入相應的存儲區域，並對數據庫進行數據提交。客户端打印取票單及帳單給旅客，旅客在登機前，經信息核審後，即可領取機票登機。
第三，航班信息管理：航空公司可將所有航班的信息存入數據庫，方便用户對航班基本信息查詢，相 關工作人員可根據公司要求，經系統身份認證後登錄並對航班信息進行修改等操作，從而使 航班信息便於管理。
第四：航班安排：從客户端接收到旅客的訂票信息，該系統可在短時間內處理旅客航班問題。將 訂票信息送往數據庫並更新，客户端的航班查詢信息也同步更新。節省時間的同時，也能讓 旅客得到最新的航班信息。
第五，售票管理：旅客不僅可在各客户端進行機票預定，也可直接在機場的售票處購票，購票信息由系統提交到數據庫進行管理更新。
第六，退票管理：機票有效期內，旅客若需退票，可在退票處進行退票。退票信息，由工作人員輸入系統，系統對訂票信息或售票信息進行刪除更新。
第七，票銷售情況核算：因為航空公司機票銷售量大，而航空公司為了公司的經營，有需要在一定的時 間階段瞭解公司機票的銷售情況。而龐大的數據量通過人工來完成，似乎不太現實，而該系 統可幫助航空公司進行售票情況的核算。
這個課程緊跟住了現代科技的發展，讓我們在第一時間和先進的科學技術做了一個親密的接觸，這樣的課程能夠點燃我們對某一個新興領域的激情，這算是一個啟蒙，讓我們對 android 先有了一個大概的瞭解，這個課程不一定能讓我們很好的掌握 android 的理念或者開發，但是能夠讓我們對 android 產生濃厚的興趣，讓我們燃起探索android 的慾望，我想這樣就已經足夠了。
第三篇：安卓學習
安卓開發學習準備要點介紹
要説當下it行業當中最具創造力、前瞻性、延續性和實現能力，想必有相當的人會把票投給google的安卓，安卓開發學習也成為新潮流。安卓開發學習要做什麼準備？下面就由福州卓躍教育具體介紹。
首先，最好先熟悉一門編程語言，現在大學裏面和計算機相關的專業甚至理工類專業一般都會開設c語言課程，只是很多同學在大學期間並沒有好好學習，如果對它掌握的不太好或者很久沒用了，建議先從將其好好複習一下，將其基本的語法再好好回顧一下，最好能搭建一個環境來運行、調試它。如果沒有學過，不妨也提前學習一下，可以參考清華大學出版社出版的譚浩強老師的《c語言程序設計》，推薦這本書的原因一是它已經經過了多年的考驗，應該説還是比較嚴謹的；其次就是大部分的高校所開設的c語言使用的教材都是用它作為教材，因此無論是購買還是借閲，都容易找到。
其次，如果後續有志於遊戲方面的開發，最好具備一定的數據結構和算法基礎知識。雖然現代的高級編程語言中，其類庫中已經幫我們實現了大部分的數據結構，一般情況下，我們直接使用即可。但如果能對其原理有所瞭解，當需要在這些數據結構和算法中間的時候，可以更加的清楚到底應該選擇那個數據結構或者算法。另外，在圖形圖像處理上面，線性代數的作用也非常重要，如果能掌握一點這方面的基礎知識，無疑也會在後續的學習中如虎添翼。舉個例子，在android中，有一個用於圖形變換的類matrix，用起來稍有點難。
第三，因為android的應用的開發語言用的是java語言，並且在android中也用到了java核心類庫的大量的類，因此，在學習android開發之前，可以先把java基本語法和java se的基礎類庫好好學習一下android應用程序開發是以java語言為基礎的，所以沒有紮實的java基礎知識，只是機械的照抄別人的代碼，是沒有任何意義的。
至少要掌握以下兩個方面的內容：a) java基礎語法：具體的知識點列表可以在這裏下載：《java知識點列表》v1.0。這部分內容沒有討價還價的餘地，必須爛熟於胸。至於具體的學習方法，可以看書或者是看視頻，但是關鍵是要多加練習，無論是書上的練習還是視頻裏面的練習，都需要仔仔細細的完成；b)設計模式：由於在android系統的框架層當中，使用了大量的設計模式，如果沒有這個方面的知識，對於android的理解就會大打折扣。設計模式的種類非常之多，一個一個的全部掌握，是不現實的，必須首先掌握面向對象的基礎設計原則，有了這些基礎原則的支持，就可以舉一反三。這部分內容可以在《effective java》和《lopment：
principles,tices》這兩本書中找到。
第四篇：如何學習安卓
如何學習安卓
想學編程開發，那要先會一門編程語言，現在可以試着去學學c語言，雖然這個安卓沾不上邊，但是，c語言的編程思想還是很重要的，學完了c語言之後，他的語法基本上和所有的編程語言都很相像， 能影響你的思維，幫助你理解其他的編程語言的。之後呢，在好好看看《數據結構》，這很重要。然後再去學學java語言，因為android的應用的開發語言用的是java，所以一定要好好學習。
最後瞭解下數據庫，我們在學習數據庫之前都先學了《數據庫原理》《離散數學》《關係代數》，有了這些基礎之後再去學數據庫，數據庫也有很多可以選擇的，推薦mysql。
加油！
第五篇：如何學習安卓開發
如何學習安卓開發?安卓開發學習已經成為it行業的新潮流。時下，android也以其創造力、前瞻性、延續性和實現能力成為行業首領，可是怎麼學好android呢?今天，歐柏泰克的老師告訴你如何學好android。
熟悉java基礎知識
android應用的開發語言用的是java語言，並且在android中也用到了java核心類庫的大量的類，因此，在學習android開發之前，可以先把java基本語法和java se的基礎類庫好好學習一下。android應用程序開發是以java語言為基礎的，所以沒有紮實的java基礎知識，只是機械的照抄別人的代碼，是沒有任何意義的。 建議在android課程前期的java學習階段中，需要用心的學好。
熟悉一門編程語言
現在大學裏面和計算機相關的專業甚至理工類專業一般都會開設c語言課程，只是很多同學在大學期間並沒有好好學習，如果對它掌握的不太好或者很久沒用了，建議先從將其好好複習一下，將其基本的語法再好好回顧一下，最好能搭建一個環境來運行、調試它。如果沒有學過，不妨也提前學習一下。大部分的高校所開設的c語言使用的教材都是用它作為教材，因此無論是購買還是借閲，都容易找到;
熟悉數據結構和算法基礎知識
如果後續有志於遊戲方面的開發，最好具備一定的數據結構和算法基礎知識。雖然現代的高級編程語言中，其類庫中已經幫我們實現了大部分的數據結構，一般情況下，我們直接使用即可。但如果能對其原理有所瞭解，當需要在這些數據結構和算法中間的時候，可以更加的清楚到底應該選擇哪個數據結構或者算法。另外，在圖形圖像處理上面，線性代數的作用也非常重要，如果能掌握一點這方面的基礎知識，無疑也會在後續的學習中如虎添翼。 ?
蒙田範文網