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 queuing of messages and delivery to the target application running on the target device.

CHARACTERISTICS OF ANDROID CLOUD TO DEVICE MESSAGING (C2DM)

Primary characteristics of C2DM are:

1. 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.
2. 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.
3. It uses an existing connection for Google services. This requires users to set up their Google account on their mobile devices.

ARCHITECTURAL OVERVIEW

Cloud to Device Messaging includes key terms and concepts which can be classified in to two divisions. They are:

1. Components
2. Credentials

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.

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

Application ID

It is the id of an 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.

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. Google User Accountfor C2DM to work, the mobile device must include at least one logged in Google account.

Sender Auth Token

A ClientLoginAuth 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.

LIFE CYCLE OF CLOUD TO DEVICE MESSAGING

Here are the primary processes involved in cloud-to-device messaging:

1. Enabling C2DM: An Android application running on a mobile device registers to receive messages.
2. Sending a message: A third-party application server sends messages to the device.
3. Receiving a message: An Android application receives a message from a C2DM server.
   

   Enabling C2DM

   Following are the sequence of events that occurs when an Android application running on a mobile device registers to receive messages:

   1. The first time the application needs to use the messaging service, it fires off a registration Intent to a C2DM server.

   This registration Intent includes the sender ID (that is, the account authorized to send messages to the application, which is typically the email address of an account set up by the application’s developer), and the application ID.

   1. The C2DM server broadcasts a Intent which gives the application a registration ID.

   The application stores this ID for later use. Google may periodically refresh the registration ID, so the application is designed with the understanding that the REGISTRATIONntent may be called multiple times.

   1. To complete the registration, the 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 application explicitly unregisters itself, or until Google refreshes the registration ID for your application.

   Sending a Message

   For an application server to send a message, the following things must be in place:

   • The application has a registration ID that allows it to receive messages for a particular device.
   • The Registration Id is stored at the Application Server.

   There is one more thing that needs to be in place for the application server to send messages: a Client Login authorization token. The Client Login token authorizes the application server to send messages to a particular Android application. An application server has one Client Login token for a particular 3rd party app, and multiple registration IDs. Each registration ID represents a particular device that has registered to use the messaging service for a particular 3rd party app.

   Here is the sequence of events that occurs when the application server sends a message:

   1. The application server sends a message to C2DM servers.
   2. Google queues and stores the message in case the device is inactive.
   3. When the device is online, Google sends the message to the device.
   4. On the device, the system broadcasts the message to the specified application via Intent broadcast with proper permissions, so that only the targeted application gets the message. This wakes the application up. The application does not need to be running beforehand to receive the message.
   5. The application processes the message. If the application is doing non-trivial processing, you may want to grab a wake lock and do any processing in a Service.

   An application can unregister C2DM if it no longer wants to receive messages.

   Receiving Message

   This is the sequence of events that occurs when an Android application running on a mobile device receives a message:

   1. The system receives the incoming message and extracts the raw key/value pairs from the message payload.
   2. The system passes the key/value pairs to the targeted Android application in a Intent as a set of extras.
   3. The Android application extracts the raw data from the Intent by key and processes the data.

Android 3.0 comes with a new UI designed from the ground up for tablets. With so many tablets in the market, UI is going to be a crucial factor to attract consumers to your device and the Google team has nailed it this time by providing an altogether new UI framework for developers, which will allow developers to create a richer, more interactive experience for users. We’re really excited about Activity fragments, which provide greater control of content and design flexibility.

This will allow developers to come up with apps, which are more intuitive and engaging thereby increasing the overall user experience. The Activity fragment feature is supplemented by redesigned UI widgets which can now be used as remote views in application widgets displayed on the home screen. Other exciting features of Android 3.0 Platform include Persistent Action Bar and Richer Notifications. It’s really a neat idea to provide each application with its own instance of the Action Bar at the top of the screen. This will allow developers to expose more features of their applications to users in a familiar location.

We know that the notification mode is arguably better on Android devices as compared to iOS. And this just got better with Android 3 SDK, which includes new builder class thereby allowing developers to quickly create notifications that include large and small icons, a title, a priority flag, and any properties already available in previous versions. In Android, all notifications are neatly organized in an expandable menu. So, whenever any of these notifications appear, they are quickly displayed for some time in a small strip that always stays at the top of the screen. iOS 4 still follows pop-up notifications, which may occasionally interfere with whatever apps you’re running at the time.

There’s also some good news for Android Game Developers. Android 3.0 offers a new hardware-accelerated OpenGL renderer that gives a performance boost to many common graphics operations for applications running in the Android framework. And if this was not enough, Google has also included RenderScript with Android 3.0, which is a runtime 3D framework for accelerating graphics operations and data processing. It seems like we are going to see some really exciting games for Android in the near future!

Android 3.0 also includes some other smart features likes HTTP Live streaming and Digital Media file transfer. Overall, it’s an impressive release and we hope that the developers will make full use of it!

• onCreate(): This is called when the activity first starts up. You can use it to perform one-time initialization such as launching the user interface. onCreate() utilizes one parameter that is either null or state information previously saved by the onSaveInstanceState( ) method, discussed below.
• onStart(): This indicates the activity is about to be displayed to the user.
• onResume(): This is called when the user can start interacting with the activity. This is a good place to start animations and music.
• onRestart(): If this is called, it indicates your activity is being redisplayed to the user from a stopped state.
• onFreeze(): Allows you to save your current state when one activity is being paused and another one resumes to interact with the user. After being paused, the system may at any time need to stop (or even outright kill) your application in order to claim resources for the current foreground activity. If this should happen, the state you supply here will later be recalled with onCreate(), when the user starts a new instance of your activity.
• onPause(): This runs when the activity is about to go into the background, usually because another activity has been launched in front of it. This is where you should save your program’s persistent state, such as a database record being edited.
• onStop(): This is called when your activity is no longer visible to the user and it won’t be needed for a while. If memory is tight, onStop() may never be called (the system may simply terminate your process).
• onDestroy(): This is called right before your activity is destroyed. If memory is tight, onDestroy( ) may never be called (the system may simply terminate your process).
• onSaveInstanceState(Bundle): Android calls this method to allow the activity to save per-instance states, such as a cursor position within a text field. Usually you won’t need to override it because the default implementation saves the state for user interface controls automatically.
• onRestoreInstanceState(Bundle): This is called when the activity is being reinitialized from a state previously saved by the onSaveInstanceState() method. The default implementation restores the state of your user interface.

I hope this brings you up to speed on Android Activity Classes. Be sure to have a thorough look at the attached diagram below (click –> full size) for a concrete overview of what we’ve been discussing here. The more familiar you are with Activity Classes and how and they affect the end user experience, the more successful your Android apps development will be.

If you have any questions or requests re: Android apps dev, drop us a line via the contact form at mothership Sourcebits and we’ll get back to you as soon as we can, perhaps even posting a tutorial here on these pages.

Best of luck,
Sudhir N Kamath
Sr. QA Engineer
Sourcebits Technologies, Ltd.

Learn it, Live it, Reap ze glory.

Step 1: Create a database-using application:

For example, as follows:

Application: TestDatabase

Package Name: com.android.TestDatabase

Database Name: TestingDatabase

Table Name: TestingTable

Step 2: Launch the application to create a database for the application.

Step 3: Open a command prompt. For example, on Windows, go to Start > Run and type “cmd”

Step 4: Navigate to the tools folder in the Android SDK.

Step 5: Input the following at the command prompt:

d:\android-sdk\tools>adb shell

# cd data/data

# cd com.android.TestDatabase

# cd databases

# sqlite3 TestingDatabase;

sqlite3 TestingDatabase

SQLite3 version x.x.x

Enter ".help" for instructions

sqlite>

Step 6: From here you can fire your queries.

For example:

sqlite> select * from TestingTable;

Step 7: To exit, press ctrl+c

Step 8: Then you can check the directories inside the folder.

For example, let’s check all the databases created in the folder “databases”

Type:

# cd databases

# ls

ls

TestingDatabase

Thanks for reading, and I hope this helps.  If you have any questions about this specific tutorial or any other issues re: coding for Android, drop us a line any time from our contact page!

Nirav Shah
Software Engineer
Sourcebits Tech Pvt Ltd.

Whenever a user launches an Android application, a thread called “main” is automatically created. This main thread, also called the UI thread, is crucial since it’s responsible for dispatching events to various widgets, including the drawing events. For careless Android developers, this single thread can be the overarching reason for poor app performance. With so much riding on a single thread performing long operations like network access or database queries, any interference on this thread will block up the entire user interface. No events can be dispatched – including drawing events – while long operations are underway, and from the user’s perspective, the application appears hung. Even worse, if the UI thread is blocked for more than a few seconds (about 5 seconds currently) the user will encounter the dreaded “application not responding” (ANR) dialog.

BaseAdapter is an Adapter object that acts as a bridge between an AdapterView and the underlying data for that view. The Adapter provides access to specific data points and is also responsible for making a View for each point in the data set. So, taking the example of downloading an image over HTTP, there may be some slowdown in our application with the Main UI thread getting blocked for more than a few seconds, and users might be presented with the ANR dialog. To avoid this situation I have some suggestions:

1. Use ExecuterService (Thread pool)
2. Use AsynTask
3. Use SoftReference Drawable Object
4. Create the ListView first, then download images
5. Make use of OnScrollListener Interface

I’ve written a sample application to help Android developers visualize this implementation.

Here we have AbastractListAdapter, an extension of BaseAdapterClass:

public abstract class AbstactListAdapter extends BaseAdapter {
	public AbstactListAdapter(Context context) {
		this.context = context;
	}
	public abstract void setScrollStatus(boolean scroll);
	public abstract void scrollIdle(AbsListView view);
}

There are two methods of implementation for Class ListAdapterScrollListener and Onscrollistner.

public void onScroll(AbsListView view, int firstVisibleItem,int visibleItemCount, int totalItemCount) {
		adapter.setScrollStatus(true);
	}
public void onScrollStateChanged(AbsListView view,intSrollState) {
		switch (scrollState) {
		case OnScrollListener.SCROLL_STATE_IDLE:
			adapter.scrollIdle(view);
			break;
		case OnScrollListener.SCROLL_STATE_TOUCH_SCROLL:
			adapter.setScrollStatus(true);
			break;
		case OnScrollListener.SCROLL_STATE_FLING:
			adapter.setScrollStatus(true);
			break;
		}
}

In my onCreate method I set up and configure the list view to load the views and set the listner for Scroll.

public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Adapter mAdapter=new Adapter(this);
        setListAdapter(mAdapter);
        getListView().setOnScrollListener(new 		ListAdapterScrollListener(mAdapter));
      }

I use an Adapter class to extend AbstractAdapterClass and implement BaseAdapter, both of which help to load images when scrolling is idle.

The image is loaded in a separate threadpool. I have used Executerservice and assign a threadpool to download images. This method employs a runnable which will extend Assigntask. This ImageLoader class has a subclass, workerthread, which extends Assyntask and implements runnables. This class uses ExecutorService, and assigns 5 threads to do the work. Other implementations of this kind launch a separate thread per image, meaning that the network connection will become clogged with any image load. Assigning the task to the workerthread subclass and using onprogressupdate to notify the adapter to display the image reduces the burden.

You’ll notice the use of SoftReference here. While this appears to work well, I haven’t done any significant load or performance testing, so it may not be necessary. Since bitmap/drawable objects require memory, and Android supports 16mb of heap, it’s better to classify those objects as SoftReference objects. SoftReferences pointing to softly reachable objects are guaranteed to be cleared before the VM triggers an OutOfMemoryError. This can be written as follows:

 public class ImageLoader {

private class WorkerThread extends AsyncTask implements Runnable{
		public WorkerThread(String url,int pos) {
			this.url=url;
			intex=pos;
			}
		@Override
		protected void onProgressUpdate(Void... values) {
			mAdapter.notifyDataSetChanged();
			super.onProgressUpdate(values);
		}
		@Override
		public void run() {
			Cache.put(intex,new SoftReference(readDrawableFromNetwork(this.url)));
			publishProgress();
		}
	}

	public Drawable getDrawble(int pos)
	{
		SoftReference mReference=Cache.get(pos);;
		if(mReference!=null)
			return mReference.get();
		else
			return null;
	}

/*method to get Image if already or to start new task to download*/
	public void loadImage(int First,int Last) {
			try{
					_exec = Executors.newFixedThreadPool(5);
				for(int pos=First;pos<=Last;pos++){
					if(Cache.containsKey(pos)){
						if(Cache.get(pos).get()==null)
							_exec.execute(new  WorkerThread(Dataset.mStrings[pos],pos));
					}else{
						_exec.execute(new  WorkerThread(Dataset.mStrings[pos],pos));
					}
				}
			}catch (Exception e) {
				_exec.shutdown();
			}

	}//end of method

	private static Drawable readDrawableFromNetwork(String url ) {
	   Write code here to downlaod image from network.
	}//end of method
}

And that’s it!

For your reference, the code has been packaged for you to download and inspect here.

Anyone with significant time in mobile application development understands the challenges of writing portable applications. There are tons of reasons for this, but probably the biggest hurdles we face are:

• Varying screen sizes
• Varying screen resolutions
• Varying hardware configurations
• Varying media formats; such as for images, audio, video
• Varying input methods; e.g. touch screen, T9 key pad, qwerty keypad
• Non-standard, device-specific hardware keys

And so on and so forth >_<

Android engineers, anticipating the witches brew of OEM handsets they would encounter, took steps to try and alleviate the situation by standardizing some key features:

• A very rich widget set that can scale according to needs
• Standardized way of implementing custom widgets
• Standardized user interface conventions for touch screen devices
• Standardized image capture formats {still buggy from time to time}
• Standardized mechanism for sharing code across different components; such as user interface elements, fixed content or a specific activity
• Standardized on a base set of hardware keys; e.g. Home, Back, End, and Trackball

Above notwithstanding, with screen sizes and resolutions still very much device dependent {see: T-Mobile G1, Motorola Droid, Google Nexus One, HTC Hero and so on}, creating a consistent UI that both looks good and works well on all platforms has been a slog. For Android developers or those just interested in Android application development, here we present a method and a design pattern that can be utilized to achieve precisely that. The focus points are as follows:

• Understand the functionality that needs to be replicated per device. This can be represented by a Java interface to achieve, for example, scaled UI elements across varying screen sizes and resolutions.
• Separate device-specific features into device-specific implementations. For example, each phone {including from the same manufacturer} might have different hardware keys, or even different keypads (such as T9, QWERTY, or SureType). If an application is to work on different phones with different input mechanisms, it must take into account these differences when implementing.
• A Class Factory that can intelligently instantiate the device-specific components of multiple handset designs.

Let’s take for example the case of displaying a splash screen at application launch. Here we address the issue of supporting for multiple devices. The first act of separating the functionality begins with this interface:

public interface SplashableScreen {
public void showSplashImage(ImageView mView);
public void startSpalshing() throws Exception;
public void SetSplashDuration(int time);

}

Any screen that can be shown as a splash has the functionality as described by the methods indicated.

A device-specific implementation / screen-specific implementation can be written as follows:

public class SplashScrren_320_480 implements SplashableScreen{
public void showSplashImage(ImageView mView){
// Write code speficic to this resolution.
}

}

And a proper implementation can be instantiated and used as follows:

public class SplashFactory{
public static SplashableScreen getSplashScreen(){
// Given a device metrics, instantiate appropriate class and return.
}
}

We’re pleased to offer the full code for this useful application for download here.

Android facebook users, you don’t have to feel left out of the facebook juggernaut anymore – you get the same easy to use, popular facebook that is making waves on the iPhone, on your Android.

The Design follows the same popular features of facebook you are used to, and far superior to the clones that are a dime a dozen on the android market.

Of course you have to use certain features like registering for an account and editing your profile settings on the popular facebook website , but this app comes very close to the home grown iPhone app. Actually, it beats it in looks and some features of user-intuitiveness.

Facebook opened up its API for 3^rd party development, saying they were not interested to pursue other platforms after having developed an in-house version for the iPhone. RIM engineers also collaborated with Facebook to develop one for the blackberry. One is not aware of the reason why this step motherly treatment for Android, but it is. This could be due to Google going the MySpace way, but it is true that Facebook has even stopped building their API in java since mid 2008.

Facebook has not opened up its API fully. It is still holding on to Chat and Inbox APIs. A lot of Android and 3^rd party apps out there are only catering to obtaining News Feeds, friend -lists from Facebook and sending SMSs in the form of status updates, and thats about it!.

AndroidBook has broken the barrier, it is the closest you can get to the iPhone app developed by Facebook. We did it the tough way – but we did it!. This despite the fact that facebook for iPhone is a homegrown application, which had access to the closed facebook APIs.

Features of AndroidBook:

• Login – Login to Facebook, and provide link to Facebook website for Sign Up

Home:

• News Feeds (Status Updates and Links)
• Notifications (Updates to Photos)
• Requests (Friend requests)

Profile:

• Wall (Compose status updates on wall)
• Info (Information of Logged in User)
• Photos, Take, Replace and Upload to personal Album.

Friends:

• Friends Search and Friends Profile

Chat:

• Chat with Available friends

E-mail:

• Inbox (Select, Compose, Reply and Send)
• Sent (Delete)
• Updates (Events Notifications)

Take Photo, Cancel, Replace or Save photo (store locally or upload to personal album)
Logout