Excluding Gradle Tasks with a Name Pattern

I’ve been spending a lot of time with Gradle build files in Android projects, which probably isn’t a big surprise given that I’m working on a book called Gradle Recipes for Android (coming soon to all your better ebook stores and (who knows?) maybe an actual, physical bookstore somewhere (but probably not), but you can always get it at O’Reilly or Amazon). In one chapter, I talk about excluding certain tasks in Gradle builds, and that led me to write an interesting custom task.

Gradle builds on Android have tons of tasks, and that number goes up and up when you add new build types or flavors. For example, on a trivial Android project, asking for the list of tasks gives:

> ./gradlew tasks
Starting a new Gradle Daemon for this build (subsequent builds will be faster).
Incremental java compilation is an incubating feature.
:tasks

------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------

Android tasks
-------------
androidDependencies - Displays the Android dependencies of the project.
signingReport - Displays the signing info for each variant.
sourceSets - Prints out all the source sets defined in this project.

Build tasks
-----------
assemble - Assembles all variants of all applications and secondary packages.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles all Debug builds.
assembleRelease - Assembles all Release builds.
build - Assembles and tests this project.
buildDependents - Assembles and tests this project and all projects that depend on it.
buildNeeded - Assembles and tests this project and all projects it depends on.
clean - Deletes the build directory.
compileDebugAndroidTestSources
compileDebugSources
compileDebugUnitTestSources
compileReleaseSources
compileReleaseUnitTestSources
mockableAndroidJar - Creates a version of android.jar that's suitable for unit tests.

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'HelloWorldAS'.
components - Displays the components produced by root project 'HelloWorldAS'. [incubating]
dependencies - Displays all dependencies declared in root project 'HelloWorldAS'.
dependencyInsight - Displays the insight into a specific dependency in root project 'HelloWorldAS'.
help - Displays a help message.
model - Displays the configuration model of root project 'HelloWorldAS'. [incubating]
projects - Displays the sub-projects of root project 'HelloWorldAS'.
properties - Displays the properties of root project 'HelloWorldAS'.
tasks - Displays the tasks runnable from root project 'HelloWorldAS' (some of the displayed tasks may belong to subprojects).

Install tasks
-------------
installDebug - Installs the Debug build.
installDebugAndroidTest - Installs the android (on device) tests for the Debug build.
uninstallAll - Uninstall all applications.
uninstallDebug - Uninstalls the Debug build.
uninstallDebugAndroidTest - Uninstalls the android (on device) tests for the Debug build.
uninstallRelease - Uninstalls the Release build.

Verification tasks
------------------
check - Runs all checks.
connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
connectedCheck - Runs all device checks on currently connected devices.
connectedDebugAndroidTest - Installs and runs the tests for debug on connected devices.
deviceAndroidTest - Installs and runs instrumentation tests using all Device Providers.
deviceCheck - Runs all device checks using Device Providers and Test Servers.
lint - Runs lint on all variants.
lintDebug - Runs lint on the Debug build.
lintRelease - Runs lint on the Release build.
test - Run unit tests for all variants.
testDebugUnitTest - Run unit tests for the debug build.
testReleaseUnitTest - Run unit tests for the release build.

Other tasks
-----------
jarDebugClasses
jarReleaseClasses
transformResourcesWithMergeJavaResForDebugUnitTest
transformResourcesWithMergeJavaResForReleaseUnitTest

To see all tasks and more detail, run gradlew tasks --all

To see more detail about a task, run gradlew help --task <task>

BUILD SUCCESSFUL

That’s about 50 tasks, and I haven’t added anything yet.

Android projects also include variants, which are combinations of build types and flavors. A build type describes whether you want to use debug or release configuration or define one of your own. Flavors allow you to build multiple similar applications that vary only in look and feel or minor code changes.

For example, in my giant Hello, World example (the same one I used in my O’Reilly video courses Learning Android and Practical Android), I use just the debug and release build types, but I have three flavors: arrogant, friendly, and obsequious.

Obsequious is such a good word. I rarely get to use it, though probably for good reason. If you’re trying to remember what it means, think Dobby from the Harry Potter novels:

Obsequious-Welcome

Under those circumstances, the number of tasks increases considerably:

> ./gradlew tasks
Incremental java compilation is an incubating feature.
:tasks

------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------

Android tasks
-------------
androidDependencies - Displays the Android dependencies of the project.
signingReport - Displays the signing info for each variant.
sourceSets - Prints out all the source sets defined in this project.

Build tasks
-----------
assemble - Assembles all variants of all applications and secondary packages.
assembleAndroidTest - Assembles all the Test applications.
assembleArrogant - Assembles all Arrogant builds.
assembleDebug - Assembles all Debug builds.
assembleFriendly - Assembles all Friendly builds.
assembleObsequious - Assembles all Obsequious builds.
assembleRelease - Assembles all Release builds.
build - Assembles and tests this project.
buildDependents - Assembles and tests this project and all projects that depend on it.
buildNeeded - Assembles and tests this project and all projects it depends on.
clean - Deletes the build directory.
compileArrogantDebugAndroidTestSources
compileArrogantDebugSources
compileArrogantDebugUnitTestSources
compileArrogantReleaseSources
compileArrogantReleaseUnitTestSources
compileFriendlyDebugAndroidTestSources
compileFriendlyDebugSources
compileFriendlyDebugUnitTestSources
compileFriendlyReleaseSources
compileFriendlyReleaseUnitTestSources
compileObsequiousDebugAndroidTestSources
compileObsequiousDebugSources
compileObsequiousDebugUnitTestSources
compileObsequiousReleaseSources
compileObsequiousReleaseUnitTestSources
mockableAndroidJar - Creates a version of android.jar that's suitable for unit tests.

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'HelloWorldAS'.
components - Displays the components produced by root project 'HelloWorldAS'. [incubating]
dependencies - Displays all dependencies declared in root project 'HelloWorldAS'.
dependencyInsight - Displays the insight into a specific dependency in root project 'HelloWorldAS'.
help - Displays a help message.
model - Displays the configuration model of root project 'HelloWorldAS'. [incubating]
projects - Displays the sub-projects of root project 'HelloWorldAS'.
properties - Displays the properties of root project 'HelloWorldAS'.
tasks - Displays the tasks runnable from root project 'HelloWorldAS' (some of the displayed tasks may belong to subprojects).

Install tasks
-------------
installArrogantDebug - Installs the DebugArrogant build.
installArrogantDebugAndroidTest - Installs the android (on device) tests for the ArrogantDebug build.
installFriendlyDebug - Installs the DebugFriendly build.
installFriendlyDebugAndroidTest - Installs the android (on device) tests for the FriendlyDebug build.
installObsequiousDebug - Installs the DebugObsequious build.
installObsequiousDebugAndroidTest - Installs the android (on device) tests for the ObsequiousDebug build.
uninstallAll - Uninstall all applications.
uninstallArrogantDebug - Uninstalls the DebugArrogant build.
uninstallArrogantDebugAndroidTest - Uninstalls the android (on device) tests for the ArrogantDebug build.
uninstallArrogantRelease - Uninstalls the ReleaseArrogant build.
uninstallFriendlyDebug - Uninstalls the DebugFriendly build.
uninstallFriendlyDebugAndroidTest - Uninstalls the android (on device) tests for the FriendlyDebug build.
uninstallFriendlyRelease - Uninstalls the ReleaseFriendly build.
uninstallObsequiousDebug - Uninstalls the DebugObsequious build.
uninstallObsequiousDebugAndroidTest - Uninstalls the android (on device) tests for the ObsequiousDebug build.
uninstallObsequiousRelease - Uninstalls the ReleaseObsequious build.

Verification tasks
------------------
check - Runs all checks.
connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
connectedArrogantDebugAndroidTest - Installs and runs the tests for arrogantDebug on connected devices.
connectedCheck - Runs all device checks on currently connected devices.
connectedFriendlyDebugAndroidTest - Installs and runs the tests for friendlyDebug on connected devices.
connectedObsequiousDebugAndroidTest - Installs and runs the tests for obsequiousDebug on connected devices.
deviceAndroidTest - Installs and runs instrumentation tests using all Device Providers.
deviceCheck - Runs all device checks using Device Providers and Test Servers.
lint - Runs lint on all variants.
lintArrogantDebug - Runs lint on the ArrogantDebug build.
lintArrogantRelease - Runs lint on the ArrogantRelease build.
lintFriendlyDebug - Runs lint on the FriendlyDebug build.
lintFriendlyRelease - Runs lint on the FriendlyRelease build.
lintObsequiousDebug - Runs lint on the ObsequiousDebug build.
lintObsequiousRelease - Runs lint on the ObsequiousRelease build.
test - Run unit tests for all variants.
testArrogantDebugUnitTest - Run unit tests for the arrogantDebug build.
testArrogantReleaseUnitTest - Run unit tests for the arrogantRelease build.
testFriendlyDebugUnitTest - Run unit tests for the friendlyDebug build.
testFriendlyReleaseUnitTest - Run unit tests for the friendlyRelease build.
testObsequiousDebugUnitTest - Run unit tests for the obsequiousDebug build.
testObsequiousReleaseUnitTest - Run unit tests for the obsequiousRelease build.

Other tasks
-----------
jarArrogantDebugClasses
jarArrogantReleaseClasses
jarFriendlyDebugClasses
jarFriendlyReleaseClasses
jarObsequiousDebugClasses
jarObsequiousReleaseClasses
transformResourcesWithMergeJavaResForArrogantDebugUnitTest
transformResourcesWithMergeJavaResForArrogantReleaseUnitTest
transformResourcesWithMergeJavaResForFriendlyDebugUnitTest
transformResourcesWithMergeJavaResForFriendlyReleaseUnitTest
transformResourcesWithMergeJavaResForObsequiousDebugUnitTest
transformResourcesWithMergeJavaResForObsequiousReleaseUnitTest

To see all tasks and more detail, run gradlew tasks --all

To see more detail about a task, run gradlew help --task

BUILD SUCCESSFUL

That’s just under 100, and the problem only gets worse if you add flavor dimensions. In the book, I add client flavors — one for Wayne Enterprises and one for Stark Industries. That gives me 3 x 2 = 6 different flavors and 2 build types, or 12 different variants, with all the (nearly 200) associated tasks. Whew.

Wayne-Help

Here’s a sample of the build file, just to show what this looks like:

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.3"
    defaultConfig {
        applicationId "com.kousenit.helloworld"
        minSdkVersion 16
        targetSdkVersion 23
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        // no changes to debug type, so no need to list it here
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'),
               'proguard-rules.pro'
        }
    }

    flavorDimensions 'attitude', 'client'

    productFlavors {
        arrogant {
            dimension 'attitude'
            applicationId 'com.kousenit.helloworld.arrg'
        }
        friendly {
            dimension 'attitude'
            applicationId 'com.kousenit.helloworld.frnd'
        }
        obsequious {
            dimension 'attitude'
            applicationId 'com.kousenit.helloworld.obsq'
        }
        stark {
            dimension 'client'
        }
        wayne {
            dimension 'client'
        }
    }
}

Say I want to skip a task. For example, when I’m doing a regular build, I don’t always need to run the lint task, which gives interesting results but takes time. In Gradle, excluding a particular task from the build is as simple as using the -x flag.

That sounds good, but unfortunately there are many lint tasks:

> ./gradlew tasks | grep lint
lint - Runs lint on all variants.
lintArrogantStarkDebug - Runs lint on the ArrogantStarkDebug build.
lintArrogantStarkRelease - Runs lint on the ArrogantStarkRelease build.
lintArrogantWayneDebug - Runs lint on the ArrogantWayneDebug build.
lintArrogantWayneRelease - Runs lint on the ArrogantWayneRelease build.
lintFriendlyStarkDebug - Runs lint on the FriendlyStarkDebug build.
lintFriendlyStarkRelease - Runs lint on the FriendlyStarkRelease build.
lintFriendlyWayneDebug - Runs lint on the FriendlyWayneDebug build.
lintFriendlyWayneRelease - Runs lint on the FriendlyWayneRelease build.
lintObsequiousStarkDebug - Runs lint on the ObsequiousStarkDebug build.
lintObsequiousStarkRelease - Runs lint on the ObsequiousStarkRelease build.
lintObsequiousWayneDebug - Runs lint on the ObsequiousWayneDebug build.
lintObsequiousWayneRelease - Runs lint on the ObsequiousWayneRelease build.

Excluding lint leaves out some of them, but runs others.

> ./gradlew build -x lint | grep lint
:app:lintVitalArrogantStarkRelease
:app:lintVitalArrogantWayneRelease
:app:lintVitalFriendlyStarkRelease
:app:lintVitalFriendlyWayneRelease
:app:lintVitalObsequiousStarkRelease
:app:lintVitalObsequiousWayneRelease

I’m not sure what the “vital” part of those release tasks is, but I don’t want it. I suppose I could try excluding the tasks one by one, but that’s starting to feel like a lot of work.

Instead, I can add the following to the build.gradle file, which waits for the task graph to be assembled and then removes the undesired name pattern.

gradle.taskGraph.whenReady { graph ->
    graph.allTasks.findAll { it.name ==~ /lint.*/ }*.enabled = false
}

Gradle assembles a directed acyclic graph of tasks, available through the gradle object via its taskGraph property. By calling the whenReady method, I wait until that graph is assembled before modifying it.

The whenReady method takes a closure, whose argument is the graph. I retrieve all the tasks into a list, find all the tasks whose name matches the given regex (meaning the name starts with the letters lint), and disable them all.

> ./gradlew build | grep lint
:app:lintVitalArrogantStarkRelease SKIPPED
:app:lintVitalArrogantWayneRelease SKIPPED
:app:lintVitalFriendlyStarkRelease SKIPPED
:app:lintVitalFriendlyWayneRelease SKIPPED
:app:lintVitalObsequiousStarkRelease SKIPPED
:app:lintVitalObsequiousWayneRelease SKIPPED
:app:lint SKIPPED

This works, but it’s a permanent solution to a temporary problem. I’d rather make excluding those tasks optional. Fortunately, I can do that through a project property.

gradle.taskGraph.whenReady { graph ->
    if (project.hasProperty('noLint')) {
        graph.allTasks.findAll { it.name ==~ /lint.*/ }*.enabled = false
    }
}

Now I can exclude the lint tasks by specifying a -P flag on the command line:

> ./gradlew build -PnoLint | grep lint
:app:lintVitalArrogantStarkRelease SKIPPED
:app:lintVitalArrogantWayneRelease SKIPPED
:app:lintVitalFriendlyStarkRelease SKIPPED
:app:lintVitalFriendlyWayneRelease SKIPPED
:app:lintVitalObsequiousStarkRelease SKIPPED
:app:lintVitalObsequiousWayneRelease SKIPPED
:app:lint SKIPPED

This strikes me as a clean, elegant solution to the problem, but maybe only because I can’t think of anything easier. If you can, please let me know, because I turned in the complete draft of the stupid book this week (!!) and this is in one of the chapters. If you find an error or a better idea, there’s still (barely) enough time to update it and even give you credit (if not necessarily cashy money, though I will be happy to purchase for you the libation of your choice next time I see you).

Either way, the idea of manipulating the task graph inside the build file is a really useful one, so you shouldn’t exclude it (get it?).

Retrofitting Groovy

I’m teaching an Android development class this week, and one of our primary references is the book Android 6 for Programmers, 3rd edition, which was released last December. One of the examples in the book accesses the Open Weather Map RESTful web service and builds a UI around the results, which is pretty much the default Android developer app.

The app accesses Open Weather Map by creating an instance of the URL class, invoking openConnection on the result, and downloading the response using the resulting InputStream. It then parses the response using various classes in the org.json package, including JsonObject and JsonArray.

As you might imagine, this is a tedious way to solve the problem. Java is already verbose; adding Android makes it worse, and then doing networking and JSON parsing “by hand” is just too much. As a teaching example it’s fine, but I wouldn’t recommend that as a long-term solution.

For RESTful web services, I’ve been a fan of the Spring for Android project, which includes a class called RestTemplate that has a method called getForObject. Once you map a set of Java classes to the expected JSON response, accessing the web service becomes a simple one-liner. Much better.

The problem, however, is that the Spring for Android project is now dormant to the point of being inactive. The 1.0.1 release is dated December, 2012, and the 2.0.0 M3 milestone hasn’t changed in years. That makes me reluctant to keep recommending it to new Android developers.

Instead, the primary library for working with RESTful services in Android appears to be Retrofit, from Square. It’s very powerful and current, and the only problem is that the documentation is, shall we say, thin.

I wanted to show the students in my class how to rewrite the book app to use Retrofit instead of doing the low-level networking and JSON parsing. That meant I had to experiment with the library, which is something I’d been planning to do for years but never actually did. The good news is that Retrofit can be used in a stand-alone Java app, so I could try it out myself before worrying about the Android aspects of the problem.

As often happens, that lead me to Groovy. Most Groovy apps are combinations of both Groovy and Java, and I like to say that while Java is good for tools, libraries, and basic infrastructure, Groovy is good for everything else. While it’s unlikely I can convince my students to use Groovy in their apps (it’s a very conservative company), I could certainly use it myself during my learning process.

The book code eventually produced a Java class called Weather, used to hold formatted strings for the day of the week, the min and max temperatures forecasted for that day, the humidity percent, a String description of the weather, and a URL to an icon showing the weather (sunny, cloudy, or whatever). My goal was to use Retrofit to access the Open Weather Map API, download the resulting JSON response, convert it to classes, and then create an instance of Weather for each of the forecast days.

First I created a new Gradle-based project that allowed me to mix Java and Groovy together. Here’s the build file, showing the Retrofit dependencies.

apply plugin: 'groovy'

sourceCompatibility = 1.8

repositories {
    jcenter()
}

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.4.6'
    compile 'com.squareup.retrofit2:retrofit:2.0.1'
    compile 'com.squareup.retrofit2:converter-gson:2.0.1'

    testCompile 'junit:junit:4.12'
}

I’m using the Gson converter, which automatically converts the JSON response to a set of classes once I’ve defined them.

Step 1 in any mapping operation is to look at the form of the JSON response. Here’s an abbreviated sample, from http://api.openweathermap.org/data/2.5/forecast/daily?q=Marlborough,CT&units=imperial&cnt=16&APPID=d82ee6zzzzzzz .

{"city":{"id":4844078,"name":"Terramuggus","coord":{"lon":-72.47036,"lat":41.635101},"country":"US","population":0},"cod":"200","message":0.0156,"cnt":16,"list":[{"dt":1460044800,"temp":{"day":51.48,"min":49.69,"max":51.48,"night":49.69,"eve":51.48,"morn":51.48},"pressure":984.62,"humidity":97,"weather":[{"id":501,"main":"Rain","description":"moderate rain","icon":"10d"}],"speed":9.98,"deg":170,"clouds":88,"rain":3.8}, { ... }, ... ]}

After the basic info, there is an array of 16 JSON objects representing the data I need, one for each day. (Note: to do this yourself, you’ll need to replace the APPID with your own, which you can get at the Open Weather Map site.)

Working top down, here is the set of POGOs (Plain Old Groovy Objects) I created to map to just the few parts I needed:

class Model {
    WeatherData[] list
}

class WeatherData {
    long dt
    TempData temp
    int humidity
    WeatherInfo[] weather
}

class TempData {
    double min
    double max
}

class WeatherInfo {
    String description
    String icon
}

To use Retrofit, I did what I normally do, which is to write a Groovy script and then eventually turn it into a class. That makes it easy to integrate with existing Java classes. Here’s the class I eventually created:

import retrofit2.Call
import retrofit2.Retrofit
import retrofit2.converter.gson.GsonConverterFactory

class DownloadForecast {
    private static final String KEY = 'd82ee6...'

    private final Retrofit retrofit = new Retrofit.Builder()
            .addConverterFactory(GsonConverterFactory.create())
            .baseUrl('http://api.openweathermap.org')
            .build()

    List<Weather> getWeatherList(String city='Marlborough', String state='CT') {
        OpenWeatherMap owm = retrofit.create(OpenWeatherMap)
        String address = "${URLEncoder.encode(city, 'UTF-8')},$state"
        Call<Model> model = owm.getData(q: address, units: 'imperial',
                cnt: '16', APPID: KEY)

        model.execute().body().list.collect { WeatherData wd ->
            Weather.parseData(wd)
        }
    }
}

I made both attributes private and final because I didn’t want Groovy to auto-generate and getters or setters for them. The instance of Retrofit is created using a builder, with its fluent syntax, in the recommended manner.

The getWeatherList method takes two strings representing the city and state. I gave both defaults (cool that you can do that in Groovy, isn’t it?), so I can invoke this method with zero, one, or two arguments, as the test cases will show.

The next requirement for Retrofit is that you provide an interface with the methods you want to invoke. In this case I called it OpenWeatherMap:

import retrofit2.Call;
import retrofit2.http.GET;
import retrofit2.http.QueryMap;

import java.util.Map;

public interface OpenWeatherMap {
    @GET("data/2.5/forecast/daily")
    Call<Model> getData(@QueryMap Map<String, String> params);
}

While I could have written that in Groovy, in this case I provided it in Java, just to make the integration cleaner. The GET annotation shows that relative to the base URL I need to access the given path, and the QueryMap annotation is applied to a map of parameters used to form the resulting query string. The return type is a Call.

Returning to the getWeatherList method, I used the create method on retrofit to return an implementation of OpenWeatherMap. Then to make the actual call, I need to invoke the execute method using my map of parameters. Groovy makes that part particularly easy:

Call<Model> model = owm.getData(q: address, units: 'imperial', cnt: '16', APPID: KEY)

That uses the normal Groovy native syntax for maps. You’ll note that I URL encoded the city when assembling the address, using the normal (Java) URLEncoder class in the standard library.

Once I executed the call, I traversed to the list child element, based on the attribute name used in the JSON response. That gave me my collection of WeatherData objects.

Then I needed to map the WeatherData class to my desired Weather class, which I did through a static method called parseData in Weather.

import groovy.transform.ToString
import java.text.NumberFormat

@ToString
class Weather {
    final static NumberFormat numberFormat = NumberFormat.instance
    final static NumberFormat percentFormat = NumberFormat.percentInstance

    String day
    String min
    String max
    String humidity
    String description
    URL iconURL

    static Weather parseData(WeatherData data) {
        numberFormat.setMaximumFractionDigits(2)

        new Weather(day: new Date(data.dt * 1000).format('EEEE'),
            min: numberFormat.format(data.temp.min) + '\u00B0F',
            max: numberFormat.format(data.temp.max) + '\u00B0F',
            humidity: percentFormat.format(data.humidity / 100),
            description: data.weather[0].description,
            iconURL: "http://openweathermap.org/img/w/${data.weather[0].icon}.png".toURL()
        )
    }
}

That (almost) matches the Java Weather POJO in the book, which I populated from the WeatherData values. The last line in the getWeatherList method:

model.execute().body().list.collect { WeatherData wd ->
    Weather.parseData(wd)
}

converts the array of WeatherData objects into a collection of Weather objects and returns it.

To make sure this is working, here’s my test case:

import org.junit.Test;
import java.util.List;

import static org.hamcrest.CoreMatchers.equalTo;
import static org.junit.Assert.*;

public class DownloadForecastTest {
    private DownloadForecast df = new DownloadForecast();

    @Test  // default city,state is Marlborough,CT
    public void getWeatherList_MarlboroughCT() throws Exception {
        List<Weather> weatherList = df.getWeatherList();
        assertThat(16, equalTo(weatherList.size()));
        System.out.println("Today's weather: " + weatherList.get(0));
    }

    @Test // specify just city defaults to state of CT
    public void getWeatherList_NewLondonCT() throws Exception {
        List<Weather> weatherList = df.getWeatherList("New London");
        assertThat(16, equalTo(weatherList.size()));
        System.out.println("Today's weather: " + weatherList.get(0));
    }

    @Test // the weather has got to be better in Honolulu
    public void getWeatherList_HonoluluHI() throws Exception {
        List<Weather> weatherList = df.getWeatherList("Honolulu", "HI");
        assertThat(16, equalTo(weatherList.size()));
        System.out.println("Today's weather: " + weatherList.get(0));    }
}

I used Java to write the test, mostly to demonstrate that I can access the Groovy classes from Java without any issues. All I’m testing is that I get 16 Weather objects in the results, as I expected (because of the supplied value of the cnt parameter). The printed output shows today’s weather in each location.

Today's weather: Weather(Thursday, 77.38°F, 79.36°F, 97%, scattered clouds, http://openweathermap.org/img/w/03n.png)
Today's weather: Weather(Thursday, 46.44°F, 48°F, 90%, moderate rain, http://openweathermap.org/img/w/10d.png)
Today's weather: Weather(Thursday, 49.69°F, 51.48°F, 97%, moderate rain, http://openweathermap.org/img/w/10d.png)

The first result is for Honolulu; the other two are in Connecticut. In other words, April hasn’t really made it’s way to Connecticut yet.

Now that the system is working, the next step would be to port everything to Java and add it to the Android app, making the REST call in an AsyncTask and so on. After coding in Groovy, however, the idea of porting all that easy code back into Java is just depressing, so I decided to blog about it instead.

A Groovy approach to npm-gate

Recently the JavaScript community experienced a serious disruption when a developer removed one of his deployed libraries from the central npm server, an event now being referred to as npm-gate. I don’t want to get into the various ethical, moral, or legal issues about that here. Rather, I want to show how trivially the missing functionality can be supplied using Groovy.

The chaos came from a function known as left-pad. All the function does is take a string, a number, and a delimiter, and returns a padded string of the requested length using the supplied delimiter. Here are the examples shown on the home page:

leftpad = require('left-pad')

leftpad('foo', 5)
// => "  foo" 

leftpad('foobar', 6)
// => "foobar" 

leftpad(1, 2, 0)
// => "01"

As you can see, there’s not much to it. The implementation is pretty simple as well:

module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch &amp;&amp; ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i &lt; len) {
    str = ch + str;
  }

  return str;
}

The Groovy implementation is almost trivially easy, because the Groovy JDK already has a method in the String class called padLeft.

assert 'foo'.padLeft(5)    == '  foo'
assert 'foobar'.padLeft(6) == 'foobar'
assert '1'.padLeft(2, '0') == '01'

It’s easy enough to make a method out of this:

String leftPad(s, len, ch=' ') {
    s.toString().padLeft(len, ch.toString())
}

assert '  foo'  == leftPad('foo', 5)
assert 'foobar' == leftPad('foobar', 6)
assert '01'     == leftPad(1, 2, 0)
assert ' null'  == leftPad(null, 5)

So far, so good, plus it’s also a nice example of specifying a default parameter in a method.

Of course, providing a function like that to JavaScript developers doesn’t really help, because they can’t invoke it (easily) from JS. Might as well make it a RESTful web service, then. I made a Ratpack app and added a ratpack.groovy script:

import static ratpack.groovy.Groovy.ratpack

ratpack {
    handlers {
        get() {
            String s = request.queryParams.string ?: 'hello'
            String len = request.queryParams.num ?: '5'
            String delim = request.queryParams.delim ?: ' '
            response.send s.padLeft(len.toInteger(), delim)
        }
    }
}

All the query parameters are strings by default, but I wanted to make sure they all had values. Thus the series of Elvis operators to provide defaults. Next I went through the simple series of hoops necessary to deploy the app to Heroku, so I can access it using HTTP:

> http leftpad.herokuapp.com

hello

> http leftpad.herokuapp.com string==foo num==5

  foo

> http leftpad.herokuapp.com string==foobar num==6
foobar

> http leftpad.herokuapp.com string==1 num==2 delim==0

01

To make the HTTP requests, I’m using httpie, which is my standard curl replacement. Feel
You can use curl, or just type a URL like

http://leftpad.herokuapp.com/?string=foo&num=8&delim=x

into a browser to see the results.
Normally at this point I would make some kind of joke lamenting how so many JavaScript developers needed an online, downloaded dependency just to pad a string, but I won’t. After all, coding in JavaScript is its own punishment. I’ll just note that, yet again, Groovy made something trivial that apparently other languages have to work to do.

%d bloggers like this: