Android C2DM (二)：流程

23 December 2011

前一篇在講參數說明
這篇專注於流程說明
第三篇在講Server端的實作
第四篇在講Android端的實作

Android C2DM的實作步驟大概分為下列三項：
  • Enabling C2DM ：在Android Device上啟動C2DM準備receive訊息。
  • Sending a message：Server傳遞訊息至Device
  • Receiving a message：Android上收來自C2DM Server的訊息
下面是個三項的說明流程，

1. Enabling C2DM
  1. 首先要先啟動一個registration Intent到C2DM的SERVER (com.google.android.c2dm.intent.REGISTER)，且這Intent必須但兩個參數，第一個是SENDER ID，第二個是application ID。參數說明請看這。
  2. 如果這個registration成功了，C2DM的Server會回傳(broadcast)一個registration ID，這時候Android applicaiton要把這registration ID先存起來，待會用。(Google可能會一段時間就去refresh這個registration ID）
  3. 完成註冊以及取得resgistration ID以後，Android App必須把此ID傳到自己的server上去。Server一樣得把這ID存起來。
註：register ID會存活直到你unregister，或者直到Google refresh為止。



2. Sending a message
  1. 在send a message之前，必須確認Android app和Sever上已經有 resgistration  ID了，以及Sever必須有ClientLogin authorization token. 至於怎麼取得這個token，可以去看Google官網說明
  2. 完成上面的以後，首先，Sever必須先send訊息至C2DM Sever上
  3. Google收到以後，會先存起來，以免Android device是inactive的狀態。
  4. 當Device是online的狀態，Google就會send訊息至device上。



3. Receiving a Message
  1. 首先Android OS會先收到這則Message，
  2. 接著Android OS會把這則訊息，會根據package name發送到含有註冊com.google.android.c2dm.intent.RECEIVE的app上去
  3. 最後，該app就會從自己註冊的RECEIVER的Intent裡收到message，就可以處理資料了。



下一篇會講如何去實作。










read more »

Android C2DM (一)：元件參數說明

23 December 2011

這篇為參數說明!
下一篇為流程說明
第三篇在講Server端的實作 
第四篇在講Android端的實作



Android C2DM (Android Cloud to Device Messaging)
C2DM是一個framework，用來負責做messaging的，
讓開發者可以從自己的web server傳遞訊息至Android的device上，
是一種push的概念!
詳細介紹就去官網看吧!
這邊主要介紹如何實作，因為發現網路上幾乎都是大陸人在教學，
沒有甚麼台灣人在PO教學，所以來PO一下。

先介紹三個元件(腳色)
Component
Mobile Device 搭載著android 2.2以上的手機
Third-Party Application Server 開發者自己建立的server，它將傳遞訊息給C2DM Server，C2DM再傳遞給Mobile Device。必須建立一個與C2DM Server溝通的管道
C2DM Servers 屬於Mobile Device與Third-Party Application Server之間的中間腳色，負責與這兩個溝通

所需的憑證
Credentials
Sender ID 開發者的email帳號，這個email帳號會用來註冊一個C2DM的process
Application ID 簡單的說是package name
Registration ID 由C2DM servers所發行給device，device拿到此id，必須再傳給Third-Party Application Server(就是我們自己建立的)，server會根據此id判斷是否被認可。
Google User Account 每隻device上，必須登入Google 帳號
Sender Auth Token 上面四項都是和device相關的，這個是和server相關的，server必須存有ClientLogin Auth token，用來存取Google的service，至於怎麼取得token很簡單，只要向Google的server發出request，就會回傳給你，可以去Google ClientLogin的官網看，或者可以去我之前發的文看怎麼用telen發出一個request。這篇將不多做說明。



詳細的流程說明請看下一篇。






read more »

Android Life Cycle （二）詳細講解

17 December 2011

前一篇已經簡略的說明Android Activity Life Cycle，
這篇將詳細說明Activity在Android 裡記憶體life cycle的呈現，



假設我有2個 Activity ，分別是A(主畫面)、B(子畫面)，
A中有一個按鈕，可以換頁面到B
startActivity(new Intent(A.this, B.class));


B中有一個按鈕，可以換頁面到A
startActivity(new Intent(B.this, A.class));



且A為app進入點
<intent-filter >
  <action android:name="android.intent.action.MAIN" />
  <category android:name="android.intent.category.LAUNCHER" />
</intent-filter>



執行此app時，記憶體的表現會如下圖：






如果這時候在A畫面按下換頁面至B的按鈕，
則記憶體的狀態如下圖
A會先去call onPause->onStop
注意!!! 並沒有onDestroy，A這個物件是還存在的
























如果這時候在B畫面按下手機上的"【返回】按鈕，
則記憶體的狀態如下圖
B會先去call onPause -> onStop -> onDestroy
注意!!! 這裡有onDestroy，此時B物件是被銷毀的，
這個情況應該是正常的life cycle，
可是有些人會用換頁的方式(startActivity)回到上一個畫面，
在我的觀念裡，會不建議這樣的行為，繼續往下看!






















如果這時候在B畫面，而且想要回到A畫面，
B畫面(下圖)中左上角，有一個自己做的返回按鈕，
則此時這返回按鈕的code為
startActivity(new Intent(B.this, A.class));

當使用者按下這個按鈕時！






























則此時記憶體的狀態如下圖！
B會進入到onStop的狀態！
且會有一個新的A畫面（橘色）!!!
則此時舊的A畫面（藍色）就會存在記憶體裡，暫時無法回收....






















因此不建議用這種方式回到上一個畫面，
會講這篇的原因，是為了稍後的另一篇，
要講解Bitmap recycle和 Out of Memory (OOM)的問題！
在做recycle時，得去考慮到整體life cycle的問題才行！






read more »