Including custom Flume components in Cloudera Manager

I'm currently working on a Hadoop project using Cloudera's stack. We're running a couple Flume jobs to move data around our cluster. Our Flume Metric Details page in Cloudera Manager looked like this:

screenshot

You could infer from the image that we run a BarSource alongside our FooSource and BazSource and you would be correct. However, it doesn't show up in Cloudera Manager. Why not?

Read more →

Android Resource Configuration override and Large Text Mode

In Android, the resource Configuration dictates what resources and assets are selected. The system populates a default configuration to match your device and settings (screen size, device orientation, language). Sometimes, you need to deviate from these defaults. Since API 17 you can use applyOverrideConfiguration(Configuration) to specify an alternative resource config. The normal place to do so is in the attachBaseContext(Context) method of your Activity.

public class MainActivity extends Activity {

@Override
protected void attachBaseContext(Context newBase) {
    super.attachBaseContext(newBase);
    final Configuration override = new Configuration();
    override.locale = new Locale("nl", "NL");
    applyOverrideConfiguration(override);
}

//...

}

Here's what that looks like:

Screenshot Screenshot

Unfortunately, there's a catch.Read more →

Using Intent extras with Espresso Rules

The android-test-support library has ditched the ActivityInstrumentationTestCase2 base class for a cleaner approach using JUnit4 rules. This is nice and clean, but te documentation is currently lacking on how to proceed if your Activity requires Intent extras to run. This post demonstrates how to make that work.

Read more →

The LGPL on Android

My client had me code review an Android app built for them by a third party. As part of my review, I checked the licensing terms of the open source libraries that it used. Most were using Apache 2.0 without a NOTICE file. One was using the GNU Lesser General Public License (LGPL).

My client has commercial reasons to avoid Copyleft-style licenses and so I flagged the library as unusable. The supplier understandably was not thrilled about the rework that implied and asked for an explanation and ideally some way to make it work within the license. Looking into it in more detail, I'm convinced that if you share my client's concerns, then there is no way to use LGPL licensed code on Android. Here's why I believe this to be the case.

Read more →

How to run Android Instrumentation tests with ProGuard

The app I'm working on has an extensive, automated test suite built using Instrumentation and Robotium. These are white-box tests; they know about the Java classes that make up the tested app. This means that we were unable to run the tests after ProGuarding our application. I've never seen ProGuard break any working code after setting up the right exclusions. Nevertheless, it's a bit questionable to have a huge automated test suite and not run it on the APK that we deliver to the Play Store.

ProGuard and Instrumentation Tests

One possible work-around is to use the UIAutomator framework, which does not have this limitation. There are several reason's why we couldn't: it requires API level 16 (Jelly Bean), our app supports API 8 (Froyo) as its minimum SDK version. Furthermore, we already had our test suite in place and rewriting it from scratch didn't seem like a very good use of time. Here's what we did instead.

Read more →

A better custom ViewGroup

Jerome P. commented on my earlier post denouncing the ViewHolder pattern. He suggested an improvement to the ViewGroup approach that inverts the direction of dependency between the ContactView and its layout XML file. Instead of referencing the custom class from XML, the Java code now references the layout file using a standard resource reference. This adds further type safety and it means your view class can be completely ProGuarded.
Read more →

ViewHolder considered harmful

The ListView is the most complicated, common view widget in the Android SDK. It is part of a family of widgets known as Adapter Views. These are views that use an Adapter class to mediate between the view widget and the list data it is showing.

ListView, ListAdapter and List of DataType.

The adapter's job is to prepare the views to be shown in the ListView for each element in the dataset. This tends to involve many findViewById(int) lookups, which are quite costly in CPU time. The standing Best Practices for Android dictate that adapters use something called the ViewHolder Pattern to mitigate the cost of these lookups.

Adapter classes tend to be a hotspot of smelly program code in Android, because they straddle the View and Controller responsibilities of the MVC model (1). In my part of the Clean Code in Android Apps talk at XebiCon 2013 I demonstrated why adapters get smelly, why ViewHolder doesn't help and how to use a custom view to alleviate this problem. Read on for the reprise.

Read more →

Anatomy of a Looper

There's an intersting low-level class in the Android SDK called Looper. Each app has at least one, because it powers the UI Thread. You can create Android apps perfectly fine without ever using Looper yourself, but it's an interesting thing, so let's take a look under the bonnet.

Read more →

Conditionally ignoring JUnit tests

A useful technique that I reinvent every once in a while is conditionally ignoring JUnit tests. Unit tests are supposed to be isolated, but occasionally you hit something that makes assumptions about the environment, such as code that executes a platform-specific shell command or (more commonly) an integration test that assumes the presence of a database. To keep such a test from breaking unsuspecting builds, you can @Ignore it, but that means you have to edit the code to run the test in a supported environment.

Proper Maven projects put their integration tests in a separate source folder called src/it/java and put an extra execution of the maven-surefire-plugin into their pom.xml, tied to the integration-test phase of the Maven build lifecycle. This is Maven's recommended way of setting these up. It ties in beautifully with the pre-integration-test and post-integration-test phases that can be used to set up and tear down the environmental dependencies of the integration test suite, such as initializing a database to a known state. There is nothing wrong with this approach, but it's a bit heavy handed for the simplest of cases.

In these simple situations it's easier to just keep the integration tests in the src/test/java directory and run them along with all your other tests. However, you still need a way to trigger them only when the right environment is present. This is easily dealt with by writing your own JUnit TestRunner and some custom annotations, as shown below.

Read more →

JSON shell scripting with jsawk

I previously blogged about shell scripting JSON with Node.js. In this post, I'll demonstrate how to achieve the same thing with jsawk. The way these things go, I didn't find out about jsawk until after I wrote my post about shell scripting with Node. It's good to know both :).

Jsawk, as the name implies, aims to be for json what awk is for structured plain text. It's rather useful, as it saves a lot of setup/boilerplate compared to the node.js scripts I've shown before.

Read more →