Android Cloud to Device Messaging Framework

Android Cloud to Device Messaging (C2DM) is a service that helps developers send data from servers to their applications on Android devices. The service provides a simple, lightweight mechanism that servers can use to tell mobile applications to contact the server directly, to fetch updated application or user data. The C2DM service handles all aspects of queueing of messages and delivery to the target application running on the target device.
Introduction
Here are the primary characteristics of Android Cloud to Device Messaging (C2DM):
• It allows third-party application servers to send lightweight messages to their Android applications. The messaging service is not designed for sending a lot of user content via the messages. Rather, it should be used to tell the application that there is new data on the server, so that the application can fetch it.
• C2DM makes no guarantees about delivery or the order of messages. So, for example, while you might use this feature to tell an instant messaging application that the user has new messages, you probably would not use it to pass the actual messages.
• An application on an Android device doesn’t need to be running to receive messages. The system will wake up the application via Intent broadcast when the 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. C2DM simply passes raw message data received straight to the 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 Market application installed. However, you are not limited to deploying your applications through Market.
• It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.
Architectural Overview
This section gives an overview of how C2DM works.
This table summarizes the key terms and concepts involved in C2DM. It is divided into these categories:
• Components — The physical entities that play a role in C2DM.
• Credentials — The IDs and tokens that are used in different stages of C2DM to ensure that all parties have been authenticated, and that the message is going to the correct place.
Components
1. Mobile Device : The device that is running an Android application that uses C2DM. This must be a 2.2 Android device that has Market installed, and it must have at least one logged in Google account.
2. Third-Party Application Server: An application server that developers set up as part of implementing C2DM in their applications. The third-party application server sends data to an Android application on the device via the C2DM server.
3. C2DM Servers: The Google servers involved in taking messages from the third-party application server and sending them to the device.
Credentials
1. Sender ID: An email account associated with the application's developer. The sender ID is used in the registration process to identify a Android application that is permitted to send messages to the device. This ID is typically role-based rather than being a personal account—- for example, my-app@gmail.com.
2. Application ID: The application that is registering to receive messages. The application is identified by the package name from the manifest. This ensures that the messages are targeted to the correct application.
3. Registration ID: An ID issued by the C2DM servers to the Android application that allows it to receive messages. Once the application has the registration ID, it sends it to the third-party application server, which uses it to identify each device that has registered to receive messages for a given application. In other words, a registration ID is tied to a particular application running on a particular device.
4. Google User Account: For C2DM to work, the mobile device must include at least one logged in Google account.
5. Sender Auth Token: A ClientLogin Auth token that is saved on the third-party application server that gives the application server authorized access to Google services. The token is included in the header of POST requests that send messages. For more discussion of ClientLogin Auth tokens, see ClientLogin for Installed Applications.

The Visual Basic Development Environment

Overview Of The Integrated Development Environment
The Visual Basic IDE has three distinct states: Design, Run, and Debug. The current state appears in Visual Basic’s title bar.
The IDE is composed of these parts:
Ø The menu bar
Ø The toolbar
Ø The Project Explorer
Ø The Properties window
Ø The Form Layout window
Ø The toolbox
Ø Form designers
Ø Code windows

The Menu Bar
The menu bar presents the Visual Basic menus. Here_s a list of those menus and what they do:
Ø File_File handling and printing; also used to make EXE files
Ø Edit_Standard editing functions, undo, searches
Ø View_Displays or hides windows and toolbars
Ø Project_Sets project properties, adds/removes forms and modules, and adds/removes references and components
Ø Format_Aligns or sizes controls
Ø Debug_Starts/stops debugging and stepping through programs
Ø Run_Starts a program, or compiles and starts it
Ø Tools_Adds procedures, starts the Menu Editor, sets IDE options
Ø Add-Ins_Add-in manager, lists add-ins like Application Wizard and API Viewer
Ø Window_Arranges or selects open windows
Ø Help_Handles Help and the About box

The Toolbar
The toolbar contains buttons matching popular menu items, clicking the button is the same as selecting a menu item and can save you some time. Besides the main toolbar, you can also display other dockable toolbars in Visual Basic: the Debug, Edit, and Form Editor toolbars. To display one of these toolbars, just select it using the Toolbars item in the View menu; the toolbar appears free-floating at first, but you can dock it as you like in the IDE.

Form Designers And Code Windows
Form designers are really just windows in which a particular form appears. You can place controls into a form simply by drawing them after clicking the corresponding control’s tool in the toolbox.
Code windows are similarly easy to understand: you just place the code you want to attach to an object in the code window (to open an object’s code in the code window, just double-click that object). There are two drop-down list boxes at the top of the code window: the left list lets you select the object to add code to, and the right list lets you select the procedure to add (all the methods the object supports appear in this list). That completes our overview of the IDE.

Additional Features of ASP.NET 3.5 and 3.5 SP1

• New Developer Infrastructures

§ Membership and Role Management

§ Personalization

§ The ASP.NET Portal Framework

§ Site Navigation

• The ASP.NET Compilation System
• Health Monitoring for your ASP.NET Applications
• Reading and Writing Configuration Settings
• Localization
• Expanding on the Page Framework

§ Master Pages

§ Themes

• Objects for Accessing Data

Goals of ASP.NET 3.5

ASP.NET 3.5 is another mojor release of the product and build on the core .NET Framework 2.0 with additional classes and compatibilities. This release of the framework was code –named Orcas internally at Microsoft. You might hear other refer to ASP.NET as ASP.NET Orcas. ASP.NET3.5 continues on a path to make ASP.NET developers the most productive developers in the web-space.

Since the release of ASP.NET2.0 by Microsoft team has focused its goals on the developer productivity, administration and management as well as performance and scalability.

• Developer Productivity: Much of the ASP.NET 3.5 focuses on productivity. Huge productivity gains were made with the release of ASP.NET 1.x. One goal the development team had for ASP.NET was to eliminate much of the tedious coding that ASP.NET originally required to make common ASP.NET tasks easier.
• Performance and Scalability: one of the goals for ASP.NET that was set by Microsoft team was to provide the world’s fastest web application server. One of the most exiting performance capabilities is the cashing capabilities aimed at exploiting Microsoft’s SQL Server. ASP.NET 3.5 includes a feature called SQL cache invalidation. Before ASP.NET2.0, it was possible to cache the results that came from SQL Server and update the cache based on a time interval – e.g. every 15 seconds or so. This meant that the end user might see stale data if the result set changed sometime during that 15 second period. In some cases, this time interval result set is unacceptable. In ideal situation, the result set stored in the cache is destroyed if any underlying changes occurs in the source from which the result set is retrieved - in this case, SQL Server. With ASP.NET 3.5, you can make this happen with the use of SQL cache invalidation. ASP.NET 3.5 provides 64-bit support. Because ASP.NET 3.5 is fully backward compatible with ASP.NET 1.0,1.1 and 2.0 you can now take any former ASP.NET application, recompile the application on the .NET Framework 3.5, and run it on a 64-bit processor.