http://werdna1222coldcodes.blogspot.tw/2009/11/javalog4j.html
http://my.so-net.net.tw/idealist/Java/Log4j.html
2012年8月28日 星期二
2012年8月27日 星期一
Lifecycle Flow
Here are the primary processes involved in cloud-to-device messaging:
- Enabling GCM. An Android application running on a mobile device registers to receive messages.
- Sending a message. A 3rd-party application server sends messages to the device.
- Receiving a message. An Android application receives a message from a GCM server.
These processes are described in more detail below.
Enabling GCM
This is the sequence of events that occurs when an Android application running on a mobile device registers to receive messages:
- The first time the Android application needs to use the messaging service, it fires off a registration Intent to a GCM server.This registration Intent (
com.google.android.c2dm.intent.REGISTER
) includes the sender ID(註冊後網址列上的ProjectID), and the Android application ID.(APP名稱)Note: Because there is no lifecycle method that is called when the application is run for the first time, the registration intent should be sent ononCreate()
, but only if the application is not registered yet. - If the registration is successful, the GCM server broadcasts a
com.google.android.c2dm.intent.REGISTRATION
intent which gives the Android application a registration ID.The Android application should store this ID for later use (for instance, to check ononCreate()
if it is already registered). Note that Google may periodically(定期) refresh the registration ID, so you should design your Android application with the understanding that thecom.google.android.c2dm.intent.REGISTRATION
intent may be called multiple times. Your Android application needs to be able to respond accordingly. - To complete the registration, the Android application sends the registration ID to the application server. The application server typically通常 stores the registration ID in a database.
The registration ID lasts持續 until the Android application explicitly明確地
unregisters itself, or until Google refreshes the registration ID for your Android application.
unregisters itself, or until Google refreshes the registration ID for your Android application.
Note: When users uninstall an application, it is not automatically unregistered on GCM. It is only unregistered when the GCM server tries to send a message to the device and the device answers that the application is uninstalled. At that point, you server should mark the device as unregistered (the server will receive a
NotRegistered
error).
Note that it might take a few minutes for the registration ID to be completed removed from the GCM server. So if the 3rd party server sends a message during this time, it will get a valid message ID, even though the message will not be delivered to the device.
Architectural Overview
Architectural Overview
This section gives an overview of how GCM works.
This table summarizes the key terms and concepts involved in GCM. It is divided into these categories:
- Components — The physical entities that play a role in GCM.
- Credentials — The IDs and tokens that are used in different stages of GCM to ensure that all parties have been authenticated, and that the message is going to the correct place.
Components | |
---|---|
Mobile Device | The device that is running an Android application that uses GCM. This must be a 2.2 Android device that has Google Play Store installed, and it must have at least one logged in Google account if the device is running a version lower than Android 4.0.4. Alternatively, for testing you can use an emulator running Android 2.2 with Google APIs. |
3rd-party Application Server | An application server that developers set up as part of implementing GCM in their applications. The 3rd-party application server sends data to an Android application on the device via the GCM server. |
GCM Servers | The Google servers involved in taking messages from the 3rd-party application server and sending them to the device. |
Credentials | |
Sender ID | A project ID you acquire from the API console, as described in Getting Started. The sender ID is used in the registration process to identify an Android application that is permitted to send messages to the device. |
Application ID | The Android application that is registering to receive messages. The Android application is identified by the package name from the manifest. This ensures that the messages are targeted to the correct Android application. |
Registration ID | An ID issued by the GCM servers to the Android application that allows it to receive messages. Once the Android application has the registration ID, it sends it to the 3rd-party application server, which uses it to identify each device that has registered to receive messages for a given Android application. In other words, a registration ID is tied to a particular Android application running on a particular device. |
Google User Account | For GCM to work, the mobile device must include at least one Google account if the device is running a version lower than Android 4.0.4. |
Sender Auth Token | An API key that is saved on the 3rd-party application server that gives the application server authorized access to Google services. The API key is included in the header of POST requests that send messages. |
GCM Architectural Overview
GCM Architectural Overview
Quickview
- Get an introduction to key GCM terms and concepts.
- Learn the basic features of a GCM application.
- Understand the role of the 3rd-party application server, and how to send messages and process results.
In this document
To jump right into using GCM with your Android
applications, see the instructions in Getting Started.
Introduction
Here are the primary characteristics of Google Cloud Messaging (GCM):
- It allows 3rd-party application servers to send messages to their Android applications.
- GCM makes no guarantees about delivery or the order of messages.
- An Android application on an Android device doesn't need to be running to receive messages. The system will wake up the Android application via Intent broadcast when the message arrives, as long as the application is set up with the proper broadcast receiver and permissions.
- It does not provide any built-in user interface or other handling for message data. GCM simply passes raw message data received straight to the Android application, which has full control of how to handle it. For example, the application might post a notification, display a custom user interface, or silently sync data.
- It requires devices running Android 2.2 or higher that also have the Google Play Store application installed, or or an emulator running Android 2.2 with Google APIs. However, you are not limited to deploying your Android applications through Google Play Store.
- It uses an existing connection for Google services. For pre-3.0 devices, this requires users to set up their Google account on their mobile devices. A Google account is not a requirement on devices running Android 4.0.4 or higher.
2012年8月25日 星期六
using plain text
If you are using plain text instead of JSON, the message fields must
be set as HTTP parameters sent in the body, and their syntax is slightly
different, as described below:
If you want to test your request (either JSON or plain text) without delivering the message to the devices, you can set an optional HTTP parameter called
Field | Description |
---|---|
registration_id |
Must contain the registration ID of the single device receiving the message. Required. |
collapse_key |
Same as JSON (see previous table). Optional. |
data.<key> |
Payload data, expressed as parameters prefixed with data. and suffixed as the key. For instance, a parameter of data.score=3x1 would result in an intent extra named score whose value is the string 3x1 .
There is no limit on the number of key/value parameters, though there
is a limit on the total size of the message. Note that the key cannot
be a reserved word (from or any word starting with google. ). Optional. |
delay_while_idle |
Should be represented as 1 or true for true , anything else for false . Optional. The default value is false . |
time_to_live |
Same as JSON (see previous table). Optional. |
If you want to test your request (either JSON or plain text) without delivering the message to the devices, you can set an optional HTTP parameter called
dry_run
with the value true
.
The result will be almost identical to running the request without this
parameter, except that the message will not be delivered to the devices.
Consequently, the response will contain fake IDs for the message and
multicast fields (see Response format).
For JSON, it must contain a string representing a JSON object with the following fields:
string representing a JSON object with the following fields:
Field | Description |
---|---|
registration_ids |
A string array with the list of devices (registration IDs) receiving the message. It must contain at least 1 and at most 1000 registration IDs. To send a multicast message, you must use JSON. For sending a single message to a single device, you could use a JSON object with just 1 registration id, or plain text (see below). Required. |
collapse_key |
An arbitrary string (such as "Updates Available") 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. See Advanced Topics for more discussion of this topic. Optional, unless you are using the time_to_live parameter—in that case, you must also specify a collapse_key . |
data |
A JSON object whose fields represents the key-value pairs of the message's payload data. If present, the payload data it will be
included in the Intent as application data, with the key being the extra's name. For instance, "data":{"score":"3x1"} would result in an intent extra named score whose value is the string 3x1 .
There is no limit on the number of key/value pairs, though there is a
limit on the total size of the message (4kb). Note that the values must be enclosed by strings.
If you want to include objects or other non-string data types (such as
integers or booleans), you have to do the conversion to string yourself.
Also note that the key cannot be a reserved word (from or any word starting with google. ). Optional. |
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. The default value is false , and must be a JSON boolean. |
time_to_live |
How long (in seconds) the message should be kept on GCM storage
if the device is offline. Optional (default time-to-live is 4 weeks, and
must be set as a JSON number). If you use this parameter, you must also
specify a collapse_key . |
The following table specifies the API Level supported by each version of the Android platform.
Migrating Your Apps
Migrating Your Apps
This section describes how to move existing C2DM apps to GCM.
Client changes
Migration is simple! The only change required in the application is replacing the email account passed in the sender parameter of the registration intent with the project ID generated when signing up for the new service. For example:Intent registrationIntent = new Intent("com.google.android.c2dm.intent.REGISTER"); // sets the app name in the intent registrationIntent.putExtra("app", PendingIntent.getBroadcast(this, 0, new Intent(), 0)); registrationIntent.putExtra("sender", senderID); startService(registrationIntent);
After receiving a response from GCM, the registration ID obtained
must be sent to the application server. When doing this, the application
should indicate that it is sending a GCM registration ID so that the
server can distinguish it from existing C2DM registrations.
從GCM接收到響應後,所獲得的註冊ID必須被發送到應用程序服務器。在這樣做時,應用程序應該表明它已被發送一個GCM註冊ID,這樣服務器可以區分它從現有的C2DM註冊。
Server changes
When the application server receives a GCM registration ID, it should store it and mark it as such.Sending messages to GCM devices requires a few changes:
- The request should be sent to a new endpoint:
https://android.googleapis.com/gcm/send
. - The Authorization header of the request should contain the API key generated during sign up. This key replaces the deprecated ClientLogin Auth token.
Content-Type:application/json Authorization:key=AIzaSyB-1uEai2WiUapxCs2Q0GZYzPu7Udno5aA { "registration_id" : "APA91bHun4MxP5egoKMwt2KZFBaFUH-1RYqx...", "data" : { "Team" : "Portugal", "Score" : "3", "Player" : "Varela", }, }For a detailed discussion of this topic and more examples, see the Architectural Overview.
Eventually, once enough users of your application have migrated to the new service, you might want to take advantage of the new JSON-formatted requests that give access to the full set of features provided by GCM.
2012年8月24日 星期五
append()
append()
http://blog.xuite.net/x_3kkk/java/11386460-%E5%AD%97%E4%B8%B2%E7%9A%84%E6%96%B0%E5%A2%9E%E8%88%87%E6%8F%92%E5%85%A5+%28+append+%2F+insert+%29
http://blog.xuite.net/x_3kkk/java/11386460-%E5%AD%97%E4%B8%B2%E7%9A%84%E6%96%B0%E5%A2%9E%E8%88%87%E6%8F%92%E5%85%A5+%28+append+%2F+insert+%29
2012年8月17日 星期五
2012年8月15日 星期三
compile kernel error
out/host/linux-x86/obj/EXECUTABLES/test-librsloader_intermediates/test-librsloader] Error 1
1. Install gcc4.4
apt-get gcc-4.4 and gcc-4.4-multilib and do
2. Use this command to build
make CC=gcc-4.4 CXX=g++-4.4
https://groups.google.com/forum/#!msg/android-building/GhtCJSBDwUw/WkKtUiNB_moJ[1-25]
out/host/linux-x86/obj/EXECUTABLES/aapt_intermediates/aapt
https://groups.google.com/forum/#!msg/android-building/GhtCJSBDwUw/WkKtUiNB_moJ[1-25]
out/host/linux-x86/obj/EXECUTABLES/aapt_intermediates/aapt
2012年8月8日 星期三
Java note
@link:
/**
*亂說一同
* @link package.class #getValue
* @param
* @see #getValue
*/ @link是一個連接標記,在doc裡會多增加一個See Also(默認的類是自己) #member label就是把@see獲取到。你可以試一下就明白了
http://topic.csdn.net/t/20031222/14/2589902.html
http://www.thebuzzmedia.com/supported-values-for-suppresswarnings/
public class GCMIntentService extends GCMBaseIntentService {
// @SuppressWarnings("hiding")
private static final String TAG = "GCMIntentService";
public GCMIntentService() {
super("SENDER_ID");
}
/**
*亂說一同
* @link package.class #getValue
* @param
* @see #getValue
*/ @link是一個連接標記,在doc裡會多增加一個See Also(默認的類是自己) #member label就是把@see獲取到。你可以試一下就明白了
http://topic.csdn.net/t/20031222/14/2589902.html
@SuppressWarnings
hiding to suppress warnings relative to locals that hide variable
java.lang.Object IntentService com.google.android.gcm.GCMBaseIntentService
Field Summary | |
---|---|
static java.lang.String | TAG |
protected GCMBaseIntentService(String senderId) {
// name is used as base name for threads, etc.
super("GCMIntentService-" + senderId + "-" + (++sCounter));
mSenderId = senderId;
}
Constructor Summary | |
---|---|
protected | GCMBaseIntentService()
Constructor that does not set a sender id, useful when the sender id is context-specific. |
protected | GCMBaseIntentService(java.lang.String... senderIds)
Constructor used when the sender id(s) is fixed. |
訂閱:
文章 (Atom)