Android Hardware Debugging from Ubuntu in VMWare

Some time back, I had posted an article on Android hardware debugging from Windows. The process is much simpler in Mac OS X or Ubuntu Linux. There, you don’t need to install any special device drivers. Today, I managed to connect my HTC Thunderbolt to Ubuntu 12.04 running as a VMWare guest. The process was simple and worked the first time. Here are the basic steps. I use VMWare Player. I assume the steps will be almost the same for VMWare Workstation.

These steps assume that you have a basic Ubuntu workstation working as a VMWare guest. Log into Ubuntu as the administrator user and then carry out these steps.

Step 1 – Install JDK and Android SDK

You will need Oracle JDK installed. Just download the distribution and unzip it somewhere. Then add <JDK>/bin folder to your PATH. If you are not sure, follow this guide.

Go to http://developer.android.com/sdk/ and download the SDK for Linux. Extract it somewhere, say within your Documents folder. In my case, this created the ~/Documents/android-sdk-linux folder. I will refer to this folder as <SDK> from now on.

Step 2 – Download SDK Platforms

From a command prompt, go to <SDK>/tools. Run this command to open the SDK manager.

./android sdk

Download the version of Android platform that is right for your phone. For example, my phone is running Android 2.3.4. So, I downloaded the nearest Android SDK 2.3.3.

For more information on downloading SDK platforms, read Google’s official guide.

Step 3 – Configure udev

udev is the Linux dynamic device management software. We will need to register our phone as a USB device.

From the command prompt, go to /etc/udev/rules.d folder.

Create a file in that folder called 51-android.rules as follows.

sudo vi 51-android.rules

In that file, I entered a single line for my HTC Thunderbolt.

SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", MODE="0666", GROUP="mygroup"

In your case, you will need to enter a different vendor ID (0bb4 is for HTC) and UNIX group that will own the device. For a list of vendor IDs and more information read the official hardware debugging guide.

Then, give read permission to the file for everyone.

sudo chmod a+r 51-android.rules

Step 4 – Plug in the Phone

Before you plugin your phone, enable USB debugging (Settings > Application > Development > USB Debugging).

While the VMWare guest window is in the foreground, plug in the phone to a USB slot. VMWare should automatically connect the guest with the device. Note: a device can be connected to either a guest or the host but not both. The fact that VMWare connected the device to the guest by default saved me a lot of trouble.

Step 5 – Test Connection

From the command prompt, go to <SDK>/platform-tools. Then run this command:

adb devices

Make sure that your phone is listed.

Configure JDK Logging in JBoss AS 7

I personally prefer logging using JDK logging API (java.util.logging package). It’s darn easy to use and comes with the JDK. IBM’s WebSphere was the first app server to switch to JDK logging. Now, JBoss 7 is also integrated with it. When developing, I need to bump up the log level to FINE. In this article, I will explain how to do that.

A typical class doing logging will look like this.

package com.mobiarch.nf;

public class TestBean {
    Logger logger = Logger.getLogger(getClass().getName());
    public void someMethod() {
        logger.fine("someMethod() called");
    }
}

Note, we use the class name as the log category name. This is the best practice. This helps us configure log level for the whole package.

In JBoss 7, logging is configured using the domain file (standalone.xml or domain.xml). During development using Eclipse JBoss Tools, we use the standalone profile. So, open the file <JBOSS>/standalone/configuration/standalone.xml. Locate the logging subsystem. It starts from this line:

<subsystem xmlns="urn:jboss:domain:logging:1.1">

Configure the log level for your Java package by adding these lines to the subsystem. This will set the log level to FINE.

<logger category="com.mobiarch.nf">
 <level name="FINE"/>
</logger>

You will also need to increase the log level for the console handler. Only then the low priority messages will show up in Eclipse Console view. Change the log level as shown below.

<console-handler name="CONSOLE">
 <level name="FINE"/>
 <formatter>
   <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
 </formatter>
</console-handler>

Save and close the file. Restart the server for the changes to take effect. That’s it. Now, low priority log messages from your code will start to show up in the console.

JSF Page Rendering After Validation Failure

The way JSF components render themselves depends on if validation had failed or not. This article will explain this subtle difference in behavior.

Consider the simple managed bean:

@ManagedBean
public class Controller {
    Logger logger = Logger.getLogger("TestWeb");
    @Size(min=3)
    private String name;
    private int age;

    public String updateCustomer() {
        logger.info("Updating " + name);

        return null;
    }

    public void prepareRender() {
        name = "Please enter a name";
        age = 0;
    }
    //getters and setters...
}

And the view:

<f:metadata>
    <f:event listener="#{controller.prepareRender()}" type="preRenderView"/>
</f:metadata>

<body> 
<h:messages />
<h:form>
  Name: <h:inputText value="#{controller.name}"/><br/>
  Age: <h:inputText value="#{controller.age}"/><br/>
  <h:commandButton value="Update" action="#{controller.updateCustomer()}"/>
</h:form>
</body>

Lifecycle After Valid Input Submission

Let us say that a user enters valid input (name: John Smith, age: 12) and submits the form. The lifecycle of the request will go as follows.

1. Restore View Phase – This phase completes as usual. Nothing special to discuss.

2. Apply Request Values Phase – User’s input is collected from the POST request parameters and stored with each UI component. Since all inputs are valid, no conversion error occurs at this point and no error message is queued.

3. Process Validation Phase – Each UI component validates the input. Since all inputs are valid, no error message is queued.

4. Update Model Values Phase – In this phase, the name and age properties of the Controller managed bean are updated with the user’s input as it was stored by the UI components in phase #2. As a result, name becomes “John Smith” and age becomes 12.

5. Invoke Application Phase – In this phase, the updateCustomer() method of the managed bean is invoked. The log message prints out the name as “Updating John Smith”.

6. Render Response Phase – First, the prepareRender() method of the managed bean is called, since, it is setup as a pre-render listener. This method resets the model properties. For example, name is set to “Please enter a name”. Next, each UI component renders itself. They grab the data to be output from the model. This is the crucial fact and will play a role later. So, the name text box shows “Please enter a name” and the age text box shows 0.

Lifecycle After Invalid Input Submission

Let us say that a user submits invalid input. Let’s consider two cases:

Case #1: Name is left empty. Age is 12.
Case #2: Name is “John Smith” and age is “abc”.

The lifecycle of the request will go as follows.

1. Restore View Phase – This phase completes as usual. Nothing special to discuss.

2. Apply Request Values Phase – User’s input is collected from the POST request parameters and stored with each UI component. Some invalid input can cause conversion failure. For example, in case #2, conversion will fail for the age text box. In that case, an error message will be queued. Note, a UI component will store input value even if conversion fails. So, in case #2, the age text box component will store “abc”. Lifecycle will proceed to the next phase, even if there was a conversion error.

3. Process Validation Phase – Each UI component validates the input. In case #1, validation will fail for the name text box. For each validation rule violation, an error message is queued.

4. Update Model Values Phase – Since, either conversion or validation had failed, this phase will be skipped. So, the name variable of the managed bean will remain null. And, age will remain 0.

5. Invoke Application Phase – Since, either conversion or validation had failed, this phase will be skipped.

6. Render Response Phase – First, the prepareRender() method of the managed bean is called. This will set the name variable to “Please enter a name”. Next, each UI component renders itself. Now, here is the twist. Instead of grabbing the data to be output from the model, the components will use the input that they had saved in Apply Request Values phase. That means:

For case #1: Name will be empty. Age will be 12.
For case #2: Name will be “John Smith”. Age will be “abc”.

Note, at the time of rendering, the name property is set to “Please enter a name” and age is 0. But, the UI components will ignore that and instead render the actual input entered by the user. So, the work done by prepareRender() is completely wasted. In real life, if the pre-render listener does any kind of database query, you may want to optimize that by skipping the work incase of a validation or conversion error.

public void prepareRender() {
    if (FacesContext.getCurrentInstance().isValidationFailed() == false) {
        name = "Please enter a name";
        age = 0;
    }
}

Paginated List in JSF 2.0

Pagination is the recommended pattern when you have a very large list to display. This reduces network I/O from the database and the web server. It may also reduce disk I/O in the database, although that depends on the database and several other factors.

Starting with JSF 2.0, the right and easy way to implement pagination is using GET request. As a general rule, you should avoid POST for any request that renders HTML. POST is used for display generation only if you need AJAX support. That’s because, in JSF 2.0, AJAX is supported for POST requests only.

In this article, I will explain how to implement pagination using GET request. I will write another article that shows how to do pagination using POST and AJAX.

The Managed Bean

The managed bean needs to keep track of the start index of the page. It will look something like this.

@ManagedBean(name="mbean")
public class Controller {
  List<UserBean> userList;
  int startIndex=0, pageSize=10;
  public List<UserBean> getUserList() {
    if (userList == null) {
      loadUserList();
    }
    return userList;
  }
  public void loadUserList() {
    //Fetch paged data from the database
    userList = dao.getAllUsersPaged(startIndex, pageSize);
  }
  //Various getters and setters omitted for brevity
}

The View XHTML

Let’s say that you are rendering a list as follows:

<f:metadata>
    <f:viewParam name="startIndex" value="#{siteAdmin.startIndex}" />
    <f:event listener="#{siteAdmin.loadUserList()}" type="preRenderView"/>
</f:metadata>

<h:form>
<h:link outcome="user_list" value="Previous">
  <f:param name="startIndex" value="#{mbean.startIndex - mbean.pageSize}" />
</h:link>
<h:link outcome="user_list" value="Next">
  <f:param name="startIndex" value="#{mbean.startIndex + mbean.pageSize}" />
</h:link>
<table>
 <thead> 
 <tr> 
   <th>Name</th> <th>E-mail</th>
 </tr> 
 </thead> 
 <tbody> 
 <ui:repeat value="#{mbean.userList}" var="user">
 <tr> 
   <td>#{user.name}</td> <td>#{user.email}</td>
 </tr> 
 </ui:repeat>
 </tbody> 
</table>
</h:form>

In the XHTML page, first study the metadata section. We can manipulate the startIndex property of the managed bean by sending a startIndex URL parameter.

When next or previous navigation link is clicked, a GET request will be sent. The startIndex URL parameter will be added. For example: “user_list.xhtml?startIndex=10”. JSF will first update the startIndex property of the managed bean from the value in the URL parameter. It will then call loadUserList() since that is the pre-render listener. This method will then load the correct page of the list since startIndex has been already modified.

Now, all there is left to do is disable Next and Previous links depending on if you are already on the first or last page. This is actually quite easy. I will leave a few hints:

• Disable Previous link if mbean.startIndex is 0.
• Disabling the Next link is a little more complicated. When requesting data from the database, ask for one more row than the page size. If the returned number of rows is more than or equal to the page size, then you know that there is no more items left.

This solution using GET request will perform well. We do not store the managed bean in session or view scope. This lowers memory requirement.

Defining Join Column Property in JPA

With JSF 2.0, EJB 3.1 Java EE has become easier to code than ever. However, JPA relationship remains a thorn in my shoes. I find it counter intuitive and just plain difficult to work with. Today, I will talk about a specific issue.

Consider two related JPA entities Employee and Organization. Employee has an unidirectional many-to-one relationship to Organization.

@Entity
public class Employee {
 @Id
 @GeneratedValue(strategy=GenerationType.IDENTITY)
 private int id;
 private String name;
 private String phone;
 //uni-directional many-to-one association to Organization
 @ManyToOne
 @JoinColumn(name="organizationId")
 private Organization organization;
 //Getters and setters omitted...
}

@Entity
public class Organization {
 @Id
 @GeneratedValue(strategy=GenerationType.IDENTITY)
 private int id;
 private String logo;
 private String name;
 //Getters and setters omitted...
}

And the schema (MySQL in this case):

CREATE TABLE Organization (
 id integer NOT NULL AUTO_INCREMENT,
 name varchar(128) DEFAULT NULL,
 logo varchar(128) DEFAULT NULL,
 UNIQUE KEY OrganizationU1 (cn),
 PRIMARY KEY (id)
);
CREATE TABLE Employee (
 id integer NOT NULL AUTO_INCREMENT,
 name varchar(128) NOT NULL,
 phone varchar(45) DEFAULT NULL,
 organizationId integer DEFAULT NULL,
 PRIMARY KEY (id),
 CONSTRAINT UserRegistryFK1 FOREIGN KEY (organizationId) 
  REFERENCES Organization (id)
);

This works just fine. But, I have a bone to pick. The Employee entity doesn’t have a property defined for the organizationId column. To get the organization ID, we have to load the organization and then get the ID from there.

Employee employee = em.find(Employee.class, id);
int orgId = employee.getOrganization().getId();

This seems wasteful. (In many-to-one, eager fetching is used by default. So, the code above will use a single SQL statement to load both employee and organization. Still, that is wasteful, if the Organization table has large rows).

Another problem appears when we need to create a new employee. Since, there is no way to store the organization ID within the Employee object, we must pass it separately to the DAO class:

public void addEmployee(Employee e, int orgId) throws Exception {
 e.setOrganization(
  getOrganization(orgId));
 em.persist(u);
}

This is just messy. Things will be a lot cleaner if we could store the organization ID directly within the Employee entity. As it turns out, this can be done.

@Entity
public class Employee {
 //Existing code omitted...
 //...
 @Column(name="organizationId", insertable=false, updatable=false)
 private int organizationId;
}

Basically, we are adding the organizationId property like any other mapped property. Except, we must set insertable and updatable to false. We need to do that because for insert and updates involving relationship, the related object property is used during persistence. In our case, that will be the Organization property of the Employee.

For example, now, our insert logic becomes cleaner.

public void addEmployee(Employee e) throws Exception {
 e.setOrganization(
  getOrganization(e.getOrganizationId()));
 em.persist(u);
}

Also, now, we can employ lazy loading and get the organization ID of an employee without loading the Organization.

On a side note, it just pains me to have to load the Organization before I can insert an employee. There is absolutely no business case for it. Not only is this unnecessary coding, it also adds load on the database for no good reason. For now, I will live with this to get the “convenience” of ORM.

Display JSF Error Messages Using Custom HTML

By default JSF messages are shown using <h:messages/> tag. This includes form validation error messages. This tag shows messages in a simple bulleted list using <ul> and <li>. For example:

<ul>
<li>Please enter a phone number</li>
<li>Please enter a valid e-mail address.</li>
</ul>

However, if you wish to show messages using custom HTML layout and additional instructions, <h:messages> will not be useful. The code below shows all error messages (severity level 2) using custom HTML:

<h:panelGroup rendered="#{facesContext.maximumSeverity.ordinal == 2}" 
  styleClass="alert_error">
 <p>Please fix these problems:</p>
 <ul>
   <ui:repeat var="msg" value="#{facesContext.messageList}">
     <li>#{msg.summary}</li>
   </ui:repeat>
 </ul>
</h:panelGroup>

Note, JSF doesn’t say anywhere that the error level messages have an ordinal of 2. This may change from implementation to implementation.

Similarly, to show informational messages, you can do:

<h:panelGroup rendered="#{facesContext.maximumSeverity.ordinal == 0}" 
  styleClass="alert_success">
 #{facesContext.messageList[0].summary}
</h:panelGroup>

Calling JAX-RS Service Using AJAX Client

At the time of this writing, there is no standard way to generate AJAX client proxy for a JAX-RS RESTful service. You will find yourself writing a lot of code in the client side just to invoke these services. Several JAX-RS implementations provide their own proprietary client code generation solution. In this article, I will discuss how to generate a client if you are using RESTeasy. JBoss AS 7.1 uses RESTeasy by default which is what I used to test my work.

Let’s say that we have a very simple service resource class.

@Path("/svc")
public class MyBean {
  @Path("/value")
  @Produces("text/plain")
  @GET
  public String getValue() {
    return "Some value";
  }
}

First, register the code generation servlet in web.xml.

<listener>
<listener-class>
  org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
</listener-class>
</listener>
<servlet>
<servlet-name>RESTEasy JSAPI</servlet-name>
  <servlet-class>org.jboss.resteasy.jsapi.JSAPIServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>RESTEasy JSAPI</servlet-name>
  <url-pattern>/rest-api.js</url-pattern>
</servlet-mapping>

This binds the “/rest-api.js” path to the generated JavaScript. You can use any other path if you like.

In your HTML file, import the client side script.

<script type="text/javascript" src="rest-api.js"></script>

Note, “res-api.js” is the path to the JSAPIServlet as registered in web.xml.

The script defines a JavaScript object for every JAX-RS resource class by the same name. In our case, we will get a variable called MyBean. This JavaScript object has a method for each exposed method of the JAX-RS resource class. In our case, the name of the method will be getValue().

Let’s go ahead and code the rest of the HTML file.

<head>
  <script type="text/javascript" src="rest-api.js"></script>
  <script type="text/javascript">
  function doTest() {
    MyBean.getValue({$callback: onResult});
  }
  function onResult(status, xhr, data) {
    console.log("Status is: " + status);
    if (status == 200)
        alert(data);
    else
        console.log("Do error handling");
  }
</script>
</head>
<body>
<button onclick="doTest();">Test</button>
</body>

Basically, MyBean.getValue() method takes a parameter object. At minimum, we need to supply the callback method which is set using the $callback property. The callback method receives three input parameters:

• The HTTP reply status. Use this to do error handling.
• The XmlHttpRequest object used to make the AJAX call.
• The actual reply data. If the response is a JSON document, then system parses it and gives you the JavaScript object. If the response is XML, then you get the Document object. Otherwise, you get the raw response data as is.

For more information, see the official doc on RESTeasy AJAX client programming.

Pushing Existing Repository to GitHub

Let’s say that you have a local Git repo that you have been using to manage your code for a while. Now, you wish to publish it to  GitHub so others can look at it and participate in development. How will you do that?

Well, the key to pushing to any remote repo for the first time is to make sure that the remote repo is completely empty. Normally, you will use “git init –bare” to create a bare/empty repo on the remote server. In GitHub, you use the web GUI to create a repo. There, make sure that you do not choose Initialize this repository with a README checkbox. This will create a bare repo in GitHub.

After the repo is created in GitHub, run these commands from your local Git repository. Let’s say that the URL for the newly created GitHub repo is “https://github.com/bobby/MyRepo.git&#8221;.

git remote add MyGitHub https://github.com/bobby/MyRepo.git
git push MyGitHub master

Then, enter your GitHub user ID and password.

So, the trick is not to create the README file when you create the repository in GitHub. Otherwise, the repository will not be bare and when you try to do a push, you will get an error message “Updates were rejected because the tip of your current branch is behind”.

Endless Scrolling List Using jQuery

The mobile site for Pinterest got me all excited about endless scrolling list. This makes sense for mobile sites where we need to minimize user input. It turns out that the behavior is quite easy to implement using jQuery.

Our goal is to fetch new data and add to the list just before the user is about to scroll to the very bottom of the list.

The amount of the document that is left to be shown below the window frame is:

$(document).height() - $(window).scrollTop() - $(window).height()

When this amount reaches a minimum value, say 100 pixels, we can begin to fetch additional data and add items to the list.

Let’s create a test application. First, we need an element for the list where we will add items.

<div id="list_area"></div>

Attach a scroll event handler for the window.

$(function() {
 addContent();
 $(window).scroll(function () { 
  if ($(document).height() -
   $(window).scrollTop() - 
   $(window).height() <= 100) {
   console.log("Time to add content");
   addContent();
  }
 });
});

Example implementation of addContent().

var i = 0;
function addContent() {
 var div = $("#list_area");
 for (var j = 0; j < 50; ++j, ++i) {
   div.append($("<p>", {"text": "Paragraph " + i}));
 } 
}

HTML5 File Upload with Progress Bar Using jQuery

XMLHttpRequest Level 2, HTML5 File API and Progress event work together to provide a completely new file upload model. There are numerous benefits to this new model compared to the old multi-part form approach.

• You can upload files using Ajax.
• You can show progress indicator.
• The server side code becomes a lot simpler.

Every new web application should take a look the new approach.

Unfortunately, jQuery is somewhat lagging in its support for the new approach. There are a few specific work arounds you have to take to make things to work. By work around, I mean, things that you must do that could have been easily taken care of by jQuery.

Note: If you are not using jQuery and just want to know how to upload file using XMLHttpRequest Level 2, then read this other article. The article below assumes that you know the fundamentals of XMLHttpRequest Level 2 already and just want to know how to use jQuery to do the work.

Let’s start with the form. There are many ways to get the list of files to upload. You can use drag and drop. Or, as is the case in this article, we will use a simple input of type file. Also, to display progress, you can use the HTML5 progress element. But, for a better look, we will choose to use jQuery UI’s progress widget. Our HTML markup will be very simple.

<input type="file" id="fileToUpload"/><br/>
<div id="progressbar"></div>
<button id="upload_btn">Start Uploading</button>

From the ready function, we setup the UI. This is just regular jQuery stuff and we are not doing anything with file upload API yet.

$(function(){
    $("#progressbar").progressbar();
    $("#progressbar").hide();
    $("#upload_btn").click(upload);
});

All the action happens from the upload() method.

function upload(){
    var fileIn = $("#fileToUpload")[0];
    //Has any file been selected yet?
    if (fileIn.files === undefined || fileIn.files.length == 0) {
        alert("Please select a file");
        return;
    }

    //We will upload only one file in this demo
    var file = fileIn.files[0];
    //Show the progress bar
    $("#progressbar").show();

    $.ajax({
        url: "MediaUploader?fileName=" + file.name + "&mimeType=" + file.type,
        type: "POST",
        data: file,
        processData: false, //Work around #1
        contentType: file.type, //Work around #2
        success: function(){
            $("#progressbar").hide();
        },
        error: function(){alert("Failed");},
        //Work around #3
        xhr: function() {
            myXhr = $.ajaxSettings.xhr();
            if(myXhr.upload){
                myXhr.upload.addEventListener('progress',showProgress, false);
            } else {
                console.log("Upload progress is not supported.");
            }
            return myXhr;
        }
    });
}

Alright, let’s go through the work arounds.

1. We must set processData to false. Here’s why. We set the File object as the data field. jQuery doesn’t recognize File object and tries to use it to generate regular form post data, which obviously fails.
2. The content type needs to be set correctly to the MIME type of the file. Otherwise, some browsers will set it to “application/x-www-form-urlencoded”. The server will then try to parse the request body as form input, which will obviously fail.
3. This is the big one. jQuery provides no way of attaching a “progress” event listener for the XMLHttpRequest object. The work around is to register your own XMLHttpRequest object creation method and attach the event handler from there.

Now, all there is left to do is show the progress.

function showProgress(evt) {
    if (evt.lengthComputable) {
        var percentComplete = (evt.loaded / evt.total) * 100;
        $('#progressbar').progressbar("option", "value", percentComplete );
    }  
}

The server side is, of course, quite straightforward. Your best bet is to write a Servlet. Various JAX-RS implementations provide custom extensions to handle HTML5 file upload. You can also use that option if you are not worried about getting locked down to an implementation. Here, we will use a Servlet.

protected void doPost(HttpServletRequest request, HttpServletResponse response) 
  throws ... {
    String fileName = request.getParameter("fileName"); 
    InputStream is = request.getInputStream();
    //Read the file contents from the input stream
    byte buff[] = new byte[256];
    int len;

    while ((len = is.read(buff)) > 0) {
        //...
    }
}