Avoiding Memory Leaks : Android Program

Avoid Memory leaks in Android Program.


* Do not keep long-lived references to a context-activity (a reference to an activity should have the same life cycle as the activity itself)

At the onset of learning customizing lists its tempting to do this mistake. We just pass reference of the present context to the adapater.
Now the problem arises when we use our programming skills to release the activity and its resources on OnDestroy callback, while activity gets destroyed but remember reference to the this activity context is still referenced by our list. And this leaks the Context means it can't be reclaimed by Garbage collector.

* Try using the context-application instead of a context-activity
Context.getApplicationContext() and use it in the application.

* Avoid non-static inner classes in an activity if you don't control their life cycle, use a static inner class and make a weak reference to the activity inside. The solution to this issue is to use a static inner class with a WeakReference to the outer class, as done in ViewRoot and its W inner class for instance


* A garbage collector is not an insurance against memory leaks

Android c2dm : Demystified

Motivation

My Project manager told me that he doesn't want to poll the server frequently to get the updated data. Probably he wants to come up with a solution that doesn't drains user pocket (due to Network Connection on Mobile operator's GPRS) and device battery.

Googled net a lot and found that Google Android Team has already come up with a solution Android Cloud to Device Messaging framework for Android 2.2 to resolve the above issues by using server push mechanism to send updates to devices.

Thanks Google.

So what's this Cloud to Device Messaging Framework.

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.


Architectural Overview : Working

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

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.

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.

C2DM Servers

The Google servers involved in taking messages from the third-party application server and sending them to the device.

Credentials


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.
Generally while registering the account at c2dm servers only test quota is given . To get production quota a discussion with c2dm server maintainers is needed. Production quota is not free.

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. Important to keep the package name same.

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 Account

For C2DM to work, the mobile device must include at least one logged in Google account.

Sender Auth Token

Auth token that the sender has already got from Google servers using ClientLogin.

Below it the php code to get AuthToken using Client Login

$userName=$_REQUEST['userName'];
$passWord=$_REQUEST['passWord'];
$userName="email add";
$passWord="password";
$auth = exec("curl https://www.google.com/accounts/ClientLogin \
--data-urlencode Email=".$userName." --data-urlencode Passwd=".$passWord." \
-d accountType=GOOGLE \
-d source=Google-cURL-Example \
-d service=ac2dm");
echo $auth;

$realAuth = substr($auth,5);

echo "


".$realAuth;

echo "


".strlen($realAuth);

mysql_connect("localhost","root","success") or die ('error connecting to mysql');
mysql_select_db("ctodm") or die('error connecting to database');
// put here logic where first id is determined if found values will be updated
// else new row would be inserted
$authorizeAccount=$userName;
$query = "TRUNCATE TABLE `tokendet`";
$query = "INSERT INTO tokendet (tokenid,senderemail) VALUES ('$realAuth','$authorizeAccount')";

mysql_query($query) or die ("Error updating database");

echo 'database updated';


After getting the authtoken store it in a database table.

Now get the client code modify it and use it


Client Code : https://sites.google.com/site/androidosbeginning/C2DM.zip?attredirects=0&d=1

If issues in using it ... wait for the next post I will be back.


Thanks