Many, many tools perform static analysis on code. There are all sorts of automated ways to look through your code and tell you if there are likely errors or not. FindBugs, PMD, and CheckStyle are some of the big names from the Java world. On the Groovy side we have two real options: IntelliJ IDEA and CodeNarc.

This post highlights my favorite static analysis rules for Groovy in IDEA that are not enabled by default. Groovy in IDEA 11 has well over 100 rules, but less than half of them are activated when you install the product. To turn these rules on you’ll need to go into Settings (Ctrl+Alt+S) and enable them under Inspections.

So here are my favorites that I think you should turn on:

Threading
Threading comes first because these inspections have saved my butt in the past. None of them are enabled by default, so do yourself a favor and enable a few. These ones are all must haves:

* Access to static field locked on instance data – Reading and writing a static field from multiple threads is not thread-safe. It needs to be done within a synchronized block. Do you know what happens when you synchronize on instance data, like this:

class MyClass {
    static resource
    final lock = new Object()

    def initialize() {
        synchronized(lock) {
            resource = new Resource()
        }
    }
}

* Synchronization on non-final field – If you are accessing a variable within a synchronized block then your synchronization token must be final. Consider this code:

class MyClass {
    def resource
    def lock = new Object()

    def initialize() {
        synchronized(lock) {
            resource = new Resource()
        }
    }
}

* Synchronization on variable initialized with literal – Do you understand the problem with synchronizing on a primitive literal? Consider this code:

class MyClass {
    def lock = 'my lock'

    def initialize() {
        synchronized(lock) {
            // do something
        }
    }
}

* Unsynchronized method overrides synchronized method – In some limited circumstances you may actually want to override a synchronized method with an unsynchronized one. But probably not. More than likely you don’t even know and you are accidentally creating a subtle bug. If the parent is synchronized then the child should be also. Or better yet, make the parent final.

Probably bugs
* Named arguments of constructor call – This inspection warns you when something like the following happens when using named arguments, which is almost certainly a bug:

class Order {
     int orderId
}

new Order(orderid: 5)

* Access to unresolved expression – There has been a lot of talk over the years about adding static compilation to Groovy. Some people want to be warned by the compiler or in the IDE if their Groovy code is referencing an object that does not exist. For example, they’d like this to produce a warning or error:

def c = { parm ->
    println it
}

Control Flow
There are many features in Groovy that simplify standard and verbose Java code. Two of these are the Elvis operator and the Null-Safe Dereference. IDEA contains inspections to help you migrate to the new way of writing code with these features.

* Conditional expression can be elvis – This inspection migrates you from code like this:

def x = value != null ? value : 2

def x = value ?: 2

* Conditional expression can be conditional call – This inspection promotes the use of the Null-Safe dereference. This following code produces a violation:

def x = value != null ? value.toString() : null

def x = value?.toString()

* If statement (or conditional) with identical branches - I periodically refactor code and accidentally leave an if or conditional statement with identical branches. These are of course redundant and can be cleaned up by removing the if expression. If you have good unit tests and use automated refactorings then this sort of things happens from time to time. The cleanup reminder is nice.

Error Handling
* Unused catch parameter - My favorite Error Handling inspection is ‘Unused catch parameter’. Consider this code:

try {
    doSomething()
} catch (e) {
    LOG.error('unexpected error occurred')
}

Validity issues
* Duplicate switch case – Groovy has Switch on Steroids, meaning you can put almost any object in the case statement, including regular expressions:

switch (input) {
    case ~/[0-9]/ : println 'numeric!'; break
    case ~/[0-9]/ : println 'a number'; break
}

Naming Conventions
Lastly, there are a whole bunch of naming convention inspections that you can activate and configure. If you’re not using CodeNarc (why not?) then you should at least activate some of these. Standards, on a whole, are good to adhere to.

IDEA Inspections of CodeNarc?
So which should you use, IDEA or CodeNarc? These two tools complement each other. There is good reason to use both CodeNarc and IDEA together. CodeNarc does have more inspections than IDEA, but the IDE integration in IDEA is better. Pressing Alt+Enter typically rewrites the offending code, and the speed of the actions are much better in IDEA. Also, the static analysis rules do not overlap between the products because the CodeNarc developers (that’s Chris Mair and myself) already use IDEA and made a conscious effort not to duplicate anything.

And if you do want to use CodeNarc and IDEA, then you might try out the CodeNarc IDEA plugin.

If you like this then you might check out some of my other IDEA related posts: The 10 Best Inspections You’re Not Using (in Java), or the IDEA archive on my blog and the Canoo blog.

And remember if you need Groovy and Grails help, then give us a call or drop me an email at hamlet.darcy@canoo.com

Google’s Android site has some fairly detailed instructions for testing Android applications… from Eclipse. They were nice enough to supply a “Testing from Other IDEs” page, but that is nothing more than instructions on using Ant and the command line. Well, if you are using IntelliJ IDEA then you already believe the IDE is going to be a better tool than Ant for this. It’s easy to set up a test project in IDEA and get your tests running. Here are some simple instructions.

Prerequisites

This tutorial assumes you have installed IntelliJ IDEA and an Android SDK, and also created an Android project. If you haven’t yet, then you should read Testing Fundamentals accessible from Google’s Testing Home page.

Creating a Test Project

Your Android tests are going to be placed in a separate module from your main Android application. Remember: an IDEA project is composed of several modules. We’re going to have the main application module and the test module. Each module has it’s own set of dependencies and classpath. (Eclipse users confused about the terminology should read this). Here are the steps to follow to set up a test project:

1. Have your main project open in IDEA
2. Create a new module using the menu File->New Module
3. Select “Create module from scratch” and click Next
4. Select “Android Module”, give the module a new name, and click Next. You should put the module in a directory called “tests” that is in your project root. That way your project will follow the same naming conventions that Ant expects, making the project easier to set up in a CI server later. Here is what your wizard screen might look like:

Adding an Android Testing Module

5. On the next wizard step just click Next to create a source directory for your files.
6. Finally, on the last wizard step select “Test” under Project properties. Make sure it is going to test your module. Then Finish.

Select Test as Project Type

At this point your two modules exist: the production module and your test module. If you look in the Project View (Alt+1) you will see both modules. Mine are named “android-testing-in-idea” and “tests”. You’ll even be given a template test for your main activity. It’s pretty slim so you will certainly want to write some of your own tests. IDEA isn’t smart enough to automatically create the test content for you… at least yet.

Running Tests

Running tests is simple. A run configuration to run all tests was created for you when you added the project. Click the ‘run triangle’ to run the tests or the ‘bug triangle’ to debug the tests. You’ll be prompted to select an emulator if you don’t have one set by default.

Click to Run All Tests

There are other ways to run tests at a more granular level, too. To run all the tests in a package, right click the package and select Run (Ctrl+Shift+F10). To run all the tests in a class, right click the class and select Run (Ctrl+Shift+F10). You can also run individual test methods one at a time. Just right click inside the test method within the IDE editor and select Run (once again, (Ctrl+Shift+F10)).

You may want to switch the emulator version from time to time in order to test across multiple devices. You can bring up the Run Configuration from the drop down menu highlighted in the screenshot above. It opens a screen like this where you configure the run target:

Configure the Test Run Target

You can switch the emulator here to a different version. Be sure to check out the other tabs as well. The Emulator tab allows you to configure the network speed and latency, and the Logcat tabs lets you configure one or two things about Logcat. Handy.

Viewing Results

So you want to view the test results? Well results window probably popped up on screen after you ran the test. Anyway, if you’re still confused you can click the Run (Alt+4) or Debug (Alt+5) drawer and see the JUnit results. There is also a Logcat drawer to click (sorry no shortcut) to view the logs.

Viewing Test Results

Other Tools

The last thing you need to know is a little about the other tools. You can manage your emulator ROMs using the AVD Manager. The menu option for that is Tools -> Android -> AVD Manager. Also, you can change the project compatibility to be a different version of Android OS. It’s under File->Project Structure (Ctrl+Alt+Shift+S) then click Module SDK. Finally, if you want to set the project up for continuous integration then head on back to the Ant command line guide from Google. It’s best not to have the IDEA project file drive your builds.

You made it to the end. Thanks for reading! And remember, Canoo is here to help with your Android and Mobile needs. Email me directly (hamlet.darcy@canoo.com) or give us a phone call. Thanks.

IntelliJ IDEA 11 was released a few weeks ago, and it contains quite a few new features for the Groovy developer. Everything listed here is in the free and open source Community Edition of IntelliJ IDEA. There are plenty of new Grails features as well, but I wanted to separate out the Ultimate Edition features into a different post. So let’s jump in.

Groovy 2.0 Support

The big promoted feature of IDEA 11 is the Groovy 2.0 support, which is itself mostly Java 7 support. In case you’re confused: Java 7 added some small language feature to Java (more here), and Groovy naturally supports the same syntax. The Project Coin Java changes are by definition small language changes, so don’t expect anything too major in terms of productivity boosts.

The first feature is underscores in numeric literals:

assert 1000000 == 1_000_000 : 'How awesome is that?'

Do you really need an explanation of this? OK, here it is then. You can put underscores into numbers and the compiler rips them out. They are just ignored. Just look at the .class file in a decompiler if you don’t believe me.

The second feature is binary literals:

assert 0b1001_1001 == 153: 'mind == blown'

This lets you specify integers using a binary format. As far as I can tell, this is mostly used if you’re constructing bit-masks to represent multiple states within one integer. You know, you could also use objects to do that and it might be clearer. But there are always times when you need this.

The third feature is multi-catch, which is the most useful feature of the three:

try {
    takeArrowToKnee()
} catch (InjuryException
     | LowHealthException
     | LowStaminaException e) {

    becomeTownGuard() // retire to a simpler life
}

This lets you catch multiple exception types in one catch block. In Java, you can Alt+Enter on an old-style catch to convert it into a multi-catch, but you can’t yet do that in Groovy. Don’t worry though, I created a ticket and it will soon be implemented…

Refactorings

For me the Groovy refactorings are one of the killer features of IDEA. There are a pair of nice upgrades in IDEA 11 in this area. The first is that Introduce Parameter works for closures now and not just methods. So if you start with something like this, where the literal 50 is hard-coded:

def adventure = {

    killMonsters() && collectLoot()
    if (health < 50) drinkPotion()
}

You can highlight the 50 and press Ctrl+Alt+P to Introduce a Parameter:

def adventure = { int minimum ->

    killMonsters() && collectLoot()
    if (health < minimum)  drinkPotion()
}

OK, so that is nice. A less well-known intention is the Unwrap Statement intention. Unwrap takes a statement that is wrapped in some sort of loop or conditional, and it removes that conditional. Witness:

Start with an If statement, choose to unwrap it, and you’re left with only the enclosed logic. Now that you know this trick, you will start to use it more often. It’s surprisingly useful.

Intentions and Inspections

There are also a couple of good, new intentions and inspections in 11. On the inspection side is the new “Incompatible In” inspection. You can use the ‘in’ keyword in, which is normally the inverse of ‘contains’. Using the in keyword to do incompatible type comparisons now triggers an IDE warning:

It’s a dynamically typed language, but as you can see the tools can easily catch your small type errors.

Also in 11 is my favorite intention, Convert JUnit Assertion to Assert. This converts your old-style JUnit assertion methods into Groovy power-asserts:

Just position the cursor at the method call and press Alt+Enter. And if you’re not sure why power asserts are an improvement then read this.

Also in IDEA 11 is ‘Split If’ and ‘Invert If’. We wrote these intentions ourselves at Hackergarten in Devoxx. Horray for open source! Split If takes a compound boolean operation like ‘if (a && b) { … }’ and converts it into ‘if (a) { if (b) { … } }. Invert If takes the boolean conditional in the If and inverts it. Both intentions are invoked with Alt+Enter and they are both described in more detail over at the JetBrains IDEA blog.

Besides that, the Import system got some new improvements as well. You can now use Alt+Enter to swap a qualified reference with an import, add a single-member static import, or add an on-demand static import. And my favorite: copy and paste within the IDE now carries the import statements with it. So if you copy a reference to the clipboard and paste it, then IDEA will ask you if you want to update the import statements. Whenever I switch back to a text editor I always miss the seamless import statement management provided by the IDE.

Groovy Isms

What else? Well, the IDE is now aware of @Category annotations and gives you correct code completion based on them. And you can finally specify a command line parameter when running a Groovy script from within IDEA. Hint: it’s the box marked ‘Script Parameters’:

Managing dependencies with Jars and Grapes got easier. If you annotate a script with @Grape when IDEA has always imported that dependency into the project for you. Well now IDEA removes obsolete @Grapes references when you no longer need them.

Lastly, there are many small UI improvements, such as overriding properties now have a gutter icon to show the relationship, multiple declarations on a single line now have better alignment, and pasting a slashy string now escapes the slashes. There are more as well, but they are even more minor.

Plus Grails Plus Java Plus…

And don’t forget, all the base improvements of IDEA, especially the speed improvements, will be felt in Groovy. The database UI has improved, the Navbar has improved, Git support has improved. It’s all there whether you’re in Java or Groovy. And like I said at the start, Grails has many improvements but they aren’t covered here… maybe in a later post after the holidays.

So long and happy holidays!

Need help with Groovy or Grails? Canoo Engineering offers training, consulting, and project delivery. Contact me directly at hamlet.darcy@canoo.com for more information.

Domain Specific Languages (DSLs) are often littered with the accidental complexity of the host language. Have you ever seen a supposedly “friendly” language expression like “ride(minutes(10)).on(bus).towards(Basel)”. The newest version of Groovy contains a language feature that aims to eliminate the noise of all those extra periods and parenthesis, so that your DSL looks more like “ride 10.minutes on bus towards Basel”. This article shows you step-by-step how to use Groovy Command Expressions and plain old metaprogramming to write just this DSL, and also offers advice on when, and when not, to use this new language feature.

The State of the Art with DSLs

Domain Specific Languages (DSLs) have been in vogue for a long time, and the topic has featured regularly at No Fluff shows for years now. The value proposition of a DSL rests in the idea that programmers and users benefit from expressing their desires in a language closer to English than to Java, using words suited to the problem domain rather than the programming language. The goal is not to create an entire new language, but to create a small language just big enough for users to capture their commands and intents in a more natural way than is typically possible in code.

Different languages support DSLs in various ways. Some languages make it easy to write nice, readable natural language-ish code and others do not. Over the next few pages we’ll explore the state of the art with Groovy DSLs, starting with looking at some unimaginative Groovy code, seeing how to convert into a better fluent interface, transforming it further using metaprogramming, and finally showing the full power of Groovy Command Expressions. As a sample problem, imagine trying to specify directions on how to get somewhere. By the end of the article you’ll understand how the Groovy code in Listing 1 works even though to looks almost like plain English sentences.

stand 7.minutes at busstop
ride 10.stops on bus towards Basel
stand 5.minutes at tramstop
ride 3.stops on tram towards Birsfelden

The Canvas

We’ll use the same running example through all of the exercises. So let’s start by painting out a few primitive ideas. Think of these basic building blocks as the undercoat to our DSL canvas. Thinking about your domain is always a good place to start if you’re considering writing a DSL. Think, analyze, and compare the domain to see how it should be naturally organized. If you read the example in Listing 1, you may notice a few similarities between the different lines of code. There are actions, such as ‘stand’ and ‘ride’. There are vehicles, such as a ‘bus’ or a ‘tram’. And there are locations, such as the ‘bus stop’, ‘Basel’, and ‘Birsfelden’. We’ll model the actions as methods later, so let’s skip those for now. Vehicles and Locations are fairly straightforward, so we’ll model those as Java enums, as shown in Listing 2. I’ve put them in a package so that I can do a static import on them later.

package nfjs

enum Location {
    busstop, Basel, tramstop, Birsfelden
}
enum Vehicle {
    bus, tram
}

There is also something else in common between all of the instructions from Listing 1. They all have a duration or distance, such as ’7 minutes’ or ’10 stops’. A duration is a little bit harder to model, but not much so. For sake of simplicity, we’ll just define a Duration class that represents either a unit of time or a unit of distance, as shown in Listing 3. I applied the TupleConstructor annotation to generate a set of constructors on the object, making it a little easier to work with.

@TupleConstructor
class Duration {
    int value
    String unit

    String toString() {
        "$value $unit"
    }
}

The last bit of undercoat to apply to our canvas is the Instruction object itself. Listing 1 creates a list of Instructions behind the scenes, so we’ll need to model those as well. Similar to Duration, it’s a simple data type with a few properties and is shown in Listing 4.

@TupleConstructor
class Instruction {
  String action
  Location location
  Duration duration
  Vehicle vehicle

  String toString() {
    if (vehicle != null) {
      "$action $duration on $vehicle towards $location"
    } else {
      "$action $duration at $location"
  }
}

An Instruction has an action (stand or ride), a location (bus stop or Basel), a duration (five minutes or three stops), and optionally a vehicle (a bus or a tram). Now that the undercoat is applied, let’s look at some different ways to construct these Instruction objects.

Cave Paintings

The most primitive way to create Instructions is to call the constructors of objects directly. This is hardly a DSL but at least it is an improvement over the Java equivalent. There’s not much here to be proud of, and list literals like [] and the leftShift operator to add list elements is only a slight improvement over the alternative. At least Listing 5 is rather short.

import static cmdexprs.Location.*
import static cmdexprs.Vehicle.*

instructions = []

instructions << new Instruction(
    'stand', busstop, new Duration(5, 'minutes') 
)
instructions << new Instruction(
    'ride', Basel, new Duration(10, 'stops'), bus
) 

The problems with this code sample is that there is a lot of accidental complexity: pieces of the underlying programming language bleed through and obscure the intent. In the first instance, only the words ‘stand bustop 5 minutes’ are essential to the problem of creating instructions. The other 59 of the 79 characters are non-essential complexity. A 25% signal to noise ratio is pretty poor. The classical solution to this problem (in a sense that it can be applied to Java code as well) is to create a fluent interface around Instruction objects so that the end user is shielded from these implementation details.

Classicism

A fluent interface is a way to chain method calls together in order to eliminate a lot of the noise associated with configuring data. Fluent interfaces can be created with statically compiled languages as well (like Java) and requires no special metaprogramming facilities in the host language. The trick is to be creative with method return types. Listing 6 shows the result of improving our signal to noise ration after refactoring to a fluent interface.

stand(minutes(5)).at(busstop)
ride(minutes(10)).on(bus).towards(Basel)

This is a big improvement and raises or signal to noise ratio from 25% all the way up to 75%. The only noise left in this example is the parenthesis party nestled between all the interesting bits. Hmmm, looks like someone invited a few periods along as well. We’ll do better in the next example, but let’s look at how to implement this fluent interface first.

As I said, the trick is to be creative with return types. For example, the code ‘minutes(5)’ actually instantiates a Duration object for us (Listing 7), which is then passed into the ‘stand’ method as an argument.

def minutes(int length) { 
    new Duration(length, 'minutes') 
} 

The trick is to make all of the method calls chain together. So the ‘stand’ method needs to return something that has an ‘at’ method on it, and that in turn needs to accept a Location parameter and create the actual Instruction. Technically speaking, stand is a higher-order function: it is a method that returns to you a method. Groovy’s dynamic typing and map-implemented interfaces make this a pretty simple task, as shown in Listing 8.

def stand(Duration duration) {     
  [at: { Location loc ->
    instructions << new Instruction('stand', loc, duration)
  }]
}

In Groovy, an object can be created as a Map literal using the [key: value] syntax. If the keys are Strings and the values or Closures, then that object can be treated as an object and have methods invoked on it, which is what Listing 8 shows.

At first, fluent interfaces often seem complex to implement. But after writing one or two you’ll often find it is really not too difficult. You have to think differently about how you craft an API, but in the end you can get a lot of usage and nice APIs using a fluent interface instead of metaprogramming. Let’s turn now towards bouncing some of those pesky parentheses out of the party using a little Groovy metaClass magic.

Impressionism

In our tour of DSL art, I’m calling the next technique impressionism. Like impressionist paintings, it does a slightly better job of capturing the intent than the previous example, but if you examine it closely it doesn’t seem to be much clearer than the alternatives. The motivating code is in Listing 9, can you spot the difference?

stand(5.minutes).at(busstop)
ride(10.stops).on(bus).towards(Basel)

There are two less parentheses, but an added period. ‘minutes(5)’ became ’5.minutes’. The signal to noise ratio improvement is marginal; the advantage here is that the code more closely resembles the away we speak. Nobody sticks their head over the cube wall at 12:05 and asks, “Do you want to go to lunch in minutes 5?” Instead, they say “5 minutes”, which is exactly what this code says. This is a small change to implement, and listing 10 shows that making the language support singular and plural words is just a few lines of code.

Integer.metaClass.getMinute  = { new Duration(delegate, 'minute') }
Integer.metaClass.getMinutes = { new Duration(delegate, 'minutes') }
Integer.metaClass.getStop    = { new Duration(delegate, 'stop') }
Integer.metaClass.getStops   = { new Duration(delegate, 'stops') }

What’s happening here is that we’re adding a method called ‘minutes’ and ‘minute’ onto the Integer class, and this method is creating the Duration object for us. Other than replacing the old ‘minutes()’ method with these four lines of code, there is no change to the previous example. The code all just stays the same.

The combination of fluent interface and metaprogramming is powerful. Sure, there are some issues with periods and parentheses, but overall it is a pretty big improvement over trying to call constructors and wire objects together in Java. Groovy 1.8 takes things a little bit further and leaves us with the best example yet.

Expressionism

The last example is the best. It contains a minimum of accidental complexity and Groovy bleed-through and looks almost like the English language equivalent. For fun, I encourage you to compare Listing 11 with the cave paintings listing in Listing 5. It’s quite a bit improved.

stand 7.minutes at busstop
ride 10.stops on bus towards Basel

I call this final version Expressionism, not because it relates very well to the 20th century art movement of the same name, but because it uses a new feature called Command Expressions and is the most expressive of all the examples.

So what are the code changes? You might notice that there are no more listings in this article. That’s right, command expressions are just the way code may be written now. Listing 11 showing the command expression usage and Listing 9 without the usage are functionally equivalent. ‘Stand’ and ‘ride’ are still method calls that return the ‘at’ and ‘on’ methods. As long as the code follows the follows the pattern ‘method parameter method parameter method parameter’ then it gets converted into ‘method(parameter).method(parameter).method(parameter)’. You can chain as many together as you like; Groovy won’t complain. The result is a nice readable chain of expressions without any additional effort. At the time being, Command Expressions are the state of the art when it comes to DSLs in Groovy.

Art Criticism

There are a couple of pitfalls to be wary of. Command expressions are shown here in the best possible light in order to display their power. In reality, they are also a little fragile. Any code not following the ‘method parameter method parameter’ rhythm doesn’t easily fit into the command expression pattern. The result is that you might have to twist your words a little to make them fit into this pattern, which moves it away from natural language and towards accidental complexity. Also, there is always the Groovy grammar and keywords to look out for. For instance ‘for’, ‘native’, and other keywords cannot appear in your DSL, a problem which other languages do have solutions for.

Also, it is probably best to avoid command expressions outside of DSLs. The code ‘list.collect{ … } each { … }’ looks like a syntax error to most Groovy programmers because there is a period missing before the each method call. However, it isn’t wrong and works just fine. Confusing, but correctly functioning. Currently, Groovy programmers are used to some parentheses and periods, and it’s confusing to leave them out unless you have good reason.

Create Your Own Art

Thus concludes the tour of the state of the art with Groovy DSLs. To start, Groovy fluent interfaces are a great way to organize an API and make it easy to use. While not a true domain specific language, in a low ceremony language like Groovy they can go a long way towards increased expressiveness and better signal to noise ration without resorting to programming trickery. For more power, start to use metaprogramming to fine tune the the exact API you need, and use Groovy Command Expressions when you need them. How go forth and make your next DSL a true work of art.

Need help with Groovy? Canoo is ready to tackle any challenge. Contact info@canoo.com to learn more about Groovy Training and Consulting.

Next Saturday, 3rd December, Canoo is sponsoring the Swiss installment of the Global Day of Code Retreat. It’s being held in Lugano, which is easily reachable from Switzerland or Northern Italy. The event is free, lunch is provided, and you’ll get a chance to practice your programming skills while taking part in a world-wide event that criss-crosses the globe. Sound fun? It will be. Here’s what you need to know:

A code retreat is a day long event where programmers get to practice and hone their craft. The format was created three years ago and has been used and improved regularly since then. During the day we’ll use Conway’s Game of Life to practice our design, testing, and pair programming skills. The event has a predefined format and will be facilitated by Canooie Hamlet D’Arcy. This is quite different from our Hackergartens, so you may want to read up on the format so you know what to expect. Michael Hunger has an excellent synopsis of Code Retreat up on the InfoQ website.

The originator of the idea is Corey Haines and he will be facilitating the first code retreat of the day in Australia and then flying to Hawaii to also facilitate the last retreat of the day. There is most likely a code retreat in your area, just in case you can’t make it to Lugano. Check out the map to see where you can go.

There are several sponsors for the Code Retreat in Lugano: Canoo, Ex Machina, and JetBrains to name a few. If you show up then expect to leave with some goodies as well as the free lunch. And please, if you plan on coming then be sure to register on the website so we can provide enough food and coffee.

See you Saturday!

The latest issue of the german Android360 magazine is featuring an article by our Android experts about fragmentation on the platform.

Fragmentation on the Android platform comes in several flavors.
Mobile devices in the wild can differ on their installed Android version, their screen size/resolution and their supported hardware features.
With the advent of Android tablets the platform added a new class of supported hardware to its portfolio.
The article summarizes the main does and don’t to tackle fragmentation successfully.

If you are experiencing fragmentation problems in your Android project or want to avoid them upfront, talk to us. Our share-a-canooie service might be just the right thing for you.

Remember: think Android, think Canoo

My grandfather used to say: “Makkelijker gezegd dan gedaan” (easier said then done). So when I talked about how HTML5 could be the new platform in-depended development paradigm, in this previous post, I better come with some real world examples instead of only saying it.

So that is exactly what I’ve been doing. My wife is a bit of an apple fan woman. And she has a book that she would like to publish. She couldn’t find a publisher, so the next best thing would be to put her book on an iPad, but you still need an publisher to put something on the iBook store and publishers are still stuck in the dark ages. So we’ve decided to make an application out of her book. Now I’ve written some objective-c code before and I must say it wasn’t the best experience I’ve had. Xcode at that time was awful, it was like writing software 10 years ago. So I started to look for alternatives. It could be a simple html page, but how to create a native iPad application out of that?

I’ve found something that I’m really exited about. Playn is a cross-platform game abstraction library for writing games that compile to multiple platforms one of these is html using gwt. Now if I use this in combination with phonegap then I can create a iPad app that can also run on android based pads. Not only that I could make it interactive add a game to the book and best of all do it in Java.

If you think about it, for companies this makes a lot of sense. Unless your companies key platform is iOS, having developers in-house that have objective-c knowledge is expensive. Also hiring external company to build an iPhone app is expensive and they have to work together with you to integrate your existing architecture. So having something like this where one can use existing knowhow to create a android and iPhone solution that works on both platforms is a huge cost saver.

Earlier this month I switched from writing my Android projects in Eclipse to writing them in IntelliJ IDEA. Overall the experience has been great, and I much prefer using IDEA to Eclipse for Android development. And now that IntelliJ IDEA 11 EAP (Early Access) has a visual layout window, there is almost no reason for me to write my Android apps in anything else. I wrote this post to help other users along their way when converting between the IDEs.

Why IntelliJ IDEA for Android?

There’s no need to ask why if IDEA is already your favorite IDE or if your company is forcing you to use it. But just in case you’re not already a raving fanboy, here are some of the features specific to Android that made me want to switch.

Find usages (Alt+F7) is aware of Android XML resources (and the semantic meaning of their content), so searching across project assets is easier. Plus, I just find IDEA’s search capabilities a little saner than Eclipse’s. Below you can see what happens when I search from within my layout XML file for a certain widget ID:

Find Usages in IDEA

Because IDEA knows about the Android XML resources, refactorings like Rename (Shift+F6) work across Java code and XML. You can rename a widget’s ID from the XML file and have the Java code updated, or rename from the Java code and have the XML updated. Here I am renaming a widget ID in XML. Nice. In general, I do not search within comments and Strings because it is a little too aggressive.

02. Rename Refactor

There are several Android specific intentions that make life easier in IDEA. Intentions are the quick-fixes that are activated in Eclipse with Ctrl+1. In IDEA you use Alt+Enter. For example, if there is a static String referenced from your code then you should make that String a resource by moving it to strings.xml. Put your cursor into the String, press Alt+Enter, accept the name suggestion, and you’re ready to go. Ctrl+Z for undo on refactorings work great, too. One of the big differences between IDEA and Eclipse is refactoring support. In IDEA, the source files do not need to compile in order for refactorings to work. It is quite common to have a broken file and fix it through a couple automated renames or refactors.

03. Move Refactor

Finally, before IDEA 11, the killer feature for Eclipse Android was the visual editor for XML based layout files. Personally, I don’t often use drag and drop layout editors but I do value seeing my code changes immediately without recompiling and redeploying. Eclipse had the better feature set. But IDEA 11 now has a layout “Preview” mode. Make a change in the XML and see it immediately updated in the preview. You can also quickly change the theme, preview in landscape and portrait, switch to night mode, and select different screen sizes. If you absolutely need a visual editor, then Eclipse is the way to go. Otherwise, the Preview in IDEA 11 is good enough. More info available on the IDEA blog.

04. Visual Preview

Let’s get started with a tour of IDEA.

Getting Oriented in IDEA

The basic layout of IDEA is not all that different from Eclipse. You have a main code window (right, in image below), you have a Project View (upper left), and you have a Structure View (lower left). If there is a window for it in Eclipse, then there is probably a window for it in IDEA. A good way to get started and get familiar with IDEA is to read the DZone IDEA RefCard I wrote a few years ago. It is still relevant today. I highlighted the image to show the relevant details.

05. Project View

At any time you can jump to the code window by pressing Escape, and you can close any open tool window with Shift+Escape. On thing that IDEA does not have is perspectives. Maybe you love Eclipse perspectives. Maybe you love when your code view shrinks up into a postage sized porthole whenever you launch a debugger. Who knows, perhaps this is useful to you somehow. I am trying very hard to be positive here, and the nicest thing I have to say about perspectives is that I hate them. Another thing IDEA does not have is a “Team Plugin”. There is no single “Team” abstraction that somehow fits on top of every version control system. Instead, when you enable Subversion then you use Subversion features. Git uses Git Features. Version control systems are enabled using the Tools->Enable Version Control menu item. Then the Alt+9 shortcut brings up the Version Control View.

Running, Debugging, and the Android Tools

Running and Debugging an application is slightly different in IDEA than in Eclipse. You manage your “Run Configurations” using your Run/Debug dropdown menu at the top of the screen:

06. Run/Debug Configurations

You can create temporary and permanent run configurations. Right clicking a test and choosing Run creates a temporary run config. If you want to run the target repeatedly then just save it so it is permanent. And you Maven users: you can right click a goal in the Maven view and create a run target, such as a run:jetty goal. The Maven support is amazing in IDEA, so you are actually lucky to be a Maven user in this case.

The features of the debuggers are fairly close between the two products. Set a break point by clicking in the gutter (Ctrl+F8), select and right click a reference to add to the watch window. I’ve noticed that Eclipse users love to enable and disable breakpoints rather than just set and remove them. Well, you can press Ctrl+Shift+F8 to manage all your breakpoints if that’s the sort of thing you like to do. Also, notice the Logcat tab on the debugger, which shows you the Android log. If you are Running (and not debugging), then the Logcat output is in the “Android Logcat” view that you see on the bottom toolbar:

07. Debug Window

The main Android Tools from the SDK are available under the Tools->Android menu. You can export a signed package this way and also launch the AVD to manage your emulators and environments. If you need the other SDK tools like “hierarchyviewer” or “monkeyrunner” then you’ll have to launch them from the command line. There is built-in Android testing support in IDEA, and when you run a unit test then the IDE will ask you whether to run it as a JUnit test or an Android test. It remembers your answer, so if you make a mistake then just delete the run configuration and start over. It will ask you again.

Managing Your IDEA Project

The two hardest parts of switching IDEs is Project configuration and Web Server configuration. Luckily we avoid the latter in an Android tutorial. But you still need to set up the project. First, some terminology. An “Eclipse Workspace” is an “IDEA Project”. An “Eclipse Project” is an “IDEA Module”. An Eclipse Workspace is composed of several projects. An IDEA Project is composed of several modules. If you have Eclipse project files then IDEA should be able to import them with no problems, and this is the fastest way to get started.

The Project is configured using the File->Project Structure menu item. You can also open the window using the Ctrl+Alt+Shift+S shortcut, which I call the Paw Mash because holding your left hand like a bear paw and mashing the keyboard usually suffices to open the window. This is where you specify your source folders, your SDK version, and your dependencies. If there is no Project SDK selected in the dropdown list, or if the list shows an error, then click on the SDKs item in the left side pane to create a new one.

08. Project Configuration

Configure the modules by clicking the module entry on the left side. Here you can mark certain folders as source or as tests. By default, a fresh IDEA Android project has no “tests” folder, so you should add the folder and then come in here as mark it as Test Sources. You can also change some of the Android compiler settings by clicking the Android facet shown in the middle.

09. Module Configuration

One last thing to configure before leaving the window. If you are writing JUnit tests then you’ll need to add JUnit to your project dependencies. If you just annotate a method as @Test then IDEA prompts you to add the junit.jar to your classpath. The problem is that they add it as the last dependency, which causes the test to fail with the error “java.lang.RuntimeException: Stub!”. Come into this window and move JUnit up in the dependency list. Or configure Ivy/Maven/Whatever to do this automatically for you.

10. Module Dependencies

That’s the quick tour of Project Structure… lets move on to Settings. Settings are the options not directly related to compiling the project. Things like code style, version control, plugins, and much more. Open Settings using File->Settings or use your Claw Attack to hit Ctrl+Alt+S. I call this shortcut the claw attack because if you pinch your left hand into an eagle claw and swoop it down on your keyboard then the Settings window usually opens right up. It helps to let out a mighty, “Ka-KAW” when you do it.

There are thousands of settings in here. I heard the advice recently that new users of either IDE should spent a few hours just clicking around the settings page, and I honestly think that is pretty good advice. If you know what you’re looking for but can’t find it, then enter your search term in the upper left side search box and the settings list dynamically displays only those pages with matching entries. For instance, if you know you want to show line numbers, then type in Line or Line Numbers and click through the resulting pages. In this case, the highlighting you see in the image was created by IDEA and is used to point you to the correct setting.

11. Settings Configuration

You most definitely want to change some of the default settings. Showing Line Numbers is under Editor->Appearance. Changing your tabs and space settings are done on a per-file type basis, and is accessed from Editor -> Code Style. By default IDEA allows you to place the cursor past the end of the line in a text file, and you turn this off under the Editor page. And Version Control is something you really must configure as well, which is under Version Control. GitHub integration in IDEA is tip-top and goes beyond just Git support, but lately I’ve been using and recommending BitBucket for free, private git hosting. In general I find myself using the IDE to make local commits and manage changelists, and the command line to perform pushes.

Links

That’s it! There are tons of ways to learn more, and here are my favorite links:

• IntelliJ IDEA RefCard from me
• IDEA Shortcut Wallpaper from me again
• JetBrains’ IDEA Q&A for Eclipse Users
• 10 Hints for Moving from Eclipse to IDEA from me
• All of my IDEA Related Blog Posts
• All of Canoo’s IDEA Related Blog Posts
• My Other Videos on JetBrains.tv
• IDEA Keyboard Stickers, so you can learn the shortcuts
• And last, you could try reading the manual

As always, feel free to keep in touch by leaving a comment. You can read more from me on my blog at http://hamletdarcy.blogspot.com/, see my YouTube channel for more screencasts, and follow me on Twitter: @HamletDRC

Opinions expressed in this post are totally my own and not necessarily that of my employer.

Wednesday started with the infamous “scriptbowl”, a competition between various scripting languages. This year the contenters were JRuby, Groovy, Scala, and Clojure. I wondered whether Scala considers itself a scripting language but obviously they either do or just seek the opportunity to be on stage.

To keep a long story short: Groovy has won this event for the third time in a row! This year the race was tied with Scala. Guillaume presented Groovy in the typical Groovy-idomatic style and explained every single line of his concurrent visual analyzer for Google+ postings. Dick Wall presented only non-idomatic Scala code. I interpret this as: to make Scala appealing you have to make it look like Groovy. Furthermore, he presented Kojo, which is a great interactive learning environment written in Play/Scala. In contrast to all other presentations, this was not specifically created for the scriptbowl, nor was it written by the presenter, nor was it clear how much effort went into it, nor did the audience see a single line the implementation code. How much this skewed the comparison, I leave to everybody’s judgement. The show was good, though.

I felt a bit sorry for Clojure. It is a great language and deserves a presentation that is more visually appealing to convince the crowd.

Afterwards, I attended a hands-on lab for “rapid enterprise development with netbeans”, which was essentially creating a Swing app for database CRUD actions. If I remember correctly, I did the exact same task 1997 with JBuilder. It left me with the feeling of “Yes, it works” but it is not less complex than it was 13 years ago.

Early afternoon Gerrit Grunwald (better known as @hansolo_) presented his work on simplified custom components for Swing. Given that he speaks about an activity that is both utterly important and highly underadvertised he would really deserve speaking at the center stage.

Graeme Rocher’s great session about Grails, polyglot datastores (hibernate, jpa, redis, mongodb, …), and the cloud was overshadowed by the news that Steve Jobs has died. Accidentally, the demo application was about showing a BBC News stream, which displayed this information live on stage. Both the presenter and the audience were equally touched.

The day officially ended with a big event at treasure island. I decided to not go there, though, and meet the former Canooey Denis Antonioli in Berkely where we had a great evening.

Dierk Koenig