Java Archive

If you are looking for a way to implement location based services within your android application without using the web services of Google, you might be interested in the CloudMade web services. These web services provide functions like geocoding, searching for objects which are close to a given coordinate, retrieving map tiles as images and even to create a full route from a start point via several transit points to an end point.

To provide these services, CloudMade relies on the collaborative OpenStreetMap (OSM) project which follows the same principles as Wikipedia to create a free map.

To ensure an easy usage of the web services, CloudMade provides several libraries for the iPhone and other programming languages. The provided Java API is using an old implementation of the Apache HTTP Client which makes it unusable for Android devices. That’s why I’ve created a port of the lightweight CloudMade Java API which can be used on android devices.

The core of this library is the com.appsolut.api.cloudmade.CMClient which hides the HTTP communication of the different calls from the developer. The methods within this class are well documented and I will only give short overview of the most important methods:

public GeoResults find(String query, int results, int skip, BBox bbox, boolean bboxOnly, boolean returnGeometry, boolean returnLocation)

This method provides the geocoding functionality:

public GeoResult findClosest(String object_type, Point point) throws ObjectNotFoundException

If you want to find a certain object which is close to a point you can use this method:

public byte[] getTile(double latitude, double longitude, int zoom, int styleId, int size)

This method will return a png image of a map tile. For example, this might return a tile which looks like the following:


An example tile retrieved from the CloudMade web service

public Route route(Point start, Point end, RouteType routeType, List<Point> transitPoints, RouteTypeModifier typeModifier, String lang, MeasureUnit units) throws RouteNotFoundException

Using this method it is possible to create a route.

There exists also an android test project which can be used to ensure that everything works fine. You can also take a look at the test cases to see an example of how to use the library.

You can download or browse the source code at our repository at Google Code ( or use svn to check it out.

For more information you can refer to the following links:

If you are having trouble with this port feel free to ask questions.

Please Note:
It is important that you create your own API key when you are using the CloudMade web services. Please refer to the CloudMade FAQ for more information on this topic.

by Kevin Kratzer

When developing Apps for the Android OS you might end up in the situation where you have common Activities or Services which could be reused in multiple Apps with just a little modification. As you don’t want to copy these classes into every single project – which would lead to a hardly maintainable code – you would seek a way to reference the source of these classes from multiple projects. For non-android applications an approach for this problem would be to break up the code into multiple libraries so that the required functionality can be referenced from multiple projects. As long as you are not interacting with external resources this attempt is also possible in Android projects (build a jar and reference it from the projects). But if you are using external resources these classes can’t be used within a library. This is caused by the fact that the Android SDK won’t generate matching ids within the “R” class for external resources which are included in a referenced jar file. In this post I want to show you different solutions for this problem which can avoid the necessity to copy the source code into the projects.

About a year ago we decided to give the Bean Validation API a try and in the beginning we were really exited about the easy to use, annotation based interface. But soon we had to do cross-field validation which lead us to revise our first impression. Unfortunately the Bean validation API offers no out of the box way of validating a field based on the value of another field and since we wanted to stay consistent with the API design we decided to go down the rocky road of writing our own custom class-level validation annotations and custom validators which really is a boring, repetitive chore and involves heavy use of reflection.

Of course boring, repetitive chores really cry for simplification and automation and therefore I soon started doing research on how others solved this problem. In this article I will outline and analyze some of the solutions I came across.

The standard approach

Creating new validation logic involves two steps. A constraint annotation and a validator which contains the validation logic have to be created. To keep things simple we will implement a class-level constraint which can be used to assert that the value of one field is greater than the value of another field of the object to be validated.

This is the annotation definition:

* Compares two of the fields of an object.
@Constraint(validatedBy = GreaterThanValidator.class)
public @interface GreaterThan {

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};

    String field();

    String greaterThan();

    /**field > greaterThan*/
    Class<? extends Comparator<Object>> comparator();

    @Target({ TYPE, ANNOTATION_TYPE })
    @interface List {
        GreaterThan [] value();

The “field” and “greaterThan” fields contain the names of the bean properties which will be compared. For this comparison we also need a comparator. Finally, we add a “List” field so that we can use more than one instance of the annotation at the class-level.

This annotation definition – already a lot of work for the humble task of comparing two values – pales in comparison to the validator:

* Validates the GreaterThan constraint
public class GreaterThanValidator implements
ConstraintValidator<GreaterThan, Object> {

    /** field > greaterThan ? */
    private String field;
    private String greaterThan;
    private Comparator<Object> comparator;

    * This will be called before isValid to initialize the validator
    public void initialize(GreaterThan ann) {

        field = ann.field();
        greaterThan = ann.greaterThan();
        Class<? extends Comparator<Object>> comparatorClass = ann.comparator();
        try {
            comparator = comparatorClass.newInstance();
        } catch (Exception e) {
            throw new IllegalArgumentException("Can't instantiate comparator",e);

    * This will be called to validate an object
    public boolean isValid(Object validateThis, ConstraintValidatorContext ctx) {
        if (validateThis == null) {
            throw new IllegalArgumentException("validateThis is null");
        Field fieldObj = null;
        Field greaterThanObj = null;
        // Find getters the properties
        try {
        } catch (Exception e) {
            throw new IllegalArgumentException("Invalid field name",e);
        try {
            greaterThanObj = validateThis.getClass().getDeclaredField(greaterThan);
        } catch (Exception e) {
            throw new IllegalArgumentException("Invalid greaterThan name",e);
        if (fieldObj == null || greaterThanObj == null) {
            throw new IllegalArgumentException("Invalid field names");

        try {
            // get field values
            Object fieldVal = fieldObj.get(validateThis);
            Object largerThanVal = greaterThanObj.get(validateThis);
            // compare
            return fieldVal == null && largerThanVal == null
            || fieldVal != null && largerThanVal != null
            &&, largerThanVal) > 0;
        } catch (Exception e) {
            throw new IllegalArgumentException("Can't validate object", e);



A lot of work for a simple greater than comparison and it isn’t even production quality code; you would have to add a few more lines for using it in your projects. Of course you could save some work by pushing some of the details into super classes but there are faster ways to achieve the same results. Another problem with this annotation is that it offers no compile-time type safety. Typos in the field names or supplying the wrong comparator class will lead to runtime errors. The following approach solves some of those problems and comes from a forum discussion on the topic (see

The @AssertTrue approach

The @AssertTrue annotation is one of the annotations of the Bean Validation API which are also applicable to methods. It simply asserts that the return value of the annotated method is true when called during validation. So if we just added a public method called isConstraint1Satisfied and annotated it like so:

public class AssertTrueExample {

public int i=0;
public int j=0;

@AssertTrue(message="Constraint 1 is not satisfied")
public boolean isConstraint1Satisfied()
return i==j;

…we could validate our object without breaking into sweat. Let’s see what the authors of the JSR-303 specification have to say about this.

Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving to be time consuming and error-prone. To avoid duplication of these validations in each layer, developers often bundle validation logic directly into the domain model, cluttering domain classes with validation code that is, in fact, metadata about the class itself. […]

Well, the @AssertTrue solution obviously violates this separation of concerns the Bean Validation API is all about and puts the validation logic into the model class. You might disagree, but in my opinion very often, too little is to be gained by separating those concerns when it comes to internal dependencies. Sometimes it is even harmfull. I will give you one example.

In one of our projects we had to encapsulate the valid parameters for a call to a legacy statistics library into an object. The validity of the parameters for this call is highly dependent on the value of other parameters and there was no way those constraints could have been factored into separate reusable constraint annotations. We created one annotation, one validator and used it once and there is no chance this annotation could ever be reused. The authors of the JSR-303 specification are of the opinion that validation logic in the domain model is often or always clutter, but I would hesitate to call this special kind of validation code clutter. Sure, validation code for an email address and the likes can safely be considered clutter because email addresses are really abundant in most information systems and everyone knows what an email address is and what it should look like; hence the validation logic contains little information for someone reading the code. The validation logic for the parameter class is a totally different topic. It really belongs to the model class, is not reusable and contains a lot of important information. It more or less IS the class and therefore extracting it into an annotation makes little sense. I think the @AssertTrue approach (and also the @ScriptAssert approach) fits this use case much better than any other approach I have come across so far.

The @ScriptAssert approach

Hibernate Validator 4.1 brought us the @ScriptAssert class-level annotation. It is an ingenious application of the Java Scripting API. Instead of writing your custom validation code in java it lets you use one of many supported scripting languages. It more or less shares the strengths and weaknesses of the @AssertTrue approach but is even more concise and has the added advantage of not cluttering the interface of the class with validation methods. This is what the last example would look like if we used the @ScriptAssert annotation:

public static class ScriptAssertExample

int i=0;
int j=0;


The big disadvantage compared to the @AssertTrue approach is of course that using a scripting language comes at the cost of losing compile-time safety.


The most important aspect of the three approaches to cross-field validation considered here is where they put the validation logic; into the model class or into an external validator class. In this article I mainly outlined why it is a bad idea to create a custom validator and annotation every time the Bean Validation API supplied annotations don’t fit your needs. But don’t get me wrong, I am not saying that putting the validation logic into the model class is always a good idea. There are at least two things that have to be considered:

  • Is it unlikely that the validation logic can be reused?
  • Does it contain important information that really belongs in the model class?

I think that if you can answer any of those questions with a ‘yes’ you can really put the validation logic into the model class without having to suffer a bad conscience.

In the next article I will present a hybrid approach based on the strategy pattern. This approach makes it possible to easily implement new reusable constraints without the need for a validator per constraint. It will let you choose where to implement validation logic and allow you to target not only types but also fields.