1. Emulators can be used for limited functionality testing only

Emulators are just mimic to actual devices in terms of functionality. They can never be treated as substitutes for actual devices. For a start, device emulators and simulators can act as an stepping stone in testing mobile applications but totally relying on them can lead to catastrophe. One of the prime examples where emulators can be used is testing design level implementations, for instance if the desired icons are on a specific screen or not. The biggest limitation of emulators is that they do not work on real network and are not prone to real world interrupts and for this reason, we need real devices to test applications. For instance emulators can be used in location based apps by simulating a route, but actual interrupts occurring on these routes can only be tested using real devices.

2. Field testing is uber important

Mobile field testing provides testing assurance of the mobile device’s workability in the actual field. This will ensure that the device works not only in the Static field environment but also in the dynamic field environment. Few years back, there was one research conducted in Helsinki where users were given 10 different tasks to perform on application at different locations. Although that application was already tested before in their laboratories but during field testing users found many different functional bugs due to signal discrepancies and other interrupts.

3. Never assume one application works for all

Market is full of devices having different configurations, operating systems, features and assuming if things are working fine on one device  then they will be fine on every device is not a good practice at all. Every device has its own characteristics due to which some features of application may fit well in one device and may not in other device. For example:- Samsung and Nokia might come up with any native application solution. Though the basic functionality is the same for both the apps but the look and feel, form factor of the applications might be largely different from each other.

4. Keep interrupts in mind while mobile app testing

Wireless networks are prone to functional and network interrupts. Lets take an example where user is disbursing using his debit card and in between that transaction there is a signal loss for fraction of seconds. In that case application should be able to intimate user about signal loss or should be able to resume from where signal was lost then his transaction should be completed after this interrupt is over. This was just one example of interrupt. There can be other types of interrupts like receiving message, receiving calls which are uncontrollable. The concept of interrupts is important in every type of applications and they should be tested with extra care specially in case of financial applications like mobile banking.

5. Give special focus on usability

Good user interface can play crucial role in software industry.Any software product can be made with provided set of functionality but an intelligent user interface can make a product hit. Intelligent user  interface means it should be easily used by end-users. There are unique features in usability of a mobile application when compared to normal desktop application. Some of the examples are mentioned below:-

1. Mobile devices are designed for both left handed and right handed people. In that case, QA should focus on convenience perspective so that mobile applications can be used by both set of people.

2. Mobile applications should be tested according to phone orientation as mobile applications can be viewed either in landscape or portrait format.  Here, QA should focus on testing on different screen resolution as well as different orientation format.

3. In addition to usability testing in different orientation,  usability should also be tested for touchscreen screens, qwerty keypads,etc. Example : sufficient usability testing should be performed to ensure that the keyboard is visible only when it is required while inputting text, numbers, etc.

1. Configure/trigger the tests in way so that we can put them into the Jenkins machines as build jobs.

2. Use maven targets to be able to force a browser type at build time (for example: mvn integration-test -DBrowserType=chrome). Using this we can create multiple Jenkins jobs for execution of selenium tests against each browser.

3. Make remote execution capability configurable along with the location (IP and port) of the selenium server (if Remote Execution is true) so that we can easily switch server (if required) or use multiple servers simultaneously executing test against different browsers.

4. Run the tests on multiple browsers like FF,IE and chrome.

With the help of this blog I intend to share the way we set about to achieve our objectives. Here I am assuming that the reader is aware of basic concepts of selenium and maven.

As a first step we created a maven project for the test suite and added the required dependencies to the POM file. We prepared a remote windows virtual machine with all the required browsers and downloaded the selenium-server-standalone-{VERSION}.jar on it.

In our framework, we added a few system properties in our BaseTest.java (A helper class used by all tests to instantiate a WebDriver/RemoteWebDriver instance).

String BrowserType = System.getProperty("BrowserType");
String RemoteExecution = System.getProperty("RemoteExecution");
String RemoteUrl = System.getProperty("RemoteUrl");


Next, we made the invocation of a browser type and remote execution capability dependent on these property values in our BaseTest.java.

if(!RemoteExecution.equals("true")) // remote execution is false
{
if(BrowserType.equals("firefox"))
{
WebDriver driver = new FirefoxDriver(); // Create a new instance of firefox driver
}
else if
{
code for ie and chrome goes here
}
else                               //remote execution is true
if(BrowserType.equals("firefox"))
{
WebDriver driver = new RemoteWebDriver(newURL(RemoteUrl+"/wd/hub"),DesiredCapabilities.firefox());
//Create a new instance of RemoteWebDriver with the remote server url
}
else if
{
code for ie and chrome goes here
}


Finally, we configured the maven-surefire-plugin to run the tests in integration-test phase. In the plugin execution we added the parameter 'systemPropertyVariables' to pass values for the system properties defined above at build time.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
<executions>
<execution>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skip>false</skip>
<systemPropertyVariables>
<BrowserType>firefox</BrowserType>
<RemoteExecution>false</RemoteExecution>
<RemoteUrl>http://127.0.0.1:4444</RemoteUrl>
</systemPropertyVariables>
<suiteXmlFiles>
<suiteXmlFile>${project.build.directory}/test-classes/testng.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
</execution>
</executions>
</plugin>

Now once we had the server running on the remote VM (using java -jar selenium-server-standalone-{VERSION}.jar) we were able to build and execute our tests using the following maven command.

mvn integration-test -DBrowserType=firefox -DRemoteExecution=true -DRemoteUrl=http://xyz.com:4444

Now we already achieved our objective 1,2 and 3 but not 4. We ran into issues while running the tests on chrome remotely. We encountered an exception with the message 'The path to the chrome driver executable must be set by the webdriver.chrome.driver system property'. The solution to this is already discussed on stackoverflow. In nutshell, you need to have the chromedriver.exe on the remote machine (where the selenium server is hosted) and run the selenium server on the remote machine with the following argument

java -Dwebdriver.chrome.driver="path-to-chromedriver.exe" -jar selenium-server-standalone.jar

That's it. This enabled us to run our tests on any remote machine against a specific browser with ease in continuous integration environment. It would be great to hear what alternative approaches you have used to solve something similar.

Google is particularly ambitious about this feature in its latest range of Android devices. Here is a summary of recent efforts by Google to make NFC popular among users and developers:

• NFC API's for developers: In OS version 2.3 (Gingerbread) of Android, Google introduced NFC support and also exposed API's for developers to create applications for NFC enabled Android devices. Using this API's, "Developers can create new applications that offer proximity-based information and services to users, organizations, merchants, and advertisers".
• Google Wallet: Google's ambitious project in the area of mCommerce. This application for smart-phones empowers the devices to act as a virtual wallet which store user's credit card and other payment information safely. Users can use their mobile devices at stores to pay and benefit from offers provided by Google directly. The transaction will happen by tapping the mobile device at NFC readers installed at point of sales.
• Android Beam: In Android 4.0(Ice-cream Sandwich), a new application called "Beam" is introduced. This application makes it more easy and intuitive for users to share contacts, apps, songs and videos between two Android devices using NFC. Beam uses NFC Android API's which are fully exposed to developers.

Let's dig into the important API’s and technical details we can use to make our application NFC enabled. Two terms frequently used for NFC are:

• NFC Tag: The important characteristic of NFC is that an NFC powered mobile device can read and write passive targets. These passive targets are usually NFC tags which may be very small and simple and can be in the form of small stickers, movie poster or visting cards.
• NFC device: NFC device is the powered device which can read or write another NFC device or tag. In our case, it is NFC enabled Android phone.

Detecting an NFC tag:

NFC device detects a NFC tag or other device when they come in close proximity(distance < 4cm). On detecting the target, the device opens up the desired Activity to handle the required job. For instance, when a video is to be shared, Youtube application opens up and when user wants to share an app, Android market gets opened. If the device detects a tag with a link, it redirects to that link on browser.

This astute process of detecting a target, extracting information from that target and then pinpointing the Activity to accomplish the intended task without user intervention is called "Tag dispatching". Tags contain small amount of data in a special format called NDEF (NFC Data Exchange Format) standardized by NFC forum. This data and its MIME type is exchanged from the target to the device. On device, this data is further attached to an Intent which is sent to the interested applications. The applications which intend to handle this type of data will have to register appropriate Intent-filter.

We deal with following classes:

1. NdefMessage: Container class for storing the NDEF data. It contains a group of records which  contain the actual payload data, the type of data and other information about it.
2. NdefRecord: Represents the records in NdefMessage. These records contain different fields to identify the required information about the data like format, type, ID and the actual payload. One of the field is Type Name Format (TNF) which is used to detect the MIME type or URI of the NdefMessage. When the data is transferred from target to receiver,the first NdefRecord is looked up for getting information about the whole NdefMessage. After that an Intent is created with action ACTION_NDEF_DISCOVERED and the MIME type and URI is attached to it.

The appropriate application is chosen to do the job on the bases of intent and the data attached to it. The applications willing to handle the NFC tag detection declare intent filter in their manifest file:

<intent-filter>

<action android:name="android.nfc.action.NDEF_DISCOVERED"/>

<category android:name="android.intent.category.DEFAULT"/>

<data android:scheme="http"

android:host="xebia.in"

android:pathPrefix="/company.html" />

</intent-filter>

This Intent filter will filter intent generated on detecting a tag having a URI as data and will result in opening www.xebia.in/company.html in browser.

Extracting required data from the NFC intent:

When the selected activity opens up after tag dispatch, required data is extracted from the incoming intent to proceed further. This data is contained in "extras" of the intent:

1.  EXTRA_TAG: The extra for containing payload data and tag technology information bound into a  Tag object.

Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);

2. EXTRA_NDEF_MESSAGES: The extra for containing all the NDEF messages in Tag object. These messages are obtained in an Array of Parcelable objects.

public void onResume() {
	super.onResume();
	Intent parentIntent = getIntent();
	if (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(parentIntent.getAction())){
		Parcelable[] rawMsgs = intent.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES);
		if (rawMsgs != null) {
			msgs = new NdefMessage[rawMsgs.length];
			for (int i = 0; i < rawMsgs.length; i++){
				msgs[i] = (NdefMessage) rawMsgs[i];
			}
		}
	}
}

Using Beam to push data:

Beam can be used to push data from an application while it is running in foreground. Beam gets activated when the "beaming" device is put in physical contact with another device for a moment. At this instance, user is prompted for confirmation in special Beam UI and style. Any third party application can integrate Beam by using setNdefPushMessage() on NfcAdapter. This method will handle the beaming of data when devices come in required distance.

CreateNdefMessageCallback interface is implemented to add Ndef push functionality in the Activity. This implementation requires following method to be defined:

public NdefMessage createNdefMessage(NfcEvent event) {
String message = "This is NFC message";
NdefRecord mimeRecord = createMimeRecord("application/param.android.sample.beam",
message.getBytes());
NdefRecord appRecord = NdefRecord.createApplicationRecord("param.android.sample.beam");
NdefRecord[] ndefRecords = new NdefRecord[] {
mimeRecord,
appRecord
};
NdefMessage ndefMessage = new NdefMessage(ndefRecords);
return ndefMessage;
}

public NdefRecord createMimeRecord(String mimeType, byte[] payload) {
byte[] mimeBytes = mimeType.getBytes(Charset.forName("US-ASCII"));
NdefRecord mimeRecord = new NdefRecord(
NdefRecord.TNF_MIME_MEDIA, mimeBytes, new byte[0], payload);
return mimeRecord;
}

Here two NdefRecords are being transferred. One record represents a text message and other is Android Application Record. This may be included to get guarantee that only this application will be opened up on detecting NFC device with this intent.

In onCreate method a reference to to an NFC adapter is created and a callback is set to it:

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

// Check for available NFC Adapter
nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null) {
Toast.makeText(this, "NFC is not available", Toast.LENGTH_LONG).show();
finish();
return;
}
// Register callback
nfcAdapter.setNdefPushMessageCallback(this, this);
}

The developers can use basic NFC API's to support any kind of tags and NFC data or they can simply leverage the benefits of in built Beam application to use NFC power. Interesting thing is that these API's are really simple to use and working with NFC is nothing less than fun.

• In a design, individual elements do not matter, big picture does: It can be difficult to separate an eye for design with the ability to design. A captivating design is simple and attractive and not. Because of prejudice and bias, designers are not able to distinguish what should be included in the existing design and what should not be. They should not be tempted to use anything that does not integrate well with the existing design. It is absolutely not worth over committing the details and wasting time on it

• Demanding Perfection in first attempt: Too many people want everything perfect before they go live. While the coder makes all the efforts to get everything perfect, the Internet changes, someone presents  the same idea. “Getting there first” is often more important than “Getting there perfect” Apply the 80-20 rule to projects instead. It is better to wait to spend 80% of your resources polishing that last 20% once you've proven the stability of your site.

• Not enough Unit Testing : It is the confidence biased towards the self written code that refrains the developer. It becomes hard to think of the scenarios and inputs that can break their code. Thus, the developer is not able to enhance his code to make it more rich and robust. Also, they get complacent when their code has to be reviewed by someone else and then is functionally checked by the QA. A developer has to get into a different mindset keeping in consideration that all checks cannot be and ideally should not be incorporated into the code.  The method(s) has to be as generic as possible to allow extensibility  and it should be tested with respect to all the specifications. Ideally, even for a minor bug fix, a unit test case should be written.

• Exceptions

  Surpassing and suppressing exceptional conditions

  Sometimes, the programmer is not specific enough in the type of exception they catch. Catching too general an exception type means that they may be inadvertently dealing with particular exceptions that would be best left to other code, higher up the call chain. Tune your exception catch blocks to be as specific as possible. The second mistake is more detrimental-the programmer doesn't want any exceptions leaving their code and so catches them all and ignores them. This is known as the empty catch block. Also,don't absorb exceptions with no logging and operation. Ignoring exceptions will save that moment but will create a chaos for maintainability later

  Inter wining Exception Handling and Business Logic

  Don't manage business logic with exceptions. Use conditional statements instead. If a control can be done with if-else statement clearly, don't use exceptions because it reduces readability and performance  (e.g. null control, divide by zero control).eg. Null control with conditionals is not an alternative to catching NullPointerException. If a method may return null, control it with if-else statement. If a return may throw NullPointerException, it should be caught.

• Closing the source: One of the trickiest challenges for any company is determining how much to share with the people who use the software. Often the code itself grows more modular and better structured as others recompile the program and move it to other platforms. Just opening up the code forces you to make the info more accessible, understandable, and thus better. As they make the small tweaks to share the code, they feed the results back into the code base. Due to the trade off, developers are mostly indecisive of it.

• Playing it fast and loose: Even though the developers are well aware of the possible security breaches, still not much is done to prevent them. Some of them are:

1. SQL injection or OS injection

2. Cross-site scripting : By not validating the input that is given dynamically, the developer might invite these problems like compromising on data integrity, cookies can be set and read, user input can be intercepted. Malicious scripts can be executed by the client in the context of the trusted source.

3. Improper release of resources: When the system resources such as memory, files, cookies, data structures, sessions, communication pipes, and so on have reached their end-of-life, they are disposed off. Attackers can exploit improper shutdown to maintain control over those resources well after you thought you got rid of them. They may sift through the disposed off  items, looking for sensitive data. They can potentially be useful to them.

4. Use of insufficiently random values:The developer  may depend on randomness without even knowing it, such as when generating session IDs or temporary file names. Pseudo-Random Number Generators (PRNG) are commonly used, but a variety of things can go wrong. Once an attacker can determine which algorithm is being used,  they can guess the next random number often enough to launch a successful attack after a relatively small number of tries.

5. Client side security: The developer should not trust the client to perform security checks on behalf of your server. Attackers can reverse engineer your client and write their own custom clients. The consequences will vary depending on what the security checks are protecting, but some of the more common targets are authentication, authorization, and input validation.

Developers make such errors for two main reasons. First, they may be operating under the mistaken assumption that a given function is too obscure to be vulnerable, they fail to grasp the extent to which attackers may be willing to analyze their application flows to find weaknesses. More often, however, they simply haven't considered how important a given function might be to the overall security of their application. As applications grow more complicated and their functions are distributed across multiple systems and resources, it's particularly easy to lose track of the big security picture.

• Delegating too much to frameworks : Sometimes the magic tools lead only to confusion. By abstracting functionality and assuming what we want, frameworks can all too often leave developers at a loss for what's gone wrong in their code. This is where the developer gets bounded within the limitations of framework. Framework should be chosen only if it has a utility, and is inevitable in the project, keeping in mind that it should not tie you down and restrict you to extend or customize your code.

• Reinventing the wheel : Writing your own libraries just because you think you know a better way to code can come back to haunt you. So being obsessed with writing your own logic without the help of an inbuilt function is like wasting time and efforts. Accepting and using libraries that are ready made, freely available and easy to use which solve your purpose is a stitch in time saves nine.

This is not an exhaustive list of the mistakes. But the ones which are the major ones. The other side of mistakes is that they are developer friendly. They act as a driver to push them get better and better and also lead to useful findings and discoveries. There would be no errors or exceptions if nobody ever had an encounter with them The important thing is to accept them with an open mindset, deal and resolve if it is not possible to eliminate it.

Creating a sample Spring MongoDB Application

I will use Spring Roo to create a simple bookshop application. Fire up the Roo shell and execute the following commands.

project --topLevelPackage com.xebia.bookshop --projectName bookshop
mongo setup --databaseName bookshop --host localhost --port 27017
entity mongo --class ~.domain.Book --testAutomatically --identifierType org.bson.types.ObjectId
field string --fieldName title --notNull
field string --fieldName author --notNull
field number --type double --fieldName price --notNull
repository mongo --interface ~.repository.BookRepository --entity ~.domain.Book
service --interface ~.service.BookService
web mvc setup
web mvc all --package ~.web

This will create a simple bookshop application. You can deploy this application on local tomcat using mvn tomcat:run. Please make sure you have MongoDB running on your local system.

Deploying on OpenShift Express

OpenShift Express supports two forms of deployment one is source code deployment which I showed in my last two blogs and other is war/binary deployment. In this blog I will show you how to deploy war to the Express cloud. Before we can deploy the application to OpenShift Express we first need to create bookshop application. To create the application execute the following command. You need rhc ruby gem to execute the command.

rhc-create-app -l <rhlogin> -a bookshop -t jbossas-7.0

It will prompt for the password. Now that you have created the application you should embed MongoDB cartridge in your application.

rhc-ctl-app -l <rhlogin> -a bookshop -e add-mongodb-2.0

Now that we have created the application and added the MongoDB cartridge we need to make change in our Spring application. We need to change applicationContext-mongo.xml file to have correct values for MongoDB factory. The values which exist are for application running on your local system. To change these values to OpenShift ones add a profile as shown below.

<beans profile="openshift">
 <mongo:db-factory dbname="${mongo.name}" host="${OPENSHIFT_NOSQL_DB_HOST}"
 port="${OPENSHIFT_NOSQL_DB_PORT}" username="${OPENSHIFT_NOSQL_DB_USERNAME}"
 password="${OPENSHIFT_NOSQL_DB_PASSWORD}" />
 </beans>

You also need to mention one context-param in web.xml to tell which profile is active. To do it add the following context-param.

   <context-param>
		<param-name>spring.profiles.active</param-name>
		<param-value>openshift</param-value>
	</context-param>

Now build the project using mvn clean install -Dtest=maven.test.skip=true and copy to war file to deployments folder in OpenShift bookshop application. Also change the name of war to ROOT.war otherwise you application will be available at url_of_application/bookshop.
Now to deploy do the following in deployments folder.

git add .
git commit -a -m "adding bookshop application"
git push

Wait for application to get deployed and see your application running at http://bookshop-random.rhcloud.com/

Deploying to Cloud Foundry

To deploy the bookshop application to Cloud Foundry we just need to add one more profile as shown below.

<beans profile="cloud">
	<cloud:mongo-db-factory id="mongoDbFactory"/>
</beans>

In web.xml change the value of spring.profiles.active to cloud and create a war. To deploy to Cloud Foundry follow the following steps

1. Download the Cloud Foundry VMC Ruby gem
2. Build the project using Maven. Do mvn clean install -Dmaven.test.skip=true
3. Once you have installed the vmc gem go to target folder and do vmc push. This command will prompt you for creating a MongoDB service say yes to that and you application will be deployed to Cloud Foundry cloud.
4. You can check the running application at http://bookshop.cloudfoundry.com/

That's it for this blog. I think you will agree that Spring Profiles feature is very useful and powerful.

Create a maven based web project (or use your existing web project) and modify pom.xml as below

<plugin>
	<groupId>org.apache.cxf</groupId>
	<artifactId>cxf-codegen-plugin</artifactId>
	<version>2.5.2</version>
	<executions>
		<execution>
			<configuration>
				<sourceRoot>${project.build.directory}</sourceRoot>
				<wsdlOptions>
					<wsdlOption>
						<wsdl>http://cxf_ws.cloudfoundry.com/sampleService?wsdl</wsdl>
					</wsdlOption>
				</wsdlOptions>
			</configuration>
			<goals>
				<goal>wsdl2js</goal>
			</goals>
		</execution>
	</executions>
</plugin>

In the pom mentioned above, sourceRoot tag in the configuration has been used to indicate directory to generate artifacts and wsdlOption has been used to mention the wsdl file location.

Execute below maven command to generate JavaScript artifacts.

mvn generate-sources

Once you run above command, a new java script file gets generated at the mentioned destination directory, with the same name as wsdl definition name.

Digging deeper into generated artifact.

In brief about generated JavaScript artifact, There will be an operation function for every exposed web service operation and there will be a serialization and a deserialization functions for every operation function. The serialize function is used to convert the JavaScript object to an XML request format and the deserialize function converts the XML response to the corresponding JavaScript object.
There will be a separate function which is used to map all these operation functions with their equivalent serialization/deserialization functions. This function is know as service function and gets generated by reading the service definition from the mentioned wsdl file in pom. The generated service function code starts with a comment given below.

// Definitions for service: {http://test.com/}SampleCXFServiceService
// Javascript for {http://test.com/}SampleCXFService

Integrating generated artifact with JavaScript client code.

Modify your client side JavaScript to incorporate generated artifact changes. For example if wsdl definition name is SampleCXFService then a SampleCXFService.js file will get generated as an artifact. You need to include this SampleCXFService.js artifact in your client js. Other than that you also need to download CXF JavaScript utility file (cxf-utils.js) and include it in client JavaScript. This is a part of CXF distribution and can be found from apache-cxf-2.5.2-src\rt\javascript\javascript-rt\src\main\resources\org\apache\cxf\javascript location.

Add a JavaScript function (i.e. invokeService() ) to invoke the web service and store the result in a variable or use it directly(like in the snippet given below).

Code snippet for client JavaScript:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script type="text/javascript" src="cxf-utils.js"></script>
<script type="text/javascript" src="SampleCXFService.js"></script>

<script language="JavaScript" type="text/javascript">
	var SampleService = new test_com__SampleCXFService();
	SampleService.url = "http://cxf_ws.cloudfoundry.com/sampleService";

	function invokeService()
	{
	  var name = $('#inputTextId').val();
	  <!-- Operation function invocation by passing name as input parameter -->
	  SampleService.getMessage(successResponse, errorResponse, name);
	}

	<!-- Function gets called for a successResponse. -->
	function sucessResponse(response)
	{
		<!-- Using response text to populate result on UI on success-->
		$('#result').text(response.getReturn());
	}

	<!-- Function gets called for an error. -->
	function errorResponse(error)
	{
  	    alert("Error message is " + error);
	}
</script>

The first 2 lines are used to get the reference of web service using service function. The invokeService() function simply delegating call to operation functions. There are two callback functions also in client js.

• successResponse(response) : This function retrieves the response object in callback process and gets called after a successful response.
• errorResponse(error): In case of web service invocation failure, this function retrieves the error message in the callback process and display that message in an alert.

References:

http://cxf.apache.org/docs/overview.html
http://cxf.apache.org/docs/wsdl-to-javascript.html

ContactsContract:

We (developers) usually use this API to get user's contacts list. The important thing about this API is that one Contact row has different information(phone number, email id, name, photo etc.) for the same person aggregated from different sources like local contacts book, Facebook account, Skype, Gmail account etc. The whole contacts database is extensible and is managed in a three tier data model using following three classes under ContactsContract package:

• RawContacts
• Data
• Contacts

ContactsContract

We can do basic operations like insert, update, delete as well as query the contacts database. For example, to insert a contact :

ContentValues values = new ContentValues();
values.put(RawContacts.ACCOUNT_TYPE, accountType);
values.put(RawContacts.ACCOUNT_NAME, accountName);
Uri rawContactUri = getContentResolver().insert(RawContacts.CONTENT_URI, values);
long rawContactId = ContentUris.parseId(rawContactUri);

What Android4.0 (ICS) added to it:

• Easy access with high resolution photos: In this version, the people to which users are most connected will be arranged into a magazine like UI. According to Android developer team “This is to support emotional connections between humans and the devices they carry”.
  For this purpose higher resolution pictures will be used ( 256x256 instead of 98x98).

• Social Stream for Sync Adapters: Through this “biggest new edition”, social applications can display recent online activities of all the contacts in the device user’s contact list. The activities would be visible in the contact list itself. This is achieved by Sync Adapters. Sync adapters can synchronize the raw contacts data  available locally on the device with the contact data available in the cloud resources like Facebook, Skype and other social  apps. In current update, the Sync Adapters now can also fetch update status, photos and other user posts via social stream. Following two classes are important:

1. StreamItems: Stream items contain the recent social updates of a particular user under its Raw Contact data. Also contain the comments, photos and other useful information related to that social update.
2. StreamItemPhotos: Contains the photos related to a single social update by the user.

• The “ME” Contact: This will contain device user’s personal contact  information and profile data. Applications can access the “ME” profile information for display and verification purpose.

• Adding a new connection is easy: This is another important update in ICS. Now user can connect to a person on any social website (Facebook, Google plus) by clicking an option in the contact detail page of that person in the device's people app.

NFC Reloaded with Beam:

NFC or Near Field Communication is one of the latest buzzwords in mobile sphere. Besides its acclaimed uses in e-commerce, mobile payments and enterprises it is becoming a new media of sharing. This "tap" technology can be used for exchanging any type of data between two mobile devices.

Good thing is, NFC APIs are exposed to the developers and are available under android.nfc package.

In 4.0, a new application "Beam" is introduced to make tap-and-share feature  more intuitive. Using Beam, users can share apps, contacts, music, videos and other media contents and files instantly by single tap or touch of two NFC enabled devices.

Beam uses "NDEF push" to transfer data between devices when two devices come in close proximity. NDEF is a special format for NFC data and stands for "NFC Data Exchange Format". Two important classes used for NFC communication are:

• NDEFMessage: Container for NDEFRecords.
• NDEFRecord: Contains the payload data, id and the type of data. if payload data is large, it is divided into   more than one NDEFRecords.

Intents To Share:

Intents are the mainstay of Android system. Apart from regular usage of intents to start another activities, passing data across activities and applications, receiving broadcasts and triggering a service, intents can perform an interesting job for us: to give apps the power to "share" and that without a much extra effort. The simplest case is to create "Activity chooser " dialog to chose a social app capable of sharing:

Intent intent=new Intent(android.content.Intent.ACTION_SEND);
intent.setType("text/plain");
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET);
// Add data to the intent, the receiving app will decide what to do with it.
intent.putExtra(Intent.EXTRA_SUBJECT, “Here goes the subject...”);
intent.putExtra(Intent.EXTRA_TEXT, “Here goes the message body...”);
<pre>

Updates in 4.0: In this version, a new tool is introduced : ShareActionProvider . This will create a "share" button in the Action Bar. It is a sub-class of ActionProvider. ActionProviders are responsible for creating views to do the required action that will accomplish a given task. ShareActionProvider will create view for "share" task.

For using ShareActionProvider, modify the onCreateOptionsMenu() method in the Activity:

public boolean onCreateOptionsMenu(Menu menu) {

MenuItem menuItem1 = menu.findItem(R.id.menu_item);

mShareActionProvider = (ShareActionProvider) menuItem1.getActionProvider();

mShareActionProvider.setShareHistoryFileName("custom_share_history.xml");

}

This will create a list of share targets the user can chose from to perform the sharing. The order of the share targets will depend on the past usage of the user which is saved in a history file. We can either use the default history file or we can maintain a custom history file and use that file throughout the application.

The ICS release has brought exciting goodies for developers and updates in social API's are most appealing.

These opportunities and threats occur in more unpredictable manner then any economic theory or sixth sense can map or forecast them. So to handle them we need event based handlers that are externally determined.

Have a look at the below picture:

To give more sense to above picture:

Event : It can be any damn thing which happens in this world or even universe like in this picture a striking light/ football match/finding water on moon etc. etc.

Event listener & generator :This element will listen an event (as a listener) and thereafter creates and send a signal to the Event Engine (as a generator).

Event Engine : Upon receiving a signal this element will process the details and then send it to clients.

Client : They all will catch the event and interrupt in the manner they want.

Gear up your imagination with the example below:

Imagine your air flight is running late (Event for us, although not the pleasant one). Now what could be the action plan in perfect world:

Your booked cab can be notified for the same so that they can adjust their bookings by assigning a new cab to you and may be book your cab for someone else.

In the same manner hotel reservation can also be handled when notified about your air flight delay.

Even your travel agent can look for other alternative routes or any other flights which can be taken if you have tight schedule. He can even notify the people at seminar you suppose to attend for your delayed plan.

The most important thing to catch here is  "when an air flight gets delayed, the airline doesn't know any of these above cases."

Airline will just announce the delay or cancellation of a flight (which is a Event). The event will be announced to everything which says it's interested in that flight, which may be no one, a passenger or may be several agents for each passenger on the flight. The event listener & generator (cab, hotel and travel agent) decides how to react to the notification. Thus processing the notification by re assigning in case of cab or re booking in case of hotel (Event Engine). After that they will send the confirmation notification to clients.

Magento (CMS in PHP) uses EDA as its core of existence. Let's look how can we define an event and its affect in Magento.

Within Magento you can dispatch an event as simple as by calling a method like :

BaseController::dispatchEvent('custom_event', array('data1'=>$data));

This method accepts two parameters - event unique identifier and associative array of data passed to listener.

In Listener custom class, all the data dispatched by event will be captured and a listener would be added :

class Listener
{
    /**
    * function to take out the 'object' key from $data passed to Listener
    */
    public static function addListener($data)
    {
        $object = $data->getEvent()->getObject();
        $object->doSomething();
    }
}

In some cases, we need to process the request as per the event received.

public static function processEvent($object)
{
    foreach($object->getEvent() as $event)
    {
        doSomeprocess($event);
    }
}

The above Airline example is a simple case of Event Driven Architecture (EDA), it has more complex parts named as Complex event processing (CEP)

Complex event processing (CEP) in above cases could be like delay in flight can affect the airport management, crew allocation, opening of gates, passengers intimation, subsequent delay in on going journey of that flight.

If you notice that event (Air flight delay) which is fired resulted in some services. Thus a service is triggered by incoming events. Hence, making its way to Service oriented architecture (SOA).

So in today's IT world where we talk more about events and services, we can easily state that  SOA 2.0 evolves with the implications of both SOA and EDA architectures.

Hopefully, in next blog we will discuss more about SOA and EDA as winning combination.

We are using Liferay 5.2.3 for developing a web based collaboration portal with a very huge user base. Portal requires development of many custom portlets, which means handling CRUDs around old and new entities. We then started searching for some tools which could increase our pace of development of portlets and we came across Liferay Service Builder. This tool has great power but its effective usage requires good level of understanding. So here is the series of upcoming blogs which will introduce the liferay service builder concepts. We will start with "Service Builder Basics" and then dive deeper into advanced topics. Here is a snapshot of different spaces.

1. Service Builder Basics
2. Service Builder Finders
3. Advantages , Disadvantages , Tips and Tricks
4. Remote Services
5. Caching
6. Transactions
7. Testing

What is service builder ?
Liferay provides a code generation utility called Service Builder, created with an intention to get rid of most boilerplate work during portlet development. Liferay internally uses Spring and Hibernate, which basically means if you are not using service builder, you will end up writing the service layers, pojo’s , dao’s , sql scripts and configuration files if not using annotations. Service Builder does all this with little instructions. To get a good hang of service builder lets walk through an example and run though the various stages starting with concept of an entity and ending with the deployment of that entity inside a portlet with suitable views.

Email Example
Lets say we need an entity of “Email” which has attributes such as from , to , cc, body, date and text.

Configuration
Create a service.xml file in your portlet as location - "portlet/docroot/WEB-INF/service.xml".  service.xml should stick to this schema definitions. Add entry for Email entity in service.xml.

<entity name="Email" local-service="true" remote-service="false" table="Email">
   	 <column name="id" type="long" primary="true">
   	 <column name="to" type="String">
   	 <column name="from" type="String">
   	 <column name="subject" type="String">
   	 <column name="content" type="String">
   	 <column name="date" type="Date">

   	 <!--  Finders -->
   	 <finder name="To" return-type="Collection">
   		 <finder-column name="to"></finder-column>
          </finder>
   	 <finder name="From" return-type="Collection">
   		 <finder-column name="from"></finder-column>
         </finder>
   	 <finder name="Subject" return-type="Collection">
   		 <finder-column name="subject"></finder-column>
         </finder>
   	<finder name="Date" return-type="Collection">
   		 <finder-column name="date"></finder-column>
         </finder>
</entity>

• entity refers to a new model which we want to create
• name attribute refers to the name of the entity
• column tag represents the different fields in entity or columns in table
• type refers to the data-type . Please note you cannot establish one-to-many or many-to-many relationships using this.
• finder tag is used to create find utility methods

Code Generation
Run "ant build-service" from the command (will work only if liferay bin is included in your path). Below is the explanation of all the classes that will be generated. Liferay strictly follows program to interface design so every impl will have its corresponding interface.

Generated classes.
Service Builder generates three types of classes i.e. Model, Service and Persistence

Model Objects

These objects are nothing but the data/value objects.

Following is the list of model classes generated when you run service builder

• BaseModel - This is the Base class provided by liferay which is extended by every model/entity object. This is analogous to object class in Java.
• BaseModelImpl - Basic implementation provided by liferay for BaseModel.
• EmailModel - Interface for the getters/setters of all the fields that are specified in the service.xml for this entity.
• Email - This is interface for Email entity.
• EmailModelImpl - Implementation for the EmailModel methods and couple of other utility methods like clone , toString etc.
• EmailImpl - By Default this class is empty. The purpose of this class is to provide a placeholder to have custom methods on the entity (which are not generated by default) . For instance, if you want to make this entity rich by having  methods like validate “to” field , you can add method something like this

   …
  <pre>public boolean validateToAddress(){
  //Add code to validate this.to
  }
  …
  

  Now once you add this method in the Impl , you need to have this inside a corresponding interface also which is Email. To add this method signature just run the "build-service" target again and method will be added to EmailInterface. Please note that the method cannot be added inside the EmailModelImpl because in case if we change the entity in future or just run the ant build-service, those custom written methods will get deleted.

Service Objects

Once you have you model objects, you need services to operate on them, and service builders generates these as well

Following are the classes generated by service builder for service layer

• EmailLocalService : Interface containing all the crud operations that can be performed on the Email entity. for e.g add/delete/get/update/find
• EmailLocalServiceBaseImpl : Implementation for the EmailLocalService .This class is injected will the serviceImpl’s and persistenceImpl’s of all entities present in the service.xml. One service may need to call other service to do business operations. Injection of these service and persistence impls fully equipts base impl to do such type of operations.
• EmailLocalServiceImpl : This class has the same role as EmailImpl in the model layer. If you want to add custom methods in the service layer for this model, then you can add the implementation in this class and run the ant build-service, and the new method signature will be pushed into EmailLocalService as well.
• EmailLocalServiceUtil : Since we are using spring, ideally we should be able to inject the EmailLocalServiceImpl instance into a java class of view layer (e.g ActionClasses in struts or PageClass in Wicked), but in liferay if you are using JSP Portlet , it will not be possible to inject this dependency . So this util contains the same method signatures as the EmailLocalService but with static qualifier, so that you can use them directly. Internally it will look up that impl from the spring context and then execute the methods on it.
• EmailLocalServiceClp : Clp or ClassLoaderProxy objects are used to serialize the objects. In this case it will be used to serialize EmailLocalServiceImpl. These clps are used for remote services which will be discussed in detail later.

Persistence objects

Persistence classes contain all the code for dealing with hibernate sessions and fetching the actual model objects

• BasePersistence - BasePersistence class is provided by liferay which every persistence impl extends. Some of the methods are registerListener , unregisterListener which are used to associate listeners with events occurring on the Entity Table. for e.g addition of new entity.
• SessionFactory - As the name suggests, this classes is used for the database sessions.We rarely have to deal directly with this class. This class is extended by the BasePersitenceImpl.
• BasePersistenceImpl - Default implementation for the BasePersistence and SessionFactory.
• EmailPersistence - Interface for the basic CRUD operation that can be done on the Email Model.
• EmailPersistenceImpl - Implementation for the EmailPersistence. Again this class is also injected with the persistence impl of all the entities specified in the service.xml. This persistence impl is not same as the ModelImpl or LocalServiceImpl, because you cannot write your custom methods in this class. If you have to create a custom persistence method then you need to create a finder. This will be discussed in our next blog.

Generated sql’s

tables.sql - This sql contains the basic template for table creation. This has to be tweaked as per the database used.

create table Email (
    id_ LONG not null primary key,
    to_ VARCHAR(75) null,
    from_ VARCHAR(75) null,
    subject VARCHAR(75) null,
    content VARCHAR(75) null,
    date_ DATE null
);

indexes.sql : This sql lists the indexes on those fields which are specified as finders in the service.xml.

create index IX_936DE65F on Email (date_);
create index IX_19F9ECE3 on Email (from_);
create index IX_8DEFA35A on Email (subject);
create index IX_92C5C772 on Email (to_);

Code Utilization

Lets take the use case of displaying all the emails that were created yesterday. So, to fetch emails by date, our portlet will call service class, which will call persistence class, and this will return the list of emails created yesterday. Lets start in t the reverse order and see how to write custom methods in each layer.

Persistence layer

This finder entry shown below, which we added while creating our Email entity,  is responsible for creation of a finder method in EmailPersestenceImpl.java and  and also in EmailPersistence.java.

	<finder name="Date" return-type="Collection">
   		 <finder-column name="date">
   	 </finder-column></finder>

The method which gets added has the following signature:

	public java.util.List<com.xebia.general.model.email> findByDate(
   	 java.util.Date date) throws com.liferay.portal.SystemException;

Service Layer

Our service layer should have a custom method which will take a date and then call the persistence layer to get all the emails corresponding to that date.  Our custom method will go into EmailLocalServiceImpl.java and will look like

public  List<email> getAllEmailsByDate(Date createdDate) throws SystemException{
   		 List<email> emailsByDate = emailPersistence.findByDate(createdDate);
   		 return emailsByDate;
    }

After adding this method run service builder. Service Builder then pushes this method in the corresponding service and util classes. The new method that is added in EmailLocalService.java will look like

	@Transactional(propagation = Propagation.SUPPORTS, readOnly = true)
    public java.util.List<com.xebia.general.model.email> getAllEmailsByDate(
   	 java.util.Date createdDate) throws com.liferay.portal.SystemException;

and in EmaiLocalServiceUtil.java

	public static java.util.List<com.xebia.general.model.email> getAllEmailsByDate(
   	 java.util.Date createdDate) throws com.liferay.portal.SystemException {
   	 return getService().getAllEmailsByDate(createdDate);
    }

Portlet code

We now have the method for fetching emails by date in both persistence and service layer. Lets call the LocalServiceUtil class to get yesterday's emails

List<email> emailsByDate = EmailLocalServiceUtil.getAllEmailsByDate(yesterday);

We would now like to conclude the "Service Builder Basics". After reading this post you should know: the classes generated by liferay, using of the generated classes, and placeholders for adding your custom code. In the next post we will add some entities in Email, and will then see how to use one-to-many, many-to-many, or write custom sqls by using finders.