Android

Mms中的ComposeMessageActivity（以下簡稱Composer）是整個Mms中最重要的一個組件，它負責編輯資訊，發送資訊，管理資訊，接收資訊，與外部應用介面。在Mms內部與Composer關聯的類和組件特別多，幾乎所有的類和組件都與Composer有關聯，關於資訊的所有操作流程都起始於Composer；在外部Composer也是公開的介面，能夠處理Intent.ACTION_SEND和Intent.ACTION_SENDTO以及檔案類型為audio/*,image/*,vide

當編輯完一條資訊後，如果在沒有發送的情況下退出編輯頁面，那麼資訊會自動儲存為草稿。也就是在ComposeMessageActivity的onStop()時，如果還沒有發送，那麼就會調用WorkingMessage.saveDraft()來把資訊儲存為草稿。期間也會檢查一些條件，比如訊息是否已被標識為放棄，或是是否為空白（isWorthSaving），如果一切正常會saveDraft()並會用Toast來告知資訊已儲存為草稿。草稿的儲存也是針對不同的資訊而不同，簡訊和多媒體訊息的流程有所不同。儲存

在Mms中每個Thread都有其相應的連絡人，但是threads表中並沒有直接儲存連絡人的資訊（號碼或名字），而是儲存一個叫做recipient_id的東西，也還有一個類叫做data/RecipientIdCache.java專門管理它。在資料庫中專門有一個表來儲存它canonical_addresses。它的目的就是為了能夠快速的找到某一對話的連絡人的資訊。對話的表threads裡面並沒有儲存其連絡人的直接資訊，而是有一列叫做recipient_ids的整數來代表收信人。而在資料庫還有另外一個

Composing and editingMMS在Android Mms應用裡面的具體實現形式，或資料結構是SlideshowModel，它是一個每個節點為SlideModel的ArrayList，SlideModel是一個Model的List，也就是它可以接收任何Model的子類，Audio，Video，Image和Text都可以放到SlideModel上面。SlideModel主要用於管理其上面的各個媒體，比如它們的布局，它們的播放控制，而SlideshowModel主要用於管理所有的附件，

Conversation這個類主要表示對話的資料結構，其內持有一個Thread所有的相關資訊，如Recipients，ThreadId等等，也用於管理Thread，比如查詢Thread，刪除Thread，更新Thread，管理ThreadId，管理Thread的連絡人等等。因為Thread表與其他表關聯的資訊比較多，如連絡人，訊息個數，這些資訊有些直接會寫在資料庫。因為Thread上面的資訊比較多，所以載入時會較費時，因此就有了一個在Conversation內部的Cache來提高載入Thread

Android當中的Mms對MMS(Multimedia Messaging

1. Testing for ContentProvider在你開始為Provider寫Case之前，應該仔細讀一讀SDK文檔中關於Provider測試的說明。但是光讀那些說明，你還是沒辦法寫出正確的Case，因為你也知道，Android的文檔是比較差勁的，有一些關鍵東西文檔中沒有說明，你也知道，這在Android當中並不少見。你寫個Provider的Case，如下：public class DemoProviderTest extends

問題Activity中使用了ListView作為布局.當每一清單項目中含有預設能擷取焦點的子View時有可能會對ListView的某些事件有影響:1. OnItemClick2. OnItemLongClick3.

1. 什麼是ContentProvider也即內容提供者，是對所有資料訪問的一層抽象，為資料訪問提供了統一的介面。它有以下優點：a. 對資料的抽象，為所有的組件提供統一的訪問資料的方式，從而讓組件不必關心具體資料的呈現形式（檔案or資料庫）。資料，也可以只關心自身的管理，而不用去管使用者的訪問問題。這樣就達到了很好的封裝。b.

開閉原則--可變與不變的分離,且容易定製應用程式的目的是儘可能做到適用於多種裝置,這些裝置的配置不盡相同,有些不同的物理尺寸,解析度.為了達到最佳的適配效果,和最少的代碼重複,以及最好的可擴充性,就需要分離資源的使用和資源.用一個統一的資源管理者來管理資源.代碼通過資源管理者提供的統一的介面來擷取資源.這樣對於使用者來講資源的擷取的方式是統一,資源者無需關心如何為不同的裝置擷取不同的資源.這樣就把隨不同裝置變化而變化的代碼降到最低,只有資源管理者需要操心不同的裝置相關的不同的資源.比如:字串的擷

      前幾天因為項目的需要，要在一個ListView中放入另一個ListView，也即在一個ListView的每個ListItem中放入另外一個ListView。但剛開始的時候，會發現放入的小ListView會顯示不完全，它的高度始終有問題。上網查了下，發現別人也有遇到這樣的問題，而大多數人都不推薦這樣的設計，因為預設情況下Android是禁止在ScrollView中放入另外的ScrollView的，它的高度是無法計算的。    

TextView of Android is a text label to display text. But it can show text only horizontally by default, left to right or right to left. There are some chances that we would like to show text vertically, top to bottom or bottom to top, for layout of

Understanding AsyncTaskAsyncTask是Android 1.5 Cubake加入的用於實現非同步作業的一個類，在此之前只能用Java SE庫中的Thread來實現多線程非同步，AsyncTask是Android平台自己的非同步工具，融入了Android平台的特性，讓非同步作業更加的安全，方便和實用。實質上它也是對Java

非即時，通知性的方式第一種方式就是Intent，Intent可以非常方便的通訊，但是它是非即時的，無法進行即時的像函數調用那樣的即時的通訊。即時的函數調用但是IPC的根本目的還是為了實現函數的調用，即使是傳遞資料也是要通過函數調用的方式，為什麼呢？因為程式運行總是要知道狀態，要有邏輯上的行為，因此必須通訊函數才能體現出行為。IPC的機制除了進程，或者說不同的應用程式之間進行通訊，同時也能夠讓不同的組件之間進行像普通對象那樣進行即時的調用。因為Android的組件都是由系統架構統一的進行構建和銷毀

Android中的RPC（IPC）是由Binder組件來實現的，雖然我們使用更多的還是AIDL，並不會直接使用Binder，但是瞭解了它能更有效協助理解AIDL以及理解Android本身的一些原理和機制。Binder的架構與其他的Android系統的組件的架構類似，Binder也是由Java層封裝，JNI，libbinder和driver組成。Binder的主要組成有三個IInterface, IBinder,

資訊的接收工作是由底層來完成的，當有一個 新的資訊時底層完成接收後會以Intent的方式來通知上層應用，資訊的相關內容也包含在Intent當中，Android所支援的資訊Intent都定義在android.provider.Telephony.Intents裡面。簡訊的接收簡訊接收，對於上層應用程式來講就是要處理廣播事件SMS_RECEIVED_ACTION，它是由Frameworks發出告訴上層有新的SMS已收到。在Mms中，是由PrivilegedSmsReceiver來處理，它收到SMS_

最近部分採用了TDD的方法來開發一個模組，小有收穫特此總結一下：1. TDD的基本原則TDD的最核心思想就是先明確需求，且用代碼的方式量化，明確需求標準，然後進行編碼實現以達成由代碼測試來衡量的標準。那麼它要求，先把需要標準寫出來，每次唯寫一個。編碼實現通過達到，並剛好滿足這個標準。這樣一點一點的迭代。這樣有三個好處：一個是先明確標準，不至於我們迷失主題，偏離方向。有標準在檢測，保證代碼是正確的。僅滿足當前測試，不至於過早最佳化和過度設計。2.

這裡的Mms名稱並不準確，因為它是一個應用程式的名字，這個應用程式是Android上面的資訊應用程式，它即能處理簡訊SMS(Short Messaging Service)，也能處理多媒體訊息(Multimedia

Android現在這麼火，各種的裝置也是琳琅滿目，高中低等，大小螢幕都有，但是它始終未能達到iOS那樣的令人稱讚的卓越體驗和效能，其操作的流暢度，效能和安全性方面總是略輸iOS一籌。據說iPhone4雖然是單核512M記憶體，但是比Android的雙核1G記憶體的操作起來更流暢，iPad2雖然是也只有512M的記憶體但是操作起來比Android四核1G記憶體還要流暢。另外在安全性方面也不如iOS。造成Android效能，待機時間，操作流暢和安全性不好的原因是Android後台進程的管理。Andr

文章目錄 與主線程互動線程任務的調度