Sunday, December 23, 2012

Thinking beyond sandbox.

 What? Why?

Hi, This is Manish . Good morning today I am sharing my past two months experience via this blog . catch it if you can.... :)

How can we achieve the goal by thinking beyond the sandbox  (private SVN location in my old company....:) ). it's nothing just an Objective oriented thinking.  I find it very useful for decision making, project planning, debates, problem solving, …. Sometime I get stuck in an activity (e.g problem solving, debating) for too long and it seems that it will not come to an end or conclusion. Objective oriented thinking helps by defining/discovering an objective and aligns all my thoughts toward achieving that objective .

How?

Frequently ask yourself, what is the objective/purpose/goal. at least 10 times if you are beginner. If you are planning a new project, ask what is the desire outcome of this project. If you have been working on a task for some time, ask why are you doing it or what is the purpose of doing it. It helps you to “take a step back”, take a look at what you are doing and remind yourself what you want to achieve.
Objectives can be easily defined by continuously asking what and why. These are some of the questions that helps to define objectives:
  • What does the customer want?
  • Why are you doing it?
  • What do you want to achieve?
  • What is the expected outcome?
  • What is the goal of the company?

Being Specific

   "Engineer aur Dhakkan me dhage bhar ka fark hota hai, dhage ke is par engineer aur us par Dhakkan......:)" (in Hindi)
If the objective is to be “successful”, you must define what is “successful”. If objective is not clearly defined, it will never be achieved. Being specific helps. It is good to use measurable/testable metrics to describe objectives. At individual level, these metrics make it easy to plan out verifiable actions to achieve objective. When working in a team, these metrics ensure everyone in the team has a common picture of the goal they want to achieve.

Application

    "I am not talking about Hangman  here........  :)"
These are some examples on how objective oriented thinking can be used in daily life.
  1. Project Planning
    Define the objective (e.g backup all data on server). Based on the objective, defines measurable/testable metrics (e.g. list of all data that needs to be backup). When the objective is communicated to the team, the members know what needs to be done and be able to make decisions when project manager is not around.
  2. Debates
    Arguing over subjective matters is a time waster. Define the objective, and everyone should justify their suggestions based on it. This helps people to stay focus and keep the debate constructive.
  3. Decision Making
    Sometime you are not sure of what is right, which is better, what to do, …. Ask yourself what is the objective of making this decision. What do you want to achieve? Once this is established, decision become clear.  Choose the option that best help you achieve your objective.

rest thinking will share soon with past resplendent experience......... :) 

Saturday, December 15, 2012

How many Contact database Table in android?

The important tables of Contact Application Database-  

1 - raw_contacts,
2 - contacts 
3 - data.


raw_contacts- stores entries for all contacts. So if you have 100 contacts, there will be 100 records in this table. For the purpose of data normalization and reduce data redundancy,  this table stores basic contacts details and foreign keys of other tables (e.g. contacts tables) which in turn stores particular contact details like count of links, whether contact has email id etc.
Column Name
Purpose
Id
unique ID for each Contact
display_name
Contact name (first and last name are clubbed together)
display_name_reverse
. This column is read when you set display order “reverse” instead of display_name
account_type
Source of the account- SIM, Phone, Google, T-Mobile etc. There can be one entry for the owner profile vnd.sec.contact.my_profile
contact_id
Foreign key for contacts table. This field is important when contacts are linked.

Contacts- this table is directly referred while creating Contact List. If a contact is linked with another, its entry will be deleted from this table and will not be displayed in the Contact List
Column Name
Purpose
Id
unique ID for each Contact
display_name
Contact name (first and last name are clubbed together). Same as raw_contacts table
display_name_reverse
Same as raw_contacts_table
link_type1
Same as account_type of raw_contacts
link_count
How many contacts are linked to this contact
has_email
Probably it helps to quickly check whether a contact has email id rather than reading entry from data table.

Data- this table stores all possible contact details e.g. multiple phone numbers, emails, icons, birthday, company name etc.
Column Name
Purpose
mimetype
Type of data. 5- display name, 6-phone _number, 1- email, 7-contact icon etc.
raw_contact_id
Foreign key for contacts table. This field is important to find out primary entries of a particular contact
data1
Stores contact details row wise. So for 3 details e.g. , and , there will be 3 rows.
data2
. (Fix me: some other numerical code also present.)
data3
. (Fix me: some other numerical code also present.)
data15
Stores contacts icons in binary format (PNG)


Important Contact URI and Sample Usage

content://com.android.contacts/raw_contacts_with_photo

Authority: com.android.contacts (It identifies the ContactsProvider class. So in all URI it will be a constant part.)
Authority Information defined in ContactsProvider Manifest-
<provider android:name="ContactsProvider2"
android:authorities="contacts;com.android.contacts"
../>

Path: raw_contacts_with_photo

Following is a list of important URI to access 3 different tables of Contact Application i.e. contacts, raw_contacts and data- 
Accessing Contacts Table
content://com.android.contacts/contacts
content://com.android.contacts/contacts/#
content://com.android.contacts/contacts/#/data
Accessing Raw_Contacts Table
content://com.android.contacts/raw_contacts
content://com.android.contacts/raw_contacts/#
content://com.android.contacts/raw_contacts/#/data
Accessing Data Table
content://com.android.contacts/data
content://com.android.contacts/data/#
content://com.android.contacts/data/phones
content://com.android.contacts/data/phones/#
 

Monday, December 3, 2012

Diffrence between HttpUrlConnection and HttpClient

The HttpUrlConnection is from the standard Java SE API and HttpClient is a Apache Commons library which is built on top of the standard Java SE one. Apache Commons libraries in turn are usually more convenienced and less opaque (read: less low-level).
In fact, everything can be done with the standard Java SE API. Major goal of those kind of libraries are just faster development and lesser code. In this particular example you can for instance send a POST request with just one or two HttpClient methods instead of writing 10~20 lines of code as you would do with plain HttpUrlConnection. The same story applies on the Apache Commons IO v.s. java.io and Apache Commons Lang v.s. java.lang, Apache Commons Collections and Google Collections v.s. Java Collections, etcetera.


Features Comparison :


Oakland Software Sun JRE < 1.4.2 Sun JRE >= 1.4.2 Sun JRE >= 5 Sun JRE >= 6 Innovation Apache
Features
cookies X


X X X
WebDAV support X





Apache Axis/Axis2 support Axis and Axis2




Axis and Axis2
plug compatible X X X X X X
multi-part POST (file upload)





X
true request output stream X

X X X X
auto authentication with streaming X





true response input stream X X X X X X X
connection keep alive X X X X X X X
connection pool throttling X




X
connection/request timeout X
X [uns] X [uns] X [uns] X X
idle connection timeout X




X
pipelining of requests X



X
auto authentication with pipelining X





non-blocking I/O





X
SSL X X X X X X X
basic authentication X X X X X X X
digest authentication X X X X X X X
NTLM authentication X
[Windows only] [Windows only]* X
[partial]
NTLM V2 authentication X
[Windows only] [Windows only]* X*

proxy authentication X X X X X X X
Support
minimum JRE version 1.2* 1.0 1.4.2 5 6 1.2 1.2
price not free free free free free free free
source available X



X X
diagnostic tracing X



X X
actively supported X X X X X
X
fix turnaround fast slow slow slow slow none medium
license purchase Sun JRE Sun JRE Sun JRE Sun JRE LGPL Apache


Explanations
[unsupported] - This feature exists in this release, but may not be supported in future releases.
idle connection timeout - Most servers timeout connections after a certain interval. When HTTP clients use connection pooling, the fact that the connection was closed is detected when the next request is written to the connection. If it's an idempotent request (like a GET, or PUT) then it can just be retried on a new connection. However, POST cannot be retried (we don't know if it has been processed by the server or not), so the user of the HTTP client will get an error on this POST. The Oakland Software implementation provides a facility to terminate connections which have been idle for a (configurable) length of time, or alternatively to send a "ping" message before using a connection (if it has been idle for a certain amount of time). This ensures that POST requests will not be affected by the server connection timeout processing.
pipelining of requests - This allows multiple requests to be sent on the same connection before getting the response to the first one. This can make a tremendous performance difference when fetching many objects from the same server (as you don't have to pay the round trip latency for each request). This can also make a substantial throughput difference when in high volume applications by reducing the latency and sharing the socket connections for multiple requests at a time. The Oakland Software pipelining implementation is the only implementation that automatically handles all authentication modes before starting pipelining, allows pipelining for POST (useful in certain controlled environments), and automatically adapts to the server closing connections for maximum pipelining performance.
non-blocking I/O - In most HTTP implementations, the outstanding HTTP request ties up a thread until it is completed. This restricts the number of outstanding HTTP requests to the number of possible threads, which is a significant limitation (since each thread consumes a certain amount of memory). With non-blocking I/O the request can be sent and the response can be received on a different thread, thus an unlimited number of outstanding connections can be active with a small number of active threads. This support is useful for applications where large numbers of connections must be processed quickly. This (especially combined with pipelining and the use of direct reading and writing from the socket) give maximum throughput.
connection pool throttling - This is very useful in certain server situations. This is a limit on the number of connections to a given host and port. The HTTP 1.1 specification recommends that no more than 2 connections are established (to a given host/port). In any of the other implementations (that use connection pooling) it will open as many connections as you have requested. This can cause problems for some servers.
connection request timeout - A good timeout mechanism has three parts: timeout when establishing the initial connection, setting the TCP timeout on the connection (so that each request is subject to the timeout), and, if connection pooling is used, timeout while waiting for a connection to be available from the pool. The Oakland Software implementation is the only implementation that supports all of these.
true request/response streams - The older JRE implementations by default record the request data into a byte array and does not actually send the data until the connection is open. This results in double copying of the data, resulting in slower performance in cases where there is a lot of data. Other implementations allow you to read/write directly to the underlying connection stream, avoiding this double copy of the data. It also avoids reading this data if not required by the application, which is not possible if there is not a true response input stream.
After JRE 5, direct streaming to the output was implemented by adding new methods (setChunkedStreamingMode() and setFixedLengthStreamingMode()) however, these methods will not work if the connection requires authentication. The Oakland Software implementation will perform the authentication automatically before beginning the streaming processing so streaming works transparently with authentication.
NTLM - The JRE 1.4.2 supports NTLM only on Windows. The Oakland Software and Apache HTTP clients support NTLM on any platform. However only the Oakland Software NTLM support correctly supports both Unicode and OEM encoding for NTLM and supports NTLM V2. The Sun implementation in JRE 6 and 1.5_08 and higher support NTLM V2 on all platforms, though on Windows they use the current user's credentials by default.
plug compatible - This is true if you can switch to this HTTP Client from the Sun HTTP client without changing any code and it will just work. This means the HTTP Client implements the java.net.HttpURLConnection class, and the necessary protocol handlers for HTTP and HTTPS.
versions - JRE versions prior to 1.2.x and 1.3.x are supported only with version 1.x of the Oakland Software HTTP client. This includes all of the features except pipelining and Axis2 support. Version 2.x and higher of the Oakland Software HTTP client require JRE version 1.4.2 or higher.
slow turnaround - You get fixes to the Sun HTTP Client when a new version of the JDK is released, which is usually a long wait.
fast turnaround - Considering the Oakland Software product is actively supported, and support contracts are available, fixes can be released as fast as next day and usually within a week.
medium turnaround - The Apache HTTP Client is supported as there are volunteers to work on it. Currently they offer pretty quick support, so long as you are willing to take their nightly builds. There have been periods though where no one was working on it, and this could be the case again. You can't be sure, but you can fix it yourself if you want.

Marshling and Demarshling

Difference between Marshling and  Demarshling?

"marshalling" refers to the process of converting the data or the objects inbto a byte-stream, and "unmarshalling" is the reverse process of converting the byte-stream beack to their original data or object. The conversion is achieved through "serialization".
The purpose of the "marshalling/unmarshalling" process is to transfer data between the RMI system.

AIDL interface in Android


Why and What's AIDL ?

Each application in Android runs in its own process. An application cannot directly access the data of another application for security reasons. However, a couple of mechanisms allow communication between applications. One such mechanism that you’ve seen throughout the book is Intents. Intents are asynchronous, meaning that you can post a message for someone to receive at some future point in time and just continue with your application.

Every once in a while we need a more direct, synchronous access to another process. There are many ways to implement this across process boundaries, and collectively they are called Interprocess Communication, or IPC for short.

To allow cross-application communication, Android provides its own version of an IPC protocol. One of the biggest challenges in IPC is passing data around, such as when passing parameters to method calls on the remote systems. IPC protocols tend to get complicated because they have to convert data from its in-memory format to a format that’s convenient for sending to another process. This is called marshaling, and the unpacking at the receiver is called unmarshaling.

To help with this, 
 "Android provides the Android Interface Definition Language, or AIDL. It is a lightweight implementation of IPC using a syntax that is very familiar to Java developers, and a tool that automatically creates the hidden code required to connect a client and a remote service."

To illustrate how to use AIDL to create interprocess communication, we’ll create two applications: a remote service called LogService and a client called LogClient that will bind to that remote service.


Implementing the Remote Service

Our remote service, LogService, will simply allow remote clients to log a message to it.

We are going to start by creating the interface for the remote service. This interface represents the API, or set of capabilities that the service provides. We write this interface in AIDL language and save it in the same directory as our Java code with an .aidl extension.

The AIDL syntax is very similar to a regular Java interface. You simply define the method signature. The datatypes supported by AIDL are somewhat different from regular Java interfaces. But all Java primitive datatypes are supported. So are the String, List, Map, and CharSequence classes.

If you have a custom complex data type, such as a class, you need to make it Parcelable so that the Android run-time can marshal and unmarshal it. In this example, we’ll create a Message as a custom type.

Writing the AIDL

We start by defining the interface for our service. As you can see, the interface very much resembles a typical Java interface. For readers who might have worked with CORBA in the past, AIDL has its roots in CORBA’s IDL.

Example 14.1. ILogService.aidl
package com.marakana.logservice; // 1

import com.marakana.logservice.Message; // 2

interface ILogService { //3
  void log_d(String tag, String message); // 4
  void log(in Message msg); // 5
}

1 Just as in Java, our AIDL code specifies what package it’s part of.
2 However, unlike Java, we have to explicitly import other AIDL definitions even if they are in the same package.
3 We specify the name of our interface. Interface names conventionally start with I for interface.
4 This method is simple because it doesn’t return anything and takes only primitives as inputs. Note that the String class is not a Java primitive, but AIDL considers it to be one.
5 This method takes our custom Message parcel as its input. We’ll define Message next.
Next, we’ll look at the implementation of the Message AIDL.

Example 14.2. Message.aidl
package com.marakana.logservice; // 1

/* 2 */
parcelable Message;

1 Specifies the package it’s in.
2 Declares that Message is a parcelable object. We will define this object later in Java.
At this point, we are done with the AIDL. As you save your files, Eclipse automatically builds the code to which the client will connect, called the stub because it looks like a complete method to the client but actually just passes on the client request to your remote service. The new Java file is located in Gen folder under /gen/com/marakana/logservice/LogService.java. Because this file is derived from your AIDL, you should never modify it. The aidl tool that comes with the Android SDK will regenerate it whenever you make any changes to your AIDL files.

Now that we have the AIDL and the generated Java stub, we are ready to implement the service.

Implementing the Service

Just like any Android service, we implement LogService in a Java class that subclasses the system Service class. But unlike our earlier Service implementations, where we ignored onBind() but implemented onCreate(), onStartCommand(), and onDestroy(), here we’re going to do the opposite. A method in a remote service starts when the client makes its request, which is called binding to the service, and therefore the client request triggers the service’s onBind() method.

To implement our remote service, we’ll return an IBinder object from the onBind() method in our service class. IBinder represents the implementation of the remote service. To implement IBinder, we subclass the ILogService.Stub class from the auto-generated Java code, and provide the implementation for our AIDL-defined methods, in this case various log() methods.

Example 14.3. LogService.java
package com.marakana.logservice;

import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.os.RemoteException;
import android.util.Log;

public class LogService extends Service { // 1

  @Override
  public IBinder onBind(Intent intent) { // 2
    final String version = intent.getExtras().getString("version");

    return new ILogService.Stub() { // 3

      public void log_d(String tag, String message) throws RemoteException { // 4
        Log.d(tag, message + " version: " + version);
      }

      public void log(Message msg) throws RemoteException { // 5
        Log.d(msg.getTag(), msg.getText());
      }
    };
  }

}

1 LogService is an Android class derived from Service. We’ve seen many services, but this time around, it’s a bound service as opposed to UpdaterService, which was unbound.
2 Since this is a bound service, we must implement onBind() and have it return a correct instance of IBinder class. The client passes us an Intent, from which we extract some string data. During the client implementation, we’ll see how it sets this, and thus how we can pass small amounts of data into the remote service as part of the binding process.
3 This instance of IBinder is represented by ILogService.Stub(), a helper method that is generated for us in the Java stub file created by the aidl tool when we saved our AIDL interface. This code is part of /gen/com/marakana/logservice/LogService.java.
4 log_d() is the simple method that takes two strings and logs them. Our implementation simply invokes the system’s Log.d().
5 We also provide a log() method that gets our Message parcel as its input parameter. Out of this object we extract the tag and the message. Again, for this trivial implementation, we just invoke Android’s logging mechanism.
Now that we have implemented the service in Java, we have to provide the Java implementation of the Message parcel as well.

Implementing a Parcel

Since Message is a Java object that we’re passing across processes, we need a way to encode and decode this object—marshal and unmarshal it—so that it can be passed. In Android, the object that is capable of doing that is called a Parcel and implements the Parcelable interface.

To be a parcel, this object must know how to write itself to a stream and how to recreate itself.

Example 14.4. Message.java
package com.marakana.logservice;

import android.os.Parcel;
import android.os.Parcelable;

public class Message implements Parcelable { // 1
  private String tag;
  private String text;

  public Message(Parcel in) { // 2
    tag = in.readString();
    text = in.readString();
  }

  public void writeToParcel(Parcel out, int flags) { // 3
    out.writeString(tag);
    out.writeString(text);
  }

  public int describeContents() { // 4
    return 0;
  }

  public static final Parcelable.Creator<Message> CREATOR = new Parcelable.Creator<Message>() { // 5

    public Message createFromParcel(Parcel source) {
      return new Message(source);
    }

    public Message[] newArray(int size) {
      return new Message[size];
    }

  };

  // Setters and Getters 6
  public String getTag() {
    return tag;
  }

  public void setTag(String tag) {
    this.tag = tag;
  }

  public String getText() {
    return text;
  }

  public void setText(String text) {
    this.text = text;
  }

}

1 As we said before, Message implements the Parcelable interface.
2 To be parcelable, this object must provide a constructor that takes in a Parcel and recreates the object. Here we read the data from the parcel into our local variables. The order in which we read in data is important: it must correspond to the order in which the data was written out as well.
3 writeToParcel() is the counterpart to the constructor. This method is responsible for taking the current state of this object and writing it out into a parcel. Again, the order in which variables are written out must match the order in which they are read in by the constructor that gets this parcel as its input.
4 We’re not using this method because we have no special objects within out parcel.
5 A parcelable object must provide a Creator. This Creator is responsible for creating the object from a parcel. It simply calls our other methods.
6 These are just various setter and getter methods for our private data.
At this point, we have implemented the required Java code. We now need to register our service with the Manifest file.

Registering with the Manifest File

As always, whenever we provide one of the new main building blocks for applications, we must register it with the system. The most common way to do that is to define it in the Manifest file.

Just as we registered UpdaterService before, we provide a <service> element specifying our service. The difference this time around is that this service is going to be invoked remotely, so we should specify what Action this service responds to. To do that, we specify the action and the Intent Filter as part of this service registration.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.marakana.logservice" android:versionCode="1"
  android:versionName="1.0">
  <application android:icon="@drawable/icon" android:label="@string/app_name">

  <!-- 1 -->
    <service android:name=".LogService">
      <!-- 2 -->
      <intent-filter>
        <action android:name="com.marakana.logservice.ILogService" />
      </intent-filter>
    </service>

  </application>
  <uses-sdk android:minSdkVersion="4" />
</manifest>
1 This is where we define our service. It is a <service> element within the application block.
2 The difference between this service and our UpdaterService is that this service is going to be remote to the client, so calling it by an explicit class name wouldn’t work well since the client may not have access to the same set of classes. So instead we provide the Intent filter and action to which this service is registered to respond.
At this point, our service is complete. We can now move on to the client implementation.

Implementing the Remote Client

Now that we have the remote service, we are going to create a client that connects to that service to test that it all works well. Note that in this example we purposely separated the client and the server into two separate projects with different Java packages altogether, in order to demonstrate how they are separate apps.

So we’re going to create a new Android project in Eclipse for this client, just as we’ve done before for various other applications. However, this time around we are also going to make this project depend on the LogService project. This is important because LogClient has to find the AIDL files we created as part of LogService in order to know what that remote interface looks like. To do this in Eclipse:

  1. After you have created your LogClient project, right-click on your project in Package Explorer and choose Properties.
  2. In the "Properties for LogClient" dialog box, choose Java Build Path, then click on the Projects tab.
  3. In this tab, click on "Add…" and point to your LogService project.
This procedure will add LogService as a dependent project for LogClient.

Binding to the Remote Service

Our client is going to be an activity so that we can graphically see it working. In this activity, we’re going to bind to the remote service and from that point on use it as if it was just like any other local class. Behind the scenes, the Android binder will marshal and unmarshal the calls to the service.

The binding process is asynchronous, meaning we request it and it happens at some later point in time. To handle that, we need a callback mechanism to handle remote service connections and disconnections.

Once we have the service connected, we can make calls to it as if it was any other local object. However, if we want to pass any complex data types, such as a custom Java object, we have to create a parcel for it first. In our case, we have Message as a custom type, and we have already made it parcelable.

Example 14.5. LogActivity.java
package com.marakana.logclient;

import android.app.Activity;
import android.content.ComponentName;
import android.content.Context;
import android.content.Intent;
import android.content.ServiceConnection;
import android.os.Bundle;
import android.os.IBinder;
import android.os.Parcel;
import android.os.RemoteException;
import android.util.Log;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;

import com.marakana.logservice.ILogService;
import com.marakana.logservice.Message;

public class LogActivity extends Activity implements OnClickListener {
  private static final String TAG = "LogActivity";
  ILogService logService;
  LogConnection conn;

  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    // Request bind to the service
    conn = new LogConnection(); // 1
    Intent intent = new Intent("com.marakana.logservice.ILogService"); // 2
    intent.putExtra("version", "1.0"); // 3
    bindService(intent, conn, Context.BIND_AUTO_CREATE); // 4

    // Attach listener to button
    ((Button) findViewById(R.id.buttonClick)).setOnClickListener(this);
  }

  class LogConnection implements ServiceConnection { // 5

    public void onServiceConnected(ComponentName name, IBinder service) { // 6
      logService = ILogService.Stub.asInterface(service); // 7
      Log.i(TAG, "connected");
    }

    public void onServiceDisconnected(ComponentName name) { // 8
      logService = null;
      Log.i(TAG, "disconnected");
    }

  }

  public void onClick(View button) {
    try {
      logService.log_d("LogClient", "Hello from onClick()"); // 9
      Message msg = new Message(Parcel.obtain()); // 10
      msg.setTag("LogClient");
      msg.setText("Hello from inClick() version 1.1");
      logService.log(msg); // 11
    } catch (RemoteException e) { // 12
      Log.e(TAG, "onClick failed", e);
    }

  }

  @Override
  protected void onDestroy() {
    super.onDestroy();
    Log.d(TAG, "onDestroyed");

    unbindService(conn); // 13

    logService = null;
  }
}

1 LogConnection is our class that connects to, and handles disconnections from, the remote service. The class is explained later.
2 This is the action Intent that we’re using to connect to the remote service. It must match the action that LogService specified in the Manifest file as part of its Intent filter.
3 Here is where we add the data to the Intent, to be extracted by the remote method.
4 bindService() is the method you use to ask the Android runtime to bind this activity to the remote service specified by the Intent action. In addition to the Intent, we pass on the Service Connection class to handle the actual connection. The BIND_AUTO_CREATE flag indicates that if the service we’re trying to connect to doesn’t already exist, it should be created.
5 LogConnection is the class that will be called back upon successful connection to the remote service, and whenever the service disconnects. This class needs to subclass ServiceConnection and implement onServiceConnected() and onServiceDisconnected().
6 onServiceConnected() is called once the bind succeeded. At this point, the IBinder instance represents our remote service.
7 We now need to cast the bound service into our LogService instance. To do that, we use a helper method named ILogService.Stub.asInterface(), provided by that Java stub that was created automatically by the aidl tool when we saved our AIDL files.
8 onServiceDisconnected() is called once the remote service is no longer available. It is an opportunity to handle any necessary cleaning up. In this case, we just set logService to null to help with the garbage collection.
9 Assuming that we have successfully bound to the remote service, we can now make calls to it as if it was a local call. logService.log_d() simply passes two strings to the log_d() method that we saw defined in LogService.
10 As mentioned earlier, if we want to pass a Message to the remote method, we have to create a parcel out of it first. This is possible because Message is a parcelable object. We then set it its properties using appropriate setters.
11 Once we have the parcel, we simply call logService.log() and pass it to LogService, where it gets logged.
12 Whenever we make a remote call, it could fail for variety of reasons outside of our control. Because of that, it is a good practice to handle a possible RemoteException.
13 When this activity is about to be destroyed, we ask to unbind the service and free those resources.
At this point our client is complete. There’s a simple UI with a single button that triggers an onClick() call. Once the user clicks the button, our client should be invoking the remote call in the service.

Testing That All Works

Try to run the client from within Eclipse. Since Eclipse knows that LogClient is dependent on LogService, it should install both packages onto your device. Once the client starts, it should bind to the service. Try clicking on the button and check that LogService is indeed logging. Your adb logcat call should give you something like this:

...
I/LogActivity(  613): connected
...
D/LogClient(  554): Hello from onClick() version: 1.0
D/LogClient(  554): Hello from inClick() version 1.1
...
The first line is from LogConnection in the client, indicating that we’ve successfully bound to the service. The other two lines are from the remote service, one for LogService.log_d() and the other one for LogService.log(), where we passed in the Message parcel.

If you run adb shell ps to see the running processes on your device, you’ll notice two separate line items for the client and the server:

app_43    554   33    130684 12748 ffffffff afd0eb08 S com.marakana.logservice
app_42    613   33    132576 16552 ffffffff afd0eb08 S com.marakana.logclient
This indicates that indeed the client and server are two separate applications.

Summary

Android provides an interprocess communication mechanism. It is based on binder: a high-performance, shared-memory system. To create create a remote service, we define it using the Android Interface Definition Language (AIDL), similar to Java interfaces. We then implement the remote interface and connect to it via the IBinder object. This allows us to connect our client to a remote service in a different process altogether.

QUESTION: How to send one class from one process to another process?

Suppose you have a class that you would like to send from one process to another through an IPC interface, you can do that. your class must support the Parcelable interface. Supporting the Parcelable interface is important because it allows the Android system to decompose objects into primitives that can be marshalled across processes.

To create a class that supports the Parcelable protocol, you must do the following:
  1. Make your class implement the Parcelable interface.
  2. Implement writeToParcel, which takes the current state of the object and writes it to a Parcel.
  3. Add a static field called CREATOR to your class which is an object implementing the Parcelable.Creator interface.
  4. Finally, create an .aidl file that declares your parcelable class (as shown for the Rect.aidl file, below). If you are using a custom build process, do not add the .aidl file to your build. Similar to a header file in the C language, this .aidl file isn't compiled.
AIDL uses these methods and fields in the code it generates to marshall and unmarshall your objects.

For example, here is a Rect.aidl file to create a Rect class that's parcelable:
package android.graphics;

// Declare Rect so AIDL can find it and knows that it implements
// the parcelable protocol.
parcelable Rect;
And here is an example of how the Rect class implements the Parcelable protocol.
import android.os.Parcel;
import android.os.Parcelable;

public final class Rect implements Parcelable {
    public int left;
    public int top;
    public int right;
    public int bottom;

    public static final Parcelable.Creator<Rect> CREATOR = new
Parcelable.Creator<Rect>() {
        public Rect createFromParcel(Parcel in) {
            return new Rect(in);
        }

        public Rect[] newArray(int size) {
            return new Rect[size];
        }
    };

    public Rect() {
    }

    private Rect(Parcel in) {
        readFromParcel(in);
    }

    public void writeToParcel(Parcel out) {
        out.writeInt(left);
        out.writeInt(top);
        out.writeInt(right);
        out.writeInt(bottom);
    }

    public void readFromParcel(Parcel in) {
        left = in.readInt();
        top = in.readInt();
        right = in.readInt();
        bottom = in.readInt();
    }
}
The marshalling in the Rect class is pretty simple. Take a look at the other methods on Parcel to see the other kinds of values you can write to a Parcel.
Warning: Don't forget the security implications of receiving data from other processes. In this case, the Rect reads four numbers from the Parcel, but it is up to you to ensure that these are within the acceptable range of values for whatever the caller is trying to do. See Security and Permissions for more information about how to keep your application secure from malware