Coming Up for Air

Book Review: 50 Android Hacks

Cover50 Android Hacks by Carl Sessa is, as you may have deduced from the title, a collection of 50 tips and tricks to help Android developers of all skill levels handle a variety of problems. For the most part, I found the book very helpful. Before I get to that, I have a minor quibble: I’m not sure "hacks" was the best choice of words. I understand the marketing aspect of it, but when I hear "hack", I think of a piece of code I’m embarrassed to share with someone else, of something I’d prefer to hide. These "hacks" seem anything but. Clean, clear, efficient, something to be proud of. It’s a minor quibble, of course, but there it is. :)

The book itself is pretty easily laid out. If you’ve read a "cookbook", then you should be comfortable and familiar with the basic layout. Each chapter is a different tip, which range from the "easy" (e.g., centering text in a view) to the more advanced (e.g., using the SyncAdapter). The topics covered include layouts, animations, build tools and more.

I read this, appropriately enough, using the Kindle App on my Android tablet, and the experience was very good. I’ve read several programming books on my tablet, and they usually have issues with unreadable source code, large blanks due to content flow issues, etc. Some of this is affected, of course, by the font size and is fixable, but I saw none of those issues here. All of the source, both XML and Java, were neatly formatted and readable, with no odd, jarring line wrap issues. The graphics were crisp and readable, and the pages were neat and clean.

This is a great book, especially for beginning to intermediate Android developers, but I’d wager that there’s something here for just about everyone.

CLI Libraries Compared

I recently ran across a couple of pretty cool libraries for creating command-line tools: Airline from the Airlift project, and crest from Tomitribe. Having spent the last few years working on administration for GlassFish, this is an area near and dear to my heart, so I thought I’d cobble together a quick example using each to see how usable they are.

Integrating Bitbucket and Jenkins

If you’re like me, you have your source code hosted in a hosted environment (such as Bitbucket), but you have a local continuous integration server (such as Jenkins). It would be really nice if you could have Jenkins build your project every time you commit, but without the heavy requirement of polling your repo. In this post, I’ll show you how to integrate the two to do just that.

Android Lifecycles

I’ve been getting a number of bug reports from my app Cub Tracker that had me stumped. I was getting NullPointerExceptions where I shouldn’t be. After some digging, I think I finally found the culprit: device rotation. While rotating the device does, indeed, trigger the error, it goes deeper than that. My problem is that the app doesn’t correctly save the state of the view, which becomes problematic when, for example, the device is rotated. In trying to fix that, I discovered I don’t understand the Android lifecycle as well as I should, so I set out to fix that.

Merry Christmas

As is my custom, I want to thank all of my readers, especially those who have joined the discussion, and wish you all a merry Christmas. In all the hustle of the season, it is my hope and prayer that the joy and peace brought to us in the person of Jesus Christ will be an ever-present blessing in your lives.

Import Maven Artifacts to Ceylon Repos

In trying to come up to speed on Ceylon, I’ve run into some issues with module import dependencies. I’m pretty sure they’re all pilot error, but it was suggested that I import the jars into the Ceylon repository and specify the dependencies between the modules. This would, effectively, be functionally the same as the <dependencies> element in the Maven POM. In classic geek, over-engineer-the-solution fashion, I cobbled together this shell script. It could be more elegant, but it seems to work, and it was much simpler than a Java implementation using the Maven APIs. :)

Ceylon: a First, Quick Take

Last week at Devoxx, Red Hat announced the release of Ceylon 1.0, "a modern, modular, statically typed programming language for the Java and JavaScript virtual machines." A fan of learning languages, I started taking the tour. In no particular order, and without any lengthy rumination, here are my initial thoughts on the language.

Awestruct NetBeans Plugin

Several weeks ago, I posted blurb about a JavaFX project I had cobbled together, DoctorFX. It is an effort to build a semi-graphical editor for Asciidoc, but it is, currently, very basic. I had some spare time last week, so I decided to add some features to it. As I thought about what needed to be added and what that would require, I thought that, perhaps, an architectural change was warranted. With some time and an itch, I pulled out the sledge hammer and out came a NetBeans plugin. This plugin though, does more than Asciidoc: it offers full(-ish) support for the Awestruct framework.

There are a lot of features I’d like to add still, but, currently it supports only basic project loading and editing. It technically has code to preview Asciidoc files, though I’m having issues getting the rendered page from displaying. (In case you want to take a crack at it, that code is here.) I’d also like to add preview support for Slim and Haml, but that may have to wait a bit.

If you’d like to lend a hand to the effort, you can find the current source on Bitbucket.

This is, of course, a bit heavier than DoctorFX, but most of my work with Asciidoc is, currently, in the context of Awestruct, so this fits my needs better, and it was fun dipping my toes into the NetBeans Platform API. :)

Gradle Tip: Running a Single Test

Using Maven, to run a single test (class), you would issue mvn -Dtest=MyTest. Gradle has similar functionality (gradle -Dtest.single=MyTest), though it seems to be much more powerful. You can get all the details here.

Gradle Tip: Better Test Debugging

In a recent post, I showed how to attach a debugger to tests run from the command line via Gradle. While it worked, it turns out that it’s a bit over kill. Try this instead:

$ gradle -Dtest.debug test
:compileJava
:processResources UP-TO-DATE
:classes
:compileTestJava
:processTestResources
:testClasses
:test
Listening for transport dt_socket at address: 5005

Attach your debugger to port 5005, and off you go. No need to modify your build. Kudos to the NetBeans debugger output for helping me find that. ;)

Gradle Tip: Seeing Standard Streams During Tests

I’m not a real big fan of using standard out as a debugging strategy (I prefer an IDE and break points, for what it’s worth), but there are times when it’s either necessary or just convenient. The standard Gradle configuration, though, makes this a bit more difficult than it probably should be. Fortunately, Gradle also makes it easy to change:

build.gradle
test {
    testLogging.showStandardStreams = true
}

If you’d like to make this change globally, that’s also easy:

~/.gradle/init.gradle
allprojects {
    tasks.withType(Test) {
        testLogging.showStandardStreams = true
    }
}

Gradle Tip: Attaching a Debugger

Maven offers a nice script to allow for attaching a debugger to your build, mvnDebug. Gradle does not. Again, though, Gradle makes it pretty easy to add this to your build.

Filtering Mail using JavaMail

At the Lee House, we have an email problem: there’s just too much of it. Over the years of signing up for contests, coupons, and other things, we seem to have amassed a giant number of subscriptions to various lists, which gives us a lot of (usually) junk email. The simple solution, of course, is just to unsubscribe, but some of those are actually occasionally useful. Throw in a pinch of proscratination and laziness, and, well… it all just keeps coming. Email clients can help manage this by providing email filters to move these emails out of the inbox, but, in the case of Thunderbird, there are only so many rules you can add to one filter, so you either create multiple rules, or give up trying. Several months back, I moved these rules to a perl-based system, but, thanks to a hard drive crash, I lost all of those. Rather than rebuild that setup, which had its own limitations, I did what every good geek would do: I wrote my own, and here it is. :)

Building "Fat Jars" with Gradle

Sometimes, such as when building command line Java apps, it would be nice to bundle all of the app’s dependencies in a single jar so that the user need not collect and manage these. With Gradle, that can be easily accomplished with the following lines:

build.gradle
jar {
    from {
        configurations.compile.collect {
            it.isDirectory() ? it : zipTree(it)
        }
        configurations.runtime.collect {
            it.isDirectory() ? it : zipTree(it)
        }
    }
}

When you run gradle assemble, you should find your now very hefty jar in build/libs.

WebJars and JSF

WebJars, for those that haven’t heard, is a project that takes popular client-side web libraries and packages them in JARs to make their use in Java-/JVM-based web apps simpler. The web site notes that you can easily see which libraries a project is using simply by looking at its dependencies, and that transitive dependencies automatically appear. It’s a pretty compelling project, but, for some reason, it doesn’t show how to integrate it with JSF. I’d like to think it’s because it’s so trivial, but I’ll show it here anyway. :)

Gradle, 'provided' scope, and Java EE 7

Maven has a dependency scope, provided, that indicates that the dependency should not be in the archive. Gradle does not provide such a scope out of the box, but it’s easy enough to add. The following Gradle build demonstrates a very bare-bones Java EE 7 web application setup:

build.gradle
apply plugin: 'war'

repositories {
    mavenCentral()
    mavenLocal()
}

configurations {
    provided
}
sourceSets {
    main { compileClasspath += configurations.provided }
}

dependencies {
    provided 'javax:javaee-api:7.0'
}

Quotes

Sample quote

Quote source