As I mentioned before, getting zoom to work was pretty easy. Implementing panning/dragging was the hard part. The major issues I encountered and subsequently fixed were the following:

1. Panning continues indefinitely in all directions.
2. When you zoom and then pan, stop, and then start again, the view jerks to a new position instead of panning from the existing position.
3. Excessive panning towards the left and top can be constrained, but panning towards the right and bottom is not so easily constrained.

Once I fixed all the problems, I figured that it would be nice to document it for future reference, and I also think it would be a useful resource for others who have the same problem. Now a little disclaimer before I go any further: I’m not an Android expert and I’m really not that great with graphics; I just started it learning to program for Android this semester for one of my Masters electives. So there might be a better way of doing all this, and if there is, please let me know! Also, if you want to skip all the explanations and just see the code, you can skip to the last page.

Let’s start with the simple stuff first, that is implementing pinch-zoom. To implement pinch-zoom, we make use of the ScaleGestureDetector class. This class helps you detect the pinch-zoom event. Using it is pretty simple:

public class ZoomView extends View {

    private static float MIN_ZOOM = 1f;
    private static float MAX_ZOOM = 5f;

    private float scaleFactor = 1.f;
    private ScaleGestureDetector detector;

    public ZoomView(Context context) {
        super(context);
        detector = new ScaleGestureDetector(getContext(), new ScaleListener());
    }

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        detector.onTouchEvent(event);
        return true;
    }

    @Override
    public void onDraw(Canvas canvas) {
        super.onDraw(canvas);

        canvas.save();
        canvas.scale(scaleFactor, scaleFactor);

        // ...
        // your canvas-drawing code
        // ...

        canvas.restore();
    }

    private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
        @Override
        public boolean onScale(ScaleGestureDetector detector) {
            scaleFactor *= detector.getScaleFactor();
            scaleFactor = Math.max(MIN_ZOOM, Math.min(scaleFactor, MAX_ZOOM));
            invalidate();
            return true;
        }
    }
}

Your view class has four private members: MIN_ZOOM, MAX_ZOOM, detector, and scaleFactor. The first two are static constants that define the maximum and minimum zoom allowed. The third is of type ScaleGestureDetector and does all the heavy lifting as far as zooming is concerned. The fourth member holds the scaling factor i.e., a number that represents the amount of “zoom”.

Now what does this do?

In the constructor, you initialize the detector. The constructor to ScaleGestureDetector takes two parameters: the current context, and a listener. Our listener is defined inside the class ScaleListener which extends the abstract class ScaleGestureDetector.SimpleOnScaleGestureListener. Inside the onScale method, we get the current scale factor from the detector. We then check to see if it is greater or smaller than our upper and lower bounds. If so, we make sure that it we limit the value to be between those bounds. We then call invalidate() which forces the canvas to redraw itself.

The actual scaling happens inside the onDraw method. There, we save the canvas, set its scaling factor (which is the one we got from the detector), draw anything we need to draw, and then restore the canvas. What happens now is that anything you draw on the canvas is now scaled by the scaling factor. This is what gives you the “zoom” effect.

Initially I was going to call the render(…) method of MappingJacksonJsonView but that didn’t work because the content-type had already been set to application/json. The solution I came up with was to duplicate some of the code (ugh) inside MappingJacksonJsonView to get the JSON as a string and to then write that to the response:

@RequestMapping
public void processFileUpload(HttpServletResponse response, Model model, ...) {

    ...

    //Set the content-type and charset of the response
    response.setContentType("text/plain");
    response.setCharacterEncoding("UTF-8");

    //I need to use another OutputStream here; I cannot use the response's OutputStream because that will cause errors
    //later on when the JSP needs to render its content (recall that getOutputStream() can only be called exactly once
    //on a response). Therefore I'm writing the data to a ByteArrayOutputStream and then writing the byte array from
    //the ByteArrayOutputStream to the response manually.

    ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
    ObjectMapper objectMapper = new ObjectMapper();
    JsonGenerator generator = objectMapper.getJsonFactory().createJsonGenerator(byteArrayOutputStream, JsonEncoding.UTF8);

    //Before I can convert the data into JSON, I will need to filter some attributes out of the model (namely BindingResult)
    Map<String, Object> result = new HashMap<String, Object>();

    for(Map.Entry<String, Object> entry : model.asMap().entrySet()) {
        if(!(entry.getValue() instanceof BindingResult)) {
            result.put(entry.getKey(), entry.getValue());
        }
    }

    objectMapper.writeValue(generator, result);
    response.getWriter().write(new String(byteArrayOutputStream.toByteArray(), "UTF8"));
}

This still seems a little hacky to me. A possible improvement is to annotate the action with @ResponseBody and return the JSON as a string without involving the response at all. If anyone has a better solution, I’m all ears!

The whole story: At work we use Maven to build our project. Over the last few months, we started noticing a disparity in build times between different developers even though the hardware they were using was similar to each other (Core i7′s with 6 Gb RAM). Initially we suspected that it might have to do with SSD performance-degradation. Some of us were using SSD’s that didn’t support TRIM and others didn’t have TRIM enabled. I was one of the few with the former problem. I secure-erased my drive but still saw no performance benefits. I even got a new drive and even with that I didn’t see much of an improvement either.

We finally realized that the build-time disparity was related to the version of maven some developers were using. On maven 3.0b1, build times are much faster compared to 3.0.3. In 3.0.3 there is a performance regression when maven tries to build the dependency graph. For example, using 3.0b1 our project built in 3 minutes and 30 seconds, whereas using 3.0.3, the build times were upwards of 9 minutes. Long build-times take away from the amount of productive coding-time a developer has.

I was determined to find the reason for this performance regression and did some investigation by looking at the source for 3.0b1 and 3.0.3. In 3.0b1, maven uses its own code to resolve dependencies and build the dependency graph, whereas in 3.0.3 it uses the aether library. For more background information on the matter, take a look at this post on the maven developer’s mailing list and this JIRA issue.

Long story short, to get better build times, maven needs to use version 1.12 of aether. I downloaded the maven source and edited the pom.xml file to use version 1.12 of aether. I then built maven from source and got a deployable version that uses the newer aether library. When I tested it out, the build times were comparable to 3.0b1.

I initially thought that version 3.0.4 of maven would include version 1.12 of aether. But it turns out that there were licensing changes and so the maven developers are discussing whether to include it. In the meantime, you can use this version of maven that I built from source, which includes version 1.12 of aether. It’s a zip file and you can install it like you would normally install maven.

Although I pulled my hair out for an hour or two (I was getting a 404 when hitting my controller with with a .jsonp extension; I’ll explain why, later), the resulting solution is actually pretty simple. First, you need to extend MappingJacksonJsonView to create your own view. Since MappingJacksonJsonView already handles the creation of JSON, all we need to do is pad it with our callback. The way to do this is to override the MappingJacksonJsonView#render(Map model, HttpServletRequest request, HttpServletResponse response) method (This method is actually defined in AbstractView, a Spring-provided abstract class that you can override in your own view). The full source is below:

package net.vivin.mvc.spring.view.jsonp;

import org.springframework.web.servlet.view.json.MappingJacksonJsonView;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.util.Map;

public class MappingJacksonJsonpView extends MappingJacksonJsonView {

	/**
	 * Default content type. Overridable as bean property.
	 */
	public static final String DEFAULT_CONTENT_TYPE = "application/javascript";

    @Override
    public String getContentType() {
        return DEFAULT_CONTENT_TYPE;
    }

 	/**
	 * Prepares the view given the specified model, merging it with static
	 * attributes and a RequestContext attribute, if necessary.
	 * Delegates to renderMergedOutputModel for the actual rendering.
	 * @see #renderMergedOutputModel
	 */
    @Override
	public void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception {

        if("GET".equals(request.getMethod().toUpperCase())) {
            @SuppressWarnings("unchecked")
            Map<String, String[]> params = request.getParameterMap();

            if(params.containsKey("callback")) {
                response.getOutputStream().write(new String(params.get("callback")[0] + "(").getBytes());
                super.render(model, request, response);
                response.getOutputStream().write(new String(");").getBytes());
                response.setContentType("application/javascript");
            }

            else {
                super.render(model, request, response);
            }
        }

        else {
            super.render(model, request, response);
        }
    }
}

The DEFAULT_CONTENT_TYPE public static property and the getContentType() method are important. Spring uses this method (among other things) to find the best candidate view. I spent at least an hour trying to figure out why I was getting 404′s. It was because I hadn’t overridden the property and the accessor to return the correct content-type. Going back to the render method itself, you can see that it’s pretty simple. First I make sure that the request method is GET. Then I get the request parameter-map and check for the callback parameter. If this parameter exists, I write out the name of the callback with an open parenthesis. Then I call the parent class’s render method. This method belongs to MappingJacksonJsonView and will write out JSON to the response. Finally, I write out a closing parenthesis and a semicolon to the response and set the content type to application/javascript. So as you can see, I’ve converted JSON into JSONP.

The next thing you need to do is include an entry for your new view in the springmvc-servlet.xml file. This part also took a little work. I wasn’t sure how to include my new view within the ContentNegotiatingViewResolver bean. But this post proved to be remarkably helpful. The post actually talks about returning XML or JSON (based on the extension), but I was able to adapt it to return JSON or JSON. Here’s what it looks like:

    <bean class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver">
        <property name="favorPathExtension" value="true"/>
        <property name="mediaTypes">
            <map>
                <entry key="json" value="application/json"/>
                <entry key="jsonp" value="application/javascript"/>
            </map>
        </property>
        <property name="defaultViews">
            <list>
                <bean class="org.springframework.web.servlet.view.json.MappingJacksonJsonView"/>
                <bean class="net.vivin.mvc.spring.view.jsonp.MappingJacksonJsonpView"/>
            </list>
        </property>
    </bean>

If you notice, the value property for jsonp has been set to application/javascript. Spring uses this value and checks it against the view class to figure out the best candidate view. If you didn’t override the DEFAULT_CONTENT_TYPE property and the associated getter, you would get a 404.

Finally, you need a url-pattern entry under servlet-mapping in your web.xml file so that the new .jsonp extension is recognized:

    <servlet-mapping>
        <servlet-name>springmvc</servlet-name>
        <url-pattern>*.json</url-pattern>
        <url-pattern>*.jsonp</url-pattern>
        ...
    </servlet-mapping>

That’s pretty much it. With this code in place, you can hit your controller with http://my.domain.com/controllerName/actionName.jsonp?callback=myCallback and you’ll get your data back as JSONP! I thought this solution was pretty simple and a little less invasive than creating a filter. Comments/suggestions/criticisms for improvement are welcome!

The source for the integration is also hosted on GitHub. My approach towards translating validation constraints from the server-side to the client-side was two-fold: gather validation constraints from the object and represent it in a canonical form. Using the canonical form, generate Javascript code that uses Regula for validation. To do this, I created a service that examines a domain object and gathers all information regarding its properties and validation constraints. The service returns this information in a canonical form, that I then inserted into the model. On the client-side, I had a tag that used the canonical form and outputted Javascript that uses the Regula framework. Initially, I was calling the service explicitly from an action in the controller. Later, in an effort to make the integration less-invasive and more seamless, I used an aspect-oriented approach with interceptors. In fact, that’s where I’d like to start.

I created an annotation called @ValidateClientSide that marks a domain object as requiring client-side validation. Then, I created an interceptor called ClientSideValidationInterceptor that will call the validation service and gather validation information:

I saw a question on Stackoverflow today that talked about the getfield opcode in the context of the trim() method in the String class. In the trim() method, you have the following comments:

int off = offset;      /* avoid getfield opcode */
char[] val = value;    /* avoid getfield opcode */

The author of the question wanted to know what these comments mean. This question seemed pretty interesting to me and so I went and did some research. I found out that getfield is an operation that lets you get access to the member variable/field of a class. This operation is fairly expensive as it involves indexing into the runtime constant pool. Performing this operation a few times does not really incur a performance hit. It is when you perform the operation multiple times, that performance becomes an issue. You can see this from the next few lines of code:

while ((st < len) && (val[off + st] <= ' ')) {
    st++;
}
while ((st < len) && (val[off + len - 1] <= ' ')) {
    len--;
}

Now if the author of the trim() method hadn’t assigned offset and value to local variables, a getfield operation would be performed every time the loop-condition is tested. This is obviously inefficient. Therefore, the author assigned the the values of offset and val into the local variables off and val. So now, instead of getfield you have iload (for off anyway), which performs much faster.

Ultimately, it serves as a way to make program code not just functional, but beautiful and artistic. Thus, we introduce a new criteria to programming. Your code must not only be elegant algorithmically, but must also be poetic and artistic (also, since program code consists of haikus, you need to represent your code in sets of 3 lines with the first and last lines having 5 syllables, and the second line 7. That is, conforming to haiku rules). CherryBlossom serves to blend the programmer and the poet into one entity (hopefully with amazing results).

Here is an example of “Hello World!” in CherryBlossom. I have opted to use a spruced up div tag instead of enclosing my beautiful poem in soulless sourcecode tags.

Trust me, this does print out “Hello World!”! You might think I’m crazy, but I’m not! Either tomorrow or day after, I’ll add a new page to the Projects menu and you’ll see how CherryBlossom works and you will also have access to the interpreter!

Last week I was solving a problem at work that required the use of a Generic (n-ary) Tree. An n-ary tree is a tree where node can have between 0 and n children. There is a special case of n-ary trees where each node can have at most n nodes (k-ary tree). This implementation focuses on the most general case, where any node can have between 0 and n children. Java doesn’t have a Tree or Tree Node data structure. I couldn’t find any third-party implementations either (like in commons-lang). So I decided to write my own.

First, we need to define the node of our tree. Our node has two attributes. One is the data, and another is a List which can contain references to the children of that node:

Structure of a Generic Tree Node

The code for a Generic Tree Node looks like this:

GenericTreeNode.java

import java.util.ArrayList;
import java.util.List;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class GenericTreeNode<T> {

    public T data;
    public List<GenericTreeNode<T>> children;

    public GenericTreeNode() {
        super();
        children = new ArrayList<GenericTreeNode<T>>();
    }

    public GenericTreeNode(T data) {
        this();
        setData(data);
    }

    public List<GenericTreeNode<T>> getChildren() {
        return this.children;
    }

    public int getNumberOfChildren() {
        return getChildren().size();
    }

    public boolean hasChildren() {
        return (getNumberOfChildren() > 0);
    }

    public void setChildren(List<GenericTreeNode<T>> children) {
        this.children = children;
    }

    public void addChild(GenericTreeNode<T> child) {
        children.add(child);
    }

    public void addChildAt(int index, GenericTreeNode<T> child) throws IndexOutOfBoundsException {
        children.add(index, child);
    }

    public void removeChildren() {
        this.children = new ArrayList<GenericTreeNode<T>>();
    }

    public void removeChildAt(int index) throws IndexOutOfBoundsException {
        children.remove(index);
    }

    public GenericTreeNode<T> getChildAt(int index) throws IndexOutOfBoundsException {
        return children.get(index);
    }

    public T getData() {
        return this.data;
    }

    public void setData(T data) {
        this.data = data;
    }

    public String toString() {
        return getData().toString();
    }

    public boolean equals(GenericTreeNode<T> node) {
        return node.getData().equals(getData());
    }

    public int hashCode() {
        return getData().hashCode();
    }

    public String toStringVerbose() {
        String stringRepresentation = getData().toString() + ":[";

        for (GenericTreeNode<T> node : getChildren()) {
            stringRepresentation += node.getData().toString() + ", ";
        }

        //Pattern.DOTALL causes ^ and $ to match. Otherwise it won't. It's retarded.
        Pattern pattern = Pattern.compile(", $", Pattern.DOTALL);
        Matcher matcher = pattern.matcher(stringRepresentation);

        stringRepresentation = matcher.replaceFirst("");
        stringRepresentation += "]";

        return stringRepresentation;
    }
}