小鰻的Android學習筆記: February 2012

Saturday, February 18, 2012

官方提供的Action Bar向下相容元件

撰寫時間︰2012/02/18 18:25

更新時間︰2012/02/20 125:35

文章更新次數︰2

Action Bar是Google在Android3.0後
力推的Android特色元件之一。
開發者能利用此元件
將簡潔實用的功能提供給使用者。

全世界的Android開發者都在問︰
Android 3.0的新元件「Action Bar」何時才能向下相容(在pre-HoneyComb執行)？

前天在Android Resource裡看到有如何將Action Bar向下相容的方法。
但是在Android SDK資料夾裡的Sample卻找不到，
只好將Sample Code頁面裡的內容，
一頁一頁在Eclipse中貼成一個新的Android專案，
花了一個早上在三星辦公室的時間，
才將這個專案建立完成。

檔案在此，請用Eclipse import Archive File的方式匯入。

匯入方式如下︰

Friday, February 17, 2012

[Android雜談] - Activity、Window、View的關係

剛才在查Window在Android中的定義，
無意中爬文到此篇文章。
解釋的還不錯。

以下文章轉載自花郎部落格

一、首先說說View和ViewGroup吧
Android中的所有UI類都是建立在View和ViewGroup的這兩個類的基礎上。
所有View的子類稱為“Widget”，所有ViewGroup的的子類稱為“Layout”。
View和ViewGroup之間採用了組合設計模式，可以使得“部分 - 整體”同等對待。
ViewGroup的是佈局容器類的最上層，佈局容器裡面又可以有View和ViewGroup。

二、LayoutInflater，LayoutInflater.inflate()是什麼意思？

LayoutInflater是一個用來實例化XML佈局文件為View對象的類

LayoutInflater.infalte(R.layout.test,null)用來從指定的XML資源中填充一个新的View。

當我們運行程式的時候，用了一setContentView()方法，Activity其實不是顯示視圖（直觀上感覺是它），實際上Activity調用了PhoneWindow的setContentView()方法，然后加載視圖，將視圖放到這個Window上，而 Activity其實構造的時候初始化的是Window (PhoneWindow)，Activity其實是個控制單元，即可視的人機交互界面。

打個比喻：
Activity是一位工人，它控制Window；
Window是一面顯示畫面，用來顯示信息；
View就是要顯示在顯示畫面上的信息，這些View都是層層重疊在一起（通過infalte()和addView()）放到Window顯示畫面上的。
而LayoutInfalter就是用來生成View的一個工具，XML佈局文件就是用來生成View的原料。

再來說說代碼中具體的執行流程
setContentView(R.layout.main)其實就是下面内容。
（註釋掉本行執行下面的代碼可以更直觀）

getWindow().setContentView(LayoutInflater.from(this).inflate(R.layout.main, null))
即運行程式後，Activity會調用PhoneWindow的setContentView()來生成一個Window，而此時的 setContentView就是那個最底層的View。然後通過LayoutInflater.infalte()方法加載佈局生成View對象並通過 addView()方法添加到Window上，（一層一層的疊加到Window上）
所以，Activity其實不是顯示視圖，View才是真正的顯示視圖。

註：一個Activity構造的時候只能初始化一個 Window(PhoneWindow)，另外這個PhoneWindow有一個”ViewRoot”，這個”ViewRoot”是一個View活 ViewGroup，是最初始的視圖，然後通過addView方法將View一個個層疊到ViewRoot上，這些層疊的View最終放在Window 這個載體上面

Monday, February 13, 2012

Android Push Notification推播機制(7)-[實例分享]以Chrome to Phone為例

撰寫時間︰2012/02/13 13:35

更新時間︰2012/02/04 15:52

文章更新次數︰1

以下內容由Google I/O 2010 - Building push applications for Android 翻譯擷取

一、前言

在Android Market和Chrome的瀏覽器中，
都可以看到一個叫Chrome to Phone的程式。

它的使用方式大概就是
當使用者正在瀏覽Google Map、或在看某個網站、甚至是某段YouTube影片，
可以在Chrome上，按下"Chrome to Phone"按鈕，
這些網址或資訊，
馬上被手機端的Chrome to Phone程式接收，
並在手機上繼續享受剛才在桌機上的使用體驗，
繼續看剛才看到一半的影片。

這就是C2DM機制被實作的例子之一。

二、文章開始

我們一起看看Chrome to Phone的操作方式︰

1.首先，使用者在Chrome瀏覽器按下了"Chrome to Phone"按鈕

2.訊息被傳遞到App Engine

3.App Engine將訊息通知到C2DM

4.C2DM會將訊息通知手機

使用者可以拉下他們的Notification bar去看訊息，當然我們也可以將Notification Bar的內容關閉，去做背景程式更新。

5.接著，手機就會開啟瀏覽器，去找出App Server裡的最後一則訊息為何。

下一篇︰

Android Push Notification推播機制(8)-問答篇

Android Push Notification推播機制(6)-[狀況2]手機在待機下

撰寫時間︰2012/02/13 13:15

更新時間︰2012/02/14 13:48

文章更新次數︰1

以下內容由Google I/O 2010 - Building push applications for Android 29:55 翻譯擷取

一、前言
在發送message給手機時，
並不一定永遠都要像第1篇的方式 - 直接喚醒手機，然後傳送訊息。
想像一下，
如果今天朋友他們在什麼地方用Facebook打了卡、
或者一些不重要的即時訊息不斷傳給你，
於是你的手機就不斷地被喚醒，
這種行為幾乎可以說是"擾民"！

因此，
C2DM提供了當手機閒置中延遲發送(Delay While Idle)的機制，
附帶一提，
該機制也是Attenuation機制的其中一環。

在C2DM API中，
對於delay_while_idle值，給予了這樣的定義︰

If included, indicates that the message should not be sent immediately if the device is idle. The server will wait for the device to become active, and then only the last message for each collapse_key value will be sent. Optional.

如果使用這個值，當手機在閒置狀態下，訊息就不會馬上被傳至手機中。C2DM會等到手機再度被開啟時，才將在App Server裡對應到的collapse key值的最後一筆message發送至手機。這個值是可以選擇性使用的。

二、文章開始

我們來看看延遲發送機制(Delay While Idle)是如何運作的吧︰

1.一樣，我們透過App Server，通知C2DM現在想要發一則訊息。

2.C2DM也如往常的將訊息儲存至後端。

3.也順便將訊息丟給Connect Server

4.不同的是，Connect Server在此時卻將訊息保留住了。

5.直到使用者開啟了手機螢幕，Connect Server才將訊息傳送給手機。

三、總結

從上面的流程圖中，
我們知道了當手機在待機模式時，
Delay While Idle的使用能有效的在閒置的手機底下，
傳達訊息給手機無誤，
也不用一直喚醒手機，
減少電量消耗。

下一篇︰

Android Push Notification推播機制(7)-[實例分享]以Chrome to Phone為例

Android Push Notification推播機制(5)-Attenuation

撰寫時間︰2012/02/12 18:25

更新時間︰2012/02/14 12:13

文章更新次數︰2

以下內容由Google I/O 2010 - Building push applications for Android 26:58 翻譯擷取

一、前言

此篇為C2DM進階篇，

請先看完第1、2、3、4篇後，

再來閱讀此篇。

在第3篇裡我們提到，
為了防止使用者解除飛航模式後，
收到爆炸般的量的訊息通知，
因此在App Server發送訊息至C2DM時，
必須在HTTP POST裡附上collapse key。
這其實是一種保護機制，
這個機制就是Attenuation(電力衰減防護)。

二、文章開始

Attenuation機制的存在，有2個目的︰
1.保護手機不會一次收到爆炸量的訊息
2.希望使用者收到的訊息永遠是最新的
3.防止使用者的手機電力過度消耗

底下一起來看看Attenuation機制的運作方式︰

1.首先，手機和Connect Server是連線的狀況，一如以往，我們的App Server傳了一個訊息給C2DM。
但這次特別的是︰這次的訊息發送之前，已經傳了數次的訊息給C2DM了。

2.C2DM收到訊息，一樣將訊息儲存下來，並將訊息傳給Connect Server

3.因為之前已發送數次訊息給C2DM了，Attenuation機制在此時發生了作用。

4.Attenuation機制將本來要從Connect Server傳給手機的訊息保留了一小段期間。

5.然後，再將訊息發出。

三、總結

經由Attenuation機制，
讓欲傳來的訊息得到延遲發送的功能。
在待機模式下的手機，
不用因為訊息傳來，
就要一直喚醒手機。
這麼做，
不旦是使用者希望的使用習慣，
也間接的減少電池的消耗功率。

四、備註

下一篇︰

Android Push Notification推播機制(6)-[狀況2]手機在待機下

Android Push Notification推播機制(2)-實務篇

撰寫時間︰2012/02/09 13:53

更新時間︰2012/02/14 13:5752

文章更新次數︰2

以下內容由Google I/O 2010 - Building push applications for Android18:01翻譯擷取

一、前言
在前一篇中，
已經簡略的介紹C2DM在Android環境的操作流程，
這一篇將更詳細的介紹其中的細節。

二、文章開始
實際上跟C2DM溝通的過程是這樣的︰

1. [手機端]先由手機上的App跟C2DM伺服器取得一組RegistrationID - 利用開啟Service的方式。
傳送的內容應含有你的App資訊以及你的e-mail帳戶，這個e-mail帳戶將會被App Server傳訊息時使用，手機上是完全用不到的。呼叫方式如下︰

2. [手機端]C2DM會回傳一個含有RegistrationID的Intent給你的App
C2DM會以Broadcast的型態傳送Intent給App，底下是收Intent的方式

3. [手機端]將RegistrationID發送給你的App Server

4. [App Server端]發送文字訊息是App Server的工作，App Server在收到手機App傳來的RegistrationID後，要做以下的動作︰

(1)使用ClientLogin API取得ac2dm的auth token，並安裝至你的App Server中
(2)發送authenticated的HTTP POST給C2DM
POST的內容會含
- authenticated的token
- authenticated的header
- encoded parameter
- collapse_key 用來控制當手機離線時，要有多少訊息被傳遞
- idle parameter (可選擇)用來控制訊息發出的延遲時間
- payload (可選擇)這個payload藉時會被轉成Intetn的extra供手機App使用

5.[App Server端]App Server端會收到3組從C2DM回傳回來的典型的Response︰

(1)200 -跟C2DM的請求成功，同時App Server也會收到從C2DM傳來的ID。App Server屆時會用這組ID來做message發送至手機端的動作。
(2)401 -若收到此值代表你的authenticated token失效了，你必須再抓一個新的authenticated token
(3)503 - 伺服器失效，請在收到header後，重新再試一次。

當然，也會有error的狀況發生︰
(1)如果C2DM發現有人傳出大量或過多的message，很快就會到達使用額度限制。當如果我們這麼做，唯一能做的就是過一段期間後再發message了。
(2)如果你提供的RegistrationID是失效的，或者你的App尚未註冊(unregistration)，那麼就必須等到你用App註冊到了一組新的RegistrationID，才能繼續做發送message的動作。
(3)如果發出的message超過上限1K，或者沒有提供collapse key，也必須先修正後，再做出重新發送message的動作。

6.[App Server端]App Server傳送message給手機時，會自動將傳送的訊息轉成一組Broadcast的Intent。

7.[手機端]因為您手機的App已事先設定了相對應的permission宣告(見上圖com.google.android.c2dm.intent.RECEIVE)，因此一旦收到從App Server端傳來的Broadcast時，手機裡只有這隻App知道有人在呼叫它，手機裡該App知道它要做事了。

8.[手機端]手機裡的App將手機裝置喚醒，並開始做一些開發者預設App要做的事。

三、總結
經由以上的機制，我們知道Poll機制不用像Push機制一樣，還要設一個Service在背景執行並消耗手機電力。而你在App Server發出payload的內容，將都會在這個Intetn中被轉成Intent的extra，做你想要做的事情。

四、備註
1.因為一收到broadcast時，會喚醒手機(呼叫WakeLock資源)。因此，當App事情做完後，不要忘了將WakeLock資源釋放掉！

2.無論你重覆發幾次訊息給C2DM，若是用同一組RegistrationID，最後一組訊息永遠會覆蓋舊有的那一組訊息！

3.一隻App有可能會收到多組collapse key，請務必塞對內容至手機App中。

4.手機若在飛航模式下，可接收至多4組訊息(以每臺裝置來看)。

5.手機要看到的message內容應該是從App Server發出，而非從App Server發訊息給C2DM的過程中！

6.如果使用者將手機切為[不要資料同步]的狀態時，C2DM就不會起作用。

7.App Server端的相關技術文件，請參照A2CM API和ClientLogin API。

下一篇︰

Android Push Notification推播機制(3)-collapse key

撰寫時間︰2012/02/12 13:50

更新時間︰2012/02/04 15:52

文章更新次數︰1

以下內容由Google I/O 2010 - Building push applications for Android 24:20翻譯擷取

一、前言
前一篇提到，
Collapse key是C2DM機制中，
App Server發出訊息給C2DM時，
必須附上的值。
但這個值倒底是在什麼時候會用到？

二、文章開始
舉例來說，
倘若使用者開啟了飛航模式，
但是App Server端卻不斷的發出訊息給C2DM，
C2DM為防止使用者一旦解除飛航模式收到爆炸性的訊息通知，
因此設計了collapse key，
collapse key控制了C2DM應該要儲存和發送多少組訊息給手機。

在C2DM官方API文件中，
對於collapse key的解釋是這樣的︰

An arbitrary string that is used to collapse a group of like messages when the device is offline, so that only the last message gets sent to the client. This is intended to avoid sending too many messages to the phone when it comes back online. Note that since there is no guarantee of the order in which messages get sent, the "last" message may not actually be the last message sent by the application server. Required.

這個值必傳。collapse key是一組隨意的字串。主要目的是當手機在離線模式下，降低收到群體訊息的可能性。以防萬一手機恢復連線了，突然間收到爆炸量的訊息。註︰並不保證App Server裡的最後一組訊息是按照當初發送訊息做排列。

也就是說，
如果後來又有相同的collapse key傳送至C2DM，
那麼原本存在C2DM的訊息，
將會被覆蓋。

三、總結

經由App Server端Collapse key的重覆使用，
手機端因而不會重覆收到大量的重覆訊息，
這麼做不外乎就是降低手機資源的使用，
也保障了傳訊人員資訊傳達的準確性。

下一篇︰

Android Push Notification推播機制(4)-[狀況1]手機在飛航模式下

撰寫時間︰2012/02/12 14:35

更新時間︰2012/02/04 15:52

文章更新次數︰1

以下內容由Google I/O 2010 - Building push applications for Android 26:00 翻譯擷取

一、前提

這篇是C2DM的進階內容，

必須先了解第1、2、3篇後，

再來閱讀此篇內容。

在第1篇和第2篇中，
我們提到的C2DM流程是當手機與Connect Server在連線狀況下的說明，
那…萬一手機沒有和Connect Server連線(也就是當手機沒有連上網時)，
message又該如何傳達呢？

二、文章開始

1.App Server如同以往，發送訊息給C2DM，不同的是︰手機此時並沒有與Connect Server連線。

2.C2DM前端一收到訊息，也如往常般將訊息傳至C2DM後端

3.然後，將訊息儲存起來

4.但在此時，C2DM前端發現了手機並未與Connect Server連線，因此，C2DM前端無法將訊息傳給Connect Server。

5.如果App Server又用同一個collapse key，再次將訊息傳給C2DM。

6.這時候C2DM前端，檢查到是同一個collapse key發出來的訊息，會將C2DM後端裡，先前儲存下來的訊息覆蓋成現在這組新的訊息。

當然，我們也可以用別的collapse key，這樣就不會有被覆蓋的行為發生。
但是，每個App在C2DM中至多只會記住4筆不同的訊息。

7.手機解除了飛航模式並跟Connect Server連線後，C2DM才會將訊息通知給手機。

8.手機的App此時才會收到App Server傳來的訊息通知。

三、總結

在這篇文章裡，
我們得知手機在與Connect Server離線的狀況下，
C2DM機制的運作方式。

但在前面流程中第7~8點中，
為什麼手機在與Connect Server連線後，
還能知道之前有訊息傳來？

這是因為在C2DM中，
存在了一種機制，
叫做"Attenuation(電力衰減防護)"，
請見下一篇的說明。

下一篇︰

Android Push Notification推播機制(5)-Attenuation

Tuesday, February 7, 2012

Android Push Notification推播機制(8)-問答篇

撰寫時間︰2012/02/07 12:45

更新時間︰2012/02/14 11:50

文章更新次數︰2

以下是Google I/O 2010 - Building push applications for Android
37:40開始的會後提問。

提問1.

觀眾︰C2DM整個流程裡是否存在「延遲」問題？包括C2DM通知App Server或是收到BroadCast廣告訊息之類的？

Debajit Ghosh: 這完全取決於網路速度，由其是你的Server和我們的Server之間，或者裝置和C2DM之間的網路速度。但它是非常快的。

提問2.

觀眾︰有沒有手機傳資訊回網站，例如雙向溝通等等的方式或API架構？

(Is there an API or a mechanism to go the other way around, from the device back to the Web to do something like a two-way chat in the same manner?)

Debajit Ghosh: 一般來說，App只用標準的HTTP與其它的App Server做整合。

提問3.

觀眾︰有2個問題，你說C2DM機制目前需要Froyo2.2，意思是否是之後也能在模擬器上運行C2DM機制？

Debajit Ghosh: 2.2 SDK就已經提供這個機制了。你可以用SDK去做App測試。

觀眾︰第2個問題，若要攢寫code是否也包含要攢寫App Engine的部份？

(Does the code side also have code for the App Engine side of the code?)

Debajit Ghosh: 當然，這個機制是很完整的。
以Chrome-to-phone的範例來說，他的架構有Chrome擴充套件、Android App和一個App Engine的後端。
以JumpNote來說，有GWT和App Engine和Android App。
我們會提供所有的資源出來做分享。

提問4.

觀眾︰您剛才說如果手機目前在閒置狀態，Server會將訊息保留住直到手機狀態可能是在"忙碌"的情況下。但想請教你們是如何定義"閒置"這件事的呢？因為它可能是使用者他們執行App，像是執行背景的Service，然後就把它丟在桌上，關了螢幕。因為可能那個Service被拿來等待接收訊息。

Debajit Ghosh: 我想你的問題是我們如何定義"閒置"這件事吧？我們是基於「螢幕是否被關閉」來做決定的。如果螢幕被關閉了一段時間，我們就把手機認作閒置或非啟用狀態。因為使用者實際上也真的沒有在看任何畫面。

觀眾︰但是程式也有可能有一支Service在背後等待接收訊息啊！

Debajit Ghosh: 如果你不想使用延遲的功能，你就不用用idle parameter功能。你如果想要有延遲功能，才需要那麼做。還有問題嗎？

觀眾︰哦，你可以再說一次嗎？

Debajit Ghosh: 抱歉，我聽不到。

觀眾︰可以再麻煩你解釋一下嗎？如果Service在背景等待訊息，而螢幕卻是關閉的，你要如何避免這種狀況呢？

Debajit Ghosh: 你的問題是「當螢幕被關閉時，如何避免訊息被延遲送出」嗎？如果你不想要訊息被延遲送出，你就不要指定idle parameter的延遲時間。parameter是選擇性使用的功能。

觀眾︰了解了，謝謝。

提問5.

觀眾︰訊息推播是否支援時區或地域性？像是指定出特定的鄉村或類似的概念？

Debajit Ghosh: 你是指地域性的問題嗎？那取決於你的App，因為你知道 - C2DM機制就只是喚醒你的裝置，你的App能做任何你想做的事。並沒有任何像你App提供的UI元件來做繼承C2DM使用的相關元件。

提問6.

觀眾︰你剛才說C2DM只支援2.2以上，但...(笑)很多人都還沒有2.2手機，也不行升到2.2。是否能夠向下支援呢？

Debajit Ghosh: 答案是否定的，因為這是新功能。我們一直不斷的在革新新功能，這是2.2提供的一個新功能。

觀眾︰意思是我們在2.2以前只能用Poll機制嗎？

Debajit Ghosh: 是的，你可以用Poll機制，當然也可以建構自己的推播系統，如果你想要，都能自己建立。

觀眾︰再一個問題，你說手機如果要收訊息，必須要先跟Server註冊才能做出發送動作。但如果說我的App已註冊了，那我們可以發送訊息給每個人，讓他們得知特定訊息嗎？

Debajit Ghosh: 你的問題是「是否能將訊息發送至所有有含該boradcast的手機裡」。這是不行的，RegistrationID是依每個app、每個裝置來做區分的。他們在裝置和app之間彼此是有劃分的，因此一則訊息無法寄到另一個App裡。你必須在你的Server端處理一連串C2DM的訊息。

提問7.

觀眾︰這個服務是不用錢的嗎？還是有任何的使用費用？在傳訊息上面是否有什麼使用上的限制？

Debajit Ghosh: 是不用錢的。而使用限制的話⋯我們會依每一位傳訊的人或依傳到特定裝置的總計來檢查是否有傳訊超量的問題。如果屆時你有用到那個量時，也許我們可以來討論這個配額(quotas)。

提問8.

觀眾︰兩個問題，當在特定時間後訊息仍未發出時，有方法去指定訊息的TTL嗎？假設使用者是離線狀態，可能訊息會超過2分鐘。

Debajit Ghosh: 問題是「是否能替訊息設定TTL？」，答案是現在還不行。但如果你真的有興趣，可以給我們一些意見回應。

提問9.

觀眾︰你剛才說如果每5分鐘就跟server要資料，會花費每天超過5~10%的電池電力。但你能說明一下C2DM機制對於電池電力減少的相關介紹嗎？舉例來說，你說當螢幕關閉狀態下，C2DM的回應時間在2秒以內，你是如何讓電池電力的使用量降低的？

Debajit Ghosh: 基本原理是「我們只有一個連線」。我們在很多的App之中緩衝連線。如果沒有連線能力而無法接收或傳送時，那只會耗相當低的電力。我們實際上去分配heartbeats - 你知道，比每5分鐘還更少的次數。我們將heartbeats分配的非常長，因此，閒置的裝置底下，如果裝置沒有去取得資料，就不會對電力造成大量的影響。當然，如果你想要大量使用，C2DM一直去喚醒手機，這當然就會造成所謂電量使用過大的問題，因此我們才會有"attenuation(防電量衰減)"功能，也因此我們才提供您可以選擇是否用「當裝置閒置時延遲發送」的機制。

提問10.

觀眾︰系統是否有5分鐘延遲？Is there a five-minute latency in the system?

Debajit Ghosh: 並沒有。heartbeats並不是每5分鐘跳一次。heatbeats的次數會比每5分鐘一次還少。你知道，有時候會到半個小時。我們去設定那個heatbeats，目的也是要保持連線能力是存活的。因為一旦你建立連線，你只是重新連線，但卻耗了更大量的資源。所以我們才會試著讓連線一直存活著。當連線是存活的狀況下，訊息也會被以非常、非常快速的時間被傳送。因此不是5分鐘的延遲時間。

提問11.

觀眾︰有任何OMA push的兼容計劃嗎？

Debajit Ghosh: 現在還沒有。

觀眾︰所以即使我有push server，我也無法用？我必須照著Google設計的方式去使用，是嗎？

Debajit Ghosh: 沒錯。如果你要用C2DM，你就要用C2DM的API。如果你想要在App上建立你想要的服務，因為這是Android，所以，你還是能自己去做你想要做的服務，像是連到OMA push server。

提問12.

觀眾︰你說你在多數App裡緩衝連線，預設的應用程式連線也是Google push服務去完成的，他們也是用這種連線方式嗎？還是說只有開發者去設定才能用這樣的功能？

Debajit Ghosh: 你的問題是「C2DM的使用方式跟原本的設計是分開的還是在一起的」，很明確的回答你他們是同一個連線，我們只是使用這個功能。我們用這個功能來推播Gmail連線人、同步行事曆和其它等等大量的需求。我們也開放到讓您完全知悉的地步。

提問13.

觀眾︰可以設定接收時段嗎？譬如早上和下午不想收到太多的訊息？

Debajit Ghosh: 還沒有那樣的功能。那些邏輯你可以設計在你的App中。

觀眾︰如果我一次發太多訊息出去，Google是不是會針對此狀況做調整？

Debajit Ghosh: 是的，那就是attenuation機制的作用。

提問14.

觀眾︰如何保證傳訊安全？我的意思是有時候訊息的內容可能是敏感話題，流程中有使用任何加密的方式嗎？

Debajit Ghosh: 使用SSL加密是一貫的機制，但記住，整體的設計並沒有要去確定訊息內容，你可以自己使用加密方式，你也可以使用payload。那些都是App層可以做的事情。喚醒手機的App並直接去跟server抓敏感性的訊息也是一種方式。我們也是用這種方式在做同步的功能的。

觀眾︰所以C2DM並不適合拿來使用在這種狀況中，是嗎？

Debajit Ghosh: 如同剛才所說，可以在App中自己攢寫此功能。

觀眾︰那訊息的認証方式為何？

Debajit Ghosh: 你的意思是要如何認證你的RegistractionID已確保別人不會偷用你的RegistractionID嗎？關於這點有2個資訊可供參考︰第1是建立RegistractionID的那個人的身份。當App server想要去發怖訊息至RegistractionID時，HTTP POST會去檢驗那個身份是否符合原來的那個人。你可以依你的喜好，可能像設密碼之類的。第2是因為RegistractionID是建在每一個App、每一臺裝置上的，你的App能和App Server互傳資訊，不要把其中的相關資訊洩漏出去，這也是一個方式。

提問15.

觀眾︰訊息的使用size為何？假設使用者在離線狀態下，訊息能儲存多久？

Debajit Ghosh: 你的問題是每封訊息的size最大能用多少嗎？答案是1K。能存久，大概是幾個星期或1個月。

提問16.

觀眾︰從產生訊息的server的觀點來看，是否有射後不理(fire and forget)機制，或者可以收到一個確認通知(acknowledgement)？

Debajit Ghosh: 當訊息發送出去後，App server會收到一組ID，如果收到這個ID，代表訊息已經送到那隻手機上面了，並無法點對點做出傳送到達的返回通知。但是，老話一句，你仍然可以用App的邏輯，去做到當一收到通知，就馬上回報你的App server。

提問17.

觀眾︰抱歉我可能有漏掉幾個重點。這個機制一定要用Wi-Fi才能用嗎？家裡的路由器有支援嗎？

Debajit Ghosh: 你的問題是Wi-Fi能用嗎？是的，只要你有資料的連線能力，手機就有能力連到我們的server，我的意思是，你當然也就可以跟你的server溝通之類的。

Saturday, February 4, 2012

Android在三種平臺上開發的個人感受

因為工作的關係，
讓我有機會在Windows XP/ Windows 7/ Ubuntu(Linux)/ Mac OS
4個平臺使用Eclipse開發Android。

這4種平臺在開發的過程中，
讓我工作愉快的平臺是Mac OS，
再來是Ubuntu，
最後才是Windows。

會有這樣的感受不是沒有理由的︰

1.Mac OS不用灌驅動程式，
我手上常常一下子換Sony Erricson、Motorola、Samsung、HTC在開發Android App，
在Ubuntu和Windows下都要先將各廠牌的驅動程式灌好，
才能用該廠牌的Device開發App。

2.Mac上可以自由的放大縮小字體，
這讓我在開發過程中，
不會替過小的API文件而頭痛。

3.Mac開機夠快，不用等。

4.第4點也是最重要的一點，

Google I/O大會上，

每一年，

那些Presentation的Android工程師，

都用Mac在Demo Android技術！

如果Google自己都用Mac在開發Android，
為什麼我們還要用別的平臺砸自己的腳？

我個人的使用經驗，
在Mac上開發所遇到的奇奇怪怪BUG也是最少的。

獻給一同為Android奮鬥的同好。

Thursday, February 2, 2012

[Android技術公報]談談Android的安全性

撰寫時間︰2012/02/03 11:40

更新時間︰2012/02/03 15:25

文章更新次數︰1

今天Android 技術公報中，
Android 副總裁Hiroshi Lockheimer寫了一篇關於「Android與安全」的文章在他的Google+中。

Android and Security Thursday, February 2, 2012 | 12:03 PM By Hiroshi Lockheimer, VP of Engineering, Android The last year has been a phenomenal one for the Android ecosystem. Device activations grew 250% year-on-year, and the total number of app downloads from Android Market topped 11 billion. As the platform continues to grow, we’re focused on bringing you the best new features and innovations - including in security.

去年度是Android生態系統非凡的一年，
裝置啟用率一年一年的成長了250%，
Android市集的App總下載次數又達到了110億次，
隨著裝置持續的成長，
我們也將焦點放在一個最新的功能和革新上，
那就是－Android的安全性問題。

Adding a new layer to Android security

新增了一層防護到Android安全中

Today we’re revealing a service we’ve developed, codenamed Bouncer, which provides automated scanning of Android Market for potentially malicious software without disrupting the user experience of Android Market or requiring developers to go through an application approval process.

我們持續不斷的跟大眾告知我們開發了一個代號叫"Bouncer(保鑣)"服務，
這個服務會在不影響使用者體驗下，
自動掃描在Android Market中潛在的惡意程式，
並要求開發者通過該軟體的審核流程。

The service performs a set of analyses on new applications, applications already in Android Market, and developer accounts. Here’s how it works: once an application is uploaded, the service immediately starts analyzing it for known malware, spyware and trojans. It also looks for behaviors that indicate an application might be misbehaving, and compares it against previously analyzed apps to detect possible red flags. We actually run every application on Google’s cloud infrastructure and simulate how it will run on an Android device to look for hidden, malicious behavior. We also analyze new developer accounts to help prevent malicious and repeat-offending developers from coming back.

"Bouncer(保鑣)"服務對新上傳的App或已在Android市集上的App、
甚至是開發者帳戶底下的App執行了數種分析，
它的運作方式是︰
一旦App經上傳，
"保鑣"服務就會立刻對此App針測是否含惡意、間諜或木馬程式，
也順便檢測並能夠指出程式中不應該要有的行為，
並跟前一版App做比較，
找出程式中可能隱含的"紅燈區"，
我們已實際在Google雲端對每一隻App執行此動作，
並且去實際模擬這些惡意程式如果在裝置上會如何運作、隱藏、或會產生怎樣的惡意行為。
我們也對開發者帳戶做分析，
防止惡意且累犯的開發者回到Android生態中。

Android malware downloads are decreasing

Android的惡意程式下載量已逐步減少

The service has been looking for malicious apps in Market for a while now, and between the first and second halves of 2011, we saw a 40% decrease in the number of potentially-malicious downloads from Android Market. This drop occurred at the same time that companies who market and sell anti-malware and security software have been reporting that malicious applications are on the rise. While it’s not possible to prevent bad people from building malware, the most important measurement is whether those bad applications are being installed from Android Market - and we know the rate is declining significantly.

"保鑣"服務已經在Market上運行一段時間了，
從2011年第1季至2季中旬，
我們看到在Android Market的潛在惡意程式下載量已經減少了40%。
那些防止惡意軟體的防護公司所銷售的安全防護軟體也是功臣之一。
雖說這無法防止那些壞蛋又做出惡意程式，
但是惡意軟體的比率已有顯著的減少卻是真的事實。

Android makes malware less potent Android

讓惡意軟體大量降低

In addition to using new services to help prevent malware, we designed Android from the beginning to make mobile malware less disruptive. In the PC model, malware has more potential to misuse your information. We learned from this approach, designing Android for Internet-connected devices. Some of Android’s core security features are:

為了讓保鑣能有效預防惡意軟體，
我們在Android當初在設計時，
就已經做了阻斷惡意軟體侵蝕的架構了，
在pc模式中，
惡意軟體會在潛在的狀況下使用你的個人資料，
我們依照此方式，
將Android設計成需要網路連線的裝置，
Android也因而有底下幾個安全核心功能在其中︰

Sandboxing: The Android platform uses a technique called “sandboxing” to put virtual walls between applications and other software on the device. So, if you download a malicious application, it can't access data on other parts of your phone and its potential harm is drastically limited.

沙盒︰

Android平臺使用"沙盒"技術，
放置一個虛擬牆到軟體和其它軟體之間，
如果你下載了惡意程式，
它是無法存取你的手機的其它位置的資料的，
因此這種潛在攻擊會招到限制。

Permissions: Android provides a permission system to help you understand the capabilities of the apps you install, and manage your own preferences. That way, if you see a game unnecessarily requests permission to send SMS, for example, you don’t need to install it.

權限的認可︰

Android提供了權限認可系統幫你了解你現在要安裝的App需要哪些能力，
你能自我管理。
因此，
如果你看到一款你正要安裝的遊戲，
跟你要求一個完全不相干的權限，
像︰發送簡訊，
那麼，你就不要去安裝它。

Malware removal: Android is designed to prevent malware from modifying the platform or hiding from you, so it can be easily removed if your device is affected. Android Market also has the capability of remotely removing malware from your phone or tablet, if required.

移除惡意軟體︰

因為Android的設計是能讓你能自由的修改或隱藏App，
因此如果你的裝置受到攻擊，
你都能很輕鬆的移除該App。

Android Market也有能力在需要的狀況下，

遠端將你手機或平板使用的惡意軟體移除。

No security approach is foolproof, and added scrutiny can often lead to important improvements. Our systems are getting better at detecting and eliminating malware every day, and we continue to invite the community to work with us to keep Android safe.
沒有安全管理的系統是很愚蠢的事，
增加審核通常能讓你的裝置更好。
我們的系統每天都不斷的針測和排除惡意程式，
而且也越做越好，
我們會持續的做好Android安全性的工作。

Android Push Notification推播機制(1)-簡介篇

撰寫時間︰2012/02/02 16:40

更新時間︰2012/02/14 09:52

文章更新次數︰5

以下文章取自Google I/O Building push applications for Android15:28~18:01秒

一、前言
如果我們今天開發了一款服務型App(如︰賣雜誌的App)，
出版商希望隨時通知使用者有新的雜誌上架，
在Android上該怎麼做呢？

在iOS上，
Apple有提供訊息推播伺服器，
讓開發商很容易透過Notification Server，
將需要的資料，
即時推播到iPhone使用者的手中。
這件事在Android上也是可行的，
這個機制叫C2DM(Cloud To Device Message)。

在開始正題以前，
我們要先理解Poll和Push這2個跟Server溝通的機制。

所謂的Poll，
就是開發者以自訂的時間，
可能每1小時1次，
定時跟伺服器詢問是否有需要更新的資料。
而Push，
是從Server端推送即時訊息至手機端。

通常Poll機制用在

1.定時更新即時新聞

2.定時更新股票匯率

在這種條件下，
使用Poll機制是很方便、也很合理的。

但是，
如果每個App都使用此機制，
卻會造成電量耗損的問題，
請看我部落格中的前一篇文章！

因此，
Google建議我們使用Push機制去更新我們App的內容。

在Android手機上，
看到的Push機制的App有︰
Gmail、行事曆、Google Voice、Android Market⋯
以上這些App，
都用到了Push機制，
因此，我們才要研究C2DM。

二、文章開始
1.C2DM的使用限制
要使用C2DM機制，
有一些先決條件︰
(1)Android版本需要在2.2以上
(2)需要有Android Market - C2DM透過Android Market底層做了一些溝通和認証。

2.C2DM的使用流程
C2DM雖然只是一個"傳訊息到手機端"的簡單動作，
但它仍然有一個使用流程是我們需注意的。

本圖取自Google I/O 2010 Building push applications for Android 15:38

首先，
我們必須先取得一組registration ID。
這個registration ID是每隻Android手機中唯一的ID(不會有重覆ID的APP發生)，
一旦取得後，
需將這個ID傳至我們APP的Server。
我們App Server才會有能力能夠傳送訊息給Google Server(傳訊的使用方式︰使用http POST)。
Google Server收到App Server 使用http POST傳來的訊息後，
將其依序排列準備發送給App。

整個C2DM的操作流程，
在手機使用中、且Server端一切運作正常的狀況下，
概念是這樣的︰

1.首先，Android手機和Google Connect Server是連結的狀態(表示手機正處於上網狀態。如果不是上網狀態，會有別的狀況發生，我會在後續做討論)

2.我們的App Server會用HTTP POST告知C2DM前端︰我們希望啟動通知功能。

3-1.C2DM前端會將傳來的訊息儲存起來。

3-2.C2DM前端順便找到該裝置所歸屬的Connect Server。

4.Connect Server接著將傳送一個通知到該裝置中。

5.在傳送的過程中，其實有2件事情同步發生︰

5-1.該傳送的通知被轉成Intent，
該Intent是一個廣播訊息(Broadcast)，
它將手機喚醒(叫手機起床)。

5-2.裝置會跟Connect Server說它已經收到該通知了，
Google C2DM才知道可以把剛才的通知刪掉。

6.手機的App此時會去跟我們的App Server詢問︰
"最後一則訊息通知"為何？

7.將訊息顯示在開發者預定的位置。

三、總結

整個C2DM流程總結來說，
我們推播的訊息，
C2DM只是幫我們做到"將手機喚醒"的動作。
至於要在手機上做什麼事、顯示什麼訊息，
看起來似乎都是App Server的功居多。

下一篇︰

Android Push Notification推播機制(2)-實務篇

Wednesday, February 1, 2012

淺談Android的網路電量耗損

撰寫時間︰2012/02/02 14:30

更新時間︰2012/02/14 14:12

文章更新次數︰3

一、前言
小弟正在研究C2DM(Cloud to Device Message)雲端推播訊息至手機這個技術，
這個技術在許多App商需要及時對使用者推播廣告訊息時特別好用，
Android上著名的Chrome to Phone也是使用到這個技術，
它可以讓使用者將桌機上瀏覽的網站、Youtube、甚至是Google地圖，
馬上傳至手機中繼續觀看。

二、文章開始
在Google I/O 2010年Building push applications for Android剛好提到相關技術，
當中提到了網路與手機的電力損耗調查，

以上的圖片是Android 團隊提供的圖表，

顯示出平常App在跟Server索取資料時的電量耗損狀態。

一般來說，
在有連線狀態，
卻沒有任何的資料傳輸狀態下，
消耗的功率是 5-8mA(毫安培)/天-App。
當開始跟server端讀取資料時，
電量消耗會突然升至115mA。
如果是寫入資料，
這個消耗的電量值將會更高，
達到180-200mA甚至更高。

圖表上也顯示，
如果跟server索取資料(poll)的次數越高，
損耗功率也會跟著提高。
如果每5分鐘跟伺服器索取資料，
以一天來看，會損耗144mA。
如果以每15分鐘跟伺服器索取資料，
則一天損耗48mA。

一顆電池的壽命通常是1200mA到1400mA，
如果每5分鐘就跟server要一次資料，
這會造成一下子就耗損手機電量10%，
實在是一個很可觀的數據！

三、總結

經由上述的實驗數據，
如果你的App沒有定時定量更新的需求，
Android Team會建議你選擇Push機制才是最佳選擇。

詳細內容請參閱Android Push Notification推播機制(1)-簡介篇