Third Party Applcation Server

The Third Party Server is *your* server and can actually be any process written in any language (for example, it can be a batch process or a cron script). The role of the 3rd party "server" is to send the message to the device.

The Server will store (or update) the registrationID received into its local database. So, eventually the server will have registrationIDs from the devices.
Your server needs to get a ClientLogin Auth token in order to talk to the C2DM servers. When it wants to push a message to the device.
For ClientLogin Auth_Token: Click Here

To send a message to a particular device, the Server needs to POST to the C2DM Service the following 4 things:

1.  The accountName which will be arxxus.pushapp@gmail.com .
2. An authentication Token.
3. The registrationID of the device it wants to send the message. 
4. The message itself (Message limit 1024 Bytes)

Code:

// Create a new HttpClient and Post Header 

HttpClient httpclient = new DefaultHttpClient(); 

HttpPost httppost = new HttpPost("https://android.apis.google.com/c2dm/send"); 

//Your Authorization Token

httppost.addHeader("Authorization", "GoogleLogin auth="+authToken); 

httppost.addHeader("Content-Type","application/x-www-form-urlencoded"); 

            

// Add your data 

List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>(2); 

nameValuePairs.add(new BasicNameValuePair("registration_id",regId)); 

nameValuePairs.add(new BasicNameValuePair("collapse_key", "TEST")); 

//.<message> is the key and Message is "Push Contact"

nameValuePairs.add(new BasicNameValuePair("data.message","Push Contact")); 

httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs,"UTF-8")); 

// Execute HTTP Post Request 

System.out.println("Executing  sendMessage"); 

HttpResponse response = httpclient.execute(httppost); 

System.out.println(response.getStatusLine()); 

if (response.getEntity() != null) 

{ 

         System.out.println(EntityUtils.toString(response.getEntity())); 

}

This code work properly on Apache Tomcat Server but while deploying this code on the Google App Engine you will get the Restricted class issues..So if you are thinking of deploying on Google App Engine Try this...

// Send a sync message to this Android device.

URL url = new URL("https://android.apis.google.com/c2dm/send");

HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();

urlConnection.setRequestMethod("POST");

urlConnection.setDoOutput(true);

urlConnection.setUseCaches(false);

urlConnection.setRequestProperty("Authorization", "GoogleLogin auth="+Constants.authToken); 

urlConnection.setRequestProperty("Content-Type","application/x-www-form-urlencoded");

urlConnection.setRequestProperty("Accept", "text/html, */*");

urlConnection.setRequestProperty("Connection", "keep-alive");

//Send MEssage

StringBuilder postDataBuilder = new StringBuilder();

postDataBuilder.append("registration_id"). append("=").append("YOUR_REGISTRATION_ID");

postDataBuilder.append("&").append("collapse_key").append("=").append("TEST");

postDataBuilder.append("&").append("data.message").append("=").append(message);

byte[] postData = postDataBuilder.toString().getBytes(URLEncoder.encode("UTF-8"));

//Executing  sendMessage

OutputStream outputStream = urlConnection.getOutputStream();

outputStream.write(postData);

outputStream.close();

int responseCode = urlConnection.getResponseCode();

If you like this post..Please do comments..

THANKS...

Software Release life cycle

Life Cycle of Software Release:
A software release lifecycle consists of different stages that report the stability of a piece of program and the amount of development is necessary before the final release. It is the distribution of software code, documentation, and support materials and composed of discrete phases that describe the software's maturity as it advances from planning and development to release and support phases.

Each version of a product goes through a stage when new features are added, or the alpha stage, a stage that is being actively debugged, or the beta stage, and finally a stage in which all major errors have been removed, or the stable phase. Intermediate stages may even be recognized. The stages can be formally announced and regulated by the developers of the project, but sometimes the terms are used informally to report the status of a product.

Pre-alpha:

Pre-alpha refers to all activities performed during the software project prior to testing. These activities can include requirement analysis, software design, software development and unit testing.

Alpha:

The alpha phase of the release life cycle is the first phase to begin software testing (alpha is the first letter of the ancient Greek alphabet, used as the number 1). In this phase, developers generally test the software using white box technique. Additional validation is then performed using black box or gray box techniques, by another testing team. Moving to black box testing inside the organization is known as alpha release.Alpha software can be unstable and could cause crashes or data loss. The exception to this is when the alpha is available publicly (such as a pre-order bonus), in which developers normally push for stability so that their testers can test properly. External availability of alpha software is uncommon.

Beta:
Beta is the software development phase following alpha (beta is the second letter of the ancient Greek alphabet, used as the number 2. It is not nowadays usual to speak of a later gamma test). It generally begins when the software is feature complete. The focus of beta testing is reducing impacts to users, often incorporating usability testing. The process of delivering a beta version to the users is called beta release and this is typically the first time that the software is available outside of the organization that developed it.The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software, willing to test the software without charge, often receiving the final software free of charge or for a reduced price.
Beta version software is often useful for demonstrations and previews within an organisation and to prospective customers. Some developers refer to this stage as a preview, prototype, technical preview (TP), or early access.

Release candidate:
The term release candidate (RC) refers to a version with potential to be a final product, which is ready to release unless fatal bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bug.
Other Greek letters, such as gamma and delta, are sometimes used to indicate versions that are substantially complete, but still undergoing testing, with omega or zenith used to indicate final testing versions that are believed to be relatively bug-free, ready for production.
A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There may still be source code changes to fix defects. There may still be changes to documentation and data files, and to the code for test cases or utilities. New code may be added in a future release.

RTM:

The term "release to manufacturing" or "release to marketing" (both abbreviated RTM, initials also commonly used for the quite different "return to manufacturer" of faulty goods)—also known as "going gold"—is a term used when software is ready for or has been delivered or provided to the customer. It is typically used in certain retail mass-production software contexts—as opposed to a specialized software production or project in a commercial or government production and distribution—where the software is sold as part of a bundle in a related computer hardware sale and typically where the software and related hardware is ultimately to be available and sold on mass/public basis at retail stores to indicate that the software has met a defined quality level and is ready for mass retail distribution. RTM could also mean in other contexts that the software has been delivered or released to a client or customer for installation or distribution to the related hardware end user computers or machines. The term does not define the delivery mechanism or volume; it only states that the quality is sufficient for mass distribution.

General availability:
General availability or general acceptance (GA) is the point where all necessary commercialization activities have been completed and the software has been made available to the general market either via the web or physical media.

Google App Engine - Restrictions

Google offers a cloud computing infrastructure called Google App Engine (App Engine) for creating and running web Applications. App Engine allows the dynamic allocation of system resources for an application based on the actual demand. Currently App Engine supports Python and Java based applications.

But Google App engine have some Restrictions

GoogleApp Engine runs a version of Java 6 but does not provide all Java classes, for example Swing and most AWT classes are not supported.

You cannot use Threads or frameworks which uses Threads. You can also not write to the filesystem and only read files which are part of your application. Certain "java.lang.System" actions, e.g. gc() or exit() will do nothing. You can not call JNI code. Reflection is possible for your own classes and standard Java classes but your cannot use reflection to access other classes outside your application.
A servlet needs also to reply within 30 seconds otherwise a com.google.apphosting.api.DeadlineExceededException" is thrown.

See   JRE Class White List