Jens Driller’s Blog

RxJava Tidbits

2016-10-30T21:48:04+00:00

I recently started a mini-series on RxJava riddles. It is a collection of tips & tricks and solutions to common, real-world problems I have come across during development.

It is published on Medium: RxJava Tidbits

How to debug a Java Annotation Processor using IntelliJ & Maven

2015-10-11T09:37:56+01:00

File this post under “stuff-I-google-repeatedly”. I’m posting this so it will pop up the next time I’m searching for it in 3 months time.

Firstly, configure IntelliJ:

Run > Edit Configurations…
Add New Configuration (Type: Remote)
Keep all defaults & Just change the port to 8000

Secondly, switch to CLI:

cd into the project’s directory
Run mvnDebug clean install

This will produce an output like this:

Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000

mvnDebug is very similar to the classic mvn command apart from the crucial difference that it will wait for a debugger to be attached to the Java process before continuing execution.

Lastly, switch back to IntelliJ:

Set your breakpoints & Run the new configuration

A new debugger session will be created and attached to the Java process on port 8000. If you switch back to the terminal, you can actually see the Maven command being resumed (i.e. logs are being printed out).

Happy debugging!

My new favourite Git feature: git rebase –-autostash

2015-07-20T20:49:27+01:00

UPDATE 14/01/16:

Git v2.7.0 is out! All you need to do now is set the following global config flag and you can simply rebase as usual even onto a dirty worktree: git config --global rebase.autostash true

UPDATE 27/10/15:

The recently released Git v2.6.0 has been taught to pay attention to your rebase.autostash configuration which enables the --autostash option by default. That means that a simple git pull --rebase is now capable of rebasing a dirty worktree.

ORIGINAL POST:

I recently stumbled upon a (in my opinion) less well-known feature of Git that’s actually been around since v1.8.4 (current version: v2.4.6).

It is the git rebase --autostash command. And it basically does what it says: Automatically stashing away changes before performing the rebase operation. Before that release, rebase would just refuse to run.

It is the equivalent to: git stash & git pull --rebase & git stash pop.

Now think about how many times you’re doing that per day. At least I find myself executing those commands over and over again to stay up-to-date with the remote origin.

So I created a handy alias for git fetch && git rebase --autostash, so I only need to run git update.

If you’re using SourceTree, you might also want to create a custom action that allows you to do the same operation with a single mouse click. Just create a new file called stash_and_rebase.sh with the following contents:

#!/bin/sh
git fetch && git rebase --autostash

You can then set it up via SourceTree / Preferences / Custom Actions / Add like so:

Baam! That’s it. And it saves me a couple of seconds every day :)

Android Annotation Processing Setup using Gradle

2015-04-20T20:36:37+01:00

TL;DR

I have created an example Android project you can use to kickstart your Java and/or Android annotation processing library based on the Gradle build system. It is also setup to easily publish the artifacts to JCenter (via Bintray) using the novoda/bintray-release plugin.

Ok, so I’ve read this article about annotation processing some time ago on Hannes Dorfmann’s blog. It’s a great article introducing you to the world of annotation processing in Java. It’s well worth reading! So make sure you check it out.

The example project that’s being created in that tutorial is using Maven as the build system. As an Android developer these days, your preferred companion for building your apps and/or libraries is (hopefully) Gradle. So let’s go ahead and see how we can produce a similar setup using the Gradle build system.

I’ve decided to create a simple annotation processor called StaticLauncher. The idea is that you can annotate any Activity with @StaticLauncher and it will generate a new ActivityLauncher class for you providing some handy, static helper methods to launch that Activity.

Here’s what it looks like - an annotated Activity:

@StaticLauncher
public class ActivityA extends ActionBarActivity {}

And the generated code:

public final class ActivityALauncher {
  public static Intent getIntent(Context context) {
    return new Intent(context, ActivityA.class);
  }

  public static void startActivity(Context context) {
    context.startActivity(getIntent(context));
  }
}

And that’s it - I guess it’s sufficient for a simple example. However, feel free to fork the repo and enhance the project to make it a truly useful library. For example, by adding support for Intent extras? :)

Ok, now this article is about the Gradle setup, so let’s have a look at the project structure:

As Hannes has already pointed out in his blog post, it’s quite common and best practice to separate out your custom annotations into a separate Java module. The main reason being that users of your library shouldn’t need to include all of your annotation processing logic and only use it for compilation.

Note that I usually name the 2nd module processor since it better describes its purpose. This time I called it compiler… because why not?

So, the contents of those modules are as follows:

api

Content: annotation definitions & potentially other, non-generated code
Dependencies: none

compiler

Content: annotation processing logic (generates the actual code)
Dependencies: api module & potentially other libraries that aid development (e.g. google/auto and square/javapoet)

sample

Content: the sample app (ba dum tss)
Dependencies: api module & compiler module as a compile time only dependency using hvisser/android-apt

For reference, here are the links to the modules’ build files:

I don’t think it’s worth going through every build file in detail. You can just checkout and browse the GitHub repo.

One more thing: If you’re using Java 8 as your SDK, you need to ensure and tell the compiler to build using Java 7 or you will get the following error during pre-dexing:

:sample:preDexDebug

UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)
...while parsing com/jenzz/staticlauncher/StaticLauncher.class

1 error; aborting
Error:Execution failed for task ':sample:preDexDebug'.

To solve this, just put the following two lines into your api module’s build file and you’re ready to go:

sourceCompatibility = JavaVersion.VERSION_1_7
targetCompatibility = JavaVersion.VERSION_1_7

Finally, to publish your annotation processor to JCenter, all you need to do is modify the ext closure of the build.gradle file in the project root folder.

For this example project, it looks like this:

ext {
  userOrg = 'jenzz'
  groupId = 'com.jenzz.staticlauncher'
  uploadName = 'Android-StaticLauncher'
  publishVersion = '0.1'
  description = 'An example project of Java annotation processing based on Gradle'
  website = 'https://github.com/jenzz/Android-StaticLauncher'
  licences = ['MIT']
}

Both submodules reference these properties, so this is the only place you need to make changes. For more info about the available properties and other usages have a look at the plugin’s GitHub wiki.

And finally, here’s how to make it available to the world:

./gradlew clean build bintrayUpload -PbintrayUser=BINTRAY_USERNAME -PbintrayKey=BINTRAY_KEY -PdryRun=false

Android Gradle workaround for missing placeholder support in resource files

2014-11-20T17:28:19+00:00

Ok, so here’s a bit more Gradle hacking.

Note that the following workaround becomes obsolete once the guys at Google add support for placeholders in resource files.

So the problem is as follows:

You have a SyncAdapter.
You have multiple build variants.

WAAAAT? Yes, that’s already enough to cause some headaches, assuming you wanna install multiple build variants side by side.

So before we’re getting right into the root of the problem, note that this article might as well take one of the following titles:

How to provide unique authorities per build variant for your SyncAdapter, AccountAuthenticator and/or ContentProvider
How to enable the ${applicationId} placeholder in <sync-adapter />, <searchable /> and/or <account-authenticator /> XML files
How to avoid the dreaded INSTALL_FAILED_CONFLICTING_PROVIDER exception

If you wonder what the exception in the last title is all about, it occurs if two apps (e.g. debug and release) are registering for the same ContentProvider.

So why is this a problem at all? Well, the authority of a SyncAdapter as listed in android:authorities must be unique. As per the official Android documentation:

A provider usually has a single authority, which serves as its Android-internal name. To avoid conflicts with other providers, you should use Internet domain ownership (in reverse) as the basis of your provider authority.

Now, for ContentProviders that are specified in your AndroidManifest.xml file this is not a problem at all. You can just use the {applicationId} placeholder as follows:

<provider
    android:name="com.example.MyApp.MyProvider"
    android:authorities="${applicationId}.provider"
    android:enabled="true"
    android:exported="false" />

Unfortunately, {applicationId} does not work in other XML resource files.

So how are we gonna fix this? Gradle to the rescue! What we’re gonna do is dynamically generate a new XML String resource file that provides unique authorities for the current build variant.

To do that, firstly, we need to tell our build script that the task that merges the resources (called mergeResources) depends on our own task which I’ve called createBuildVariantResources:

android {
	applicationVariants.all { variant ->
    	 variant.mergeResources.dependsOn {
            createBuildVariantResources(variant)
        }
    }
}

That task takes the build variant as a parameter. You will soon see why.

But first, let’s create a simple helper method that returns the application ID for a given build variant:

/**
 * @return the applicationId for the given build variant
 */
ext.applicationId = { variant ->
    def applicationId = variant.productFlavors[0].applicationId
    def suffix = variant.buildType.applicationIdSuffix
    applicationId += suffix ?: ""
}

I think this snippet doesn’t need much explanation. It grabs both the app ID and a potential app suffix from the given build variant and returns them as a concatenated String. You can put this anywhere in your build.gradle file. I usually place it outside of the Android closure at the bottom of the build script.

Now, let’s generate the resources. Note that regular Strings in Groovy cannot span multiple lines. So we’re gonna use triple double quotes to create a multi-line GString that supports interpolating variables:

/**
 * Generates unique resources for the given build variant that are used
 * by our sync adapter, account authenticator, content provider, etc.
 * The resources are based on the application id so that each build variant can be installed
 * alongside each other without causing the dreaded "INSTALL_FAILED_CONFLICTING_PROVIDER" exception.
 */
ext.createBuildVariantResources = { variant ->
    def applicationId = applicationId(variant)
    def syncAuthority = applicationId + ".sync"
    def syncAccountType = applicationId + ".provider"
    def res = """<?xml version="1.0" encoding="utf-8"?>
<resources>

    <!-- Automatically generated file. DO NOT MODIFY. -->

    <string name="application_id">${applicationId}</string>
    <string name="sync_authority">${syncAuthority}</string>
    <string name="sync_account_type">${syncAccountType}</string>

</resources>"""
	def folder = new File("${buildDir}/generated/res/generated/${variant.dirName}/values")
	folder.mkdirs()
	def file = new File(folder, "variant_resources.xml")
	file.createNewFile()
	file.write(res)
}

I think the code itself is again self-explanatory. It creates a new file called variant_resources.xml and stores it in the project’s generated values folder. I also added the application ID which you might as well obtain via BuildConfig.APPLICATION_ID.

And that’s it. You can now reference your SyncAdapter’s authority using @string/sync_authority which is guaranteed to be unique per build variant since it’s based on the current variant’s application ID.

One last note: resource-based authorities only work on Android 2.2.1 and later. This shouldn’t be a problem for you these days. minSdkVersion=15 FTW!

Also: Android Studio doesn’t yet recognize resources that are generated by Gradle. So you will see that the references from above are being marked in red and annotated with Cannot resolve symbol '@string/sync_authority'. However, this is only Android Studio moaning. You can safely ignore that. It will be fixed soon.

So this solution is obviously not elegant at all, but it does the job. For now. Consider it a temporary workaround until another update of the Android Gradle plugin will be released that fixes this problem.

5 simple Google Chrome extensions to enhance your GitHub experience

2014-11-03T12:01:00+00:00

So you’re using GitHub like your #1 social network? Here are some Google Chrome extensions that will improve your daily experience. I’ve been using them for a couple of months now and can’t imagine browsing GitHub w/o them anymore.

Note that unfortunately some of these extensions only work with public repos.

Octotree

Chrome Web Store - GitHub

A Chrome extension to display GitHub code in tree format. This adds a sidebar to the left and makes navigating projects a lot easier!

GitHub.Expandinizr

Chrome Web Store - GitHub

Have you ever noticed all the whitespace on almost every GitHub page? This extension gets rid of it and expands the content to full width. Also prevents truncation of commits. Pretty cool.

GitHub Tab Size

Chrome Web Store - GitHub

Makes tab indented code more readable by forcing the tab size to four instead of eight.

Coloured Timestamps

Chrome Web Store - GitHub n/a

Have you ever found yourself browsing around a project for quite a while only until you realize that the project is inactive for more than a year? This extension adds colour to all the timestamps in the file list. If you see a red wall on the right, the project’s probably been abandoned…

GitHub Wiki Search

Chrome Web Store - GitHub

Adds a search field to the Wiki pages. I found this to be especially useful on large projects where there are loads of different sections in the Wiki.

And finally, there’s the simple CoderStats extension which adds a link to the current user’s CoderStats page right below his avatar.

That’s it. If you know of any other cool extensions that improve your day-to-day experience on GitHub, please let me know in the comments.

Simple deserialization of Java enums using Google GSON annotations

2014-10-06T09:40:53+01:00

Here’s a little quick tip about something that I think is a less well-known feature of Google’s awesome GSON library:

Parsing Java enums using annotations

Assuming you receive a simple JSON response like this:

{
    "value": 9,
    "suit": "hearts"
}

where suit is always a lower-case String of the following fixed set: hearts - diamonds - clubs - spades

The equivalent POJO would look something like this:

public class Card {
	private int value;
    private Suit suit;

    public int getValue() {
    	return value;
    }

    public Suit getSuit() {
    	return suit;
    }

    public enum Suit {
    	HEARTS,
        DIAMONDS,
        CLUBS,
        SPADES
    }
}

So what’s the simplest way of deserializing the suit field into the Java object? A common approach is to create a type adapter (e.g. LowercaseEnumTypeAdapterFactory) that will write the enum names in lower-case and map it to the correct constant.

However, there’s an easier way to do it, using annotations! GSON provides five different annotations, as documented in the Java Doc. The one we’re interested in is called SerializedName.

So let’s annotate our enum constants:

public class Card {
	private int value;
    private Suit suit;

    public int getValue() {
    	return value;
    }

    public Suit getSuit() {
    	if(suit == null) suit = Suit.UNKNOWN;
    	return suit;
    }

    public enum Suit {
    	@SerializedName("hearts") HEARTS,
        @SerializedName("diamonds") DIAMONDS,
        @SerializedName("clubs") CLUBS,
        @SerializedName("spades") SPADES,
        UNKNOWN
    }
}

Note that I also added another constant to the enum called UNKNOWN. The reason being that if your server returns (for whatever reason) a value that isn’t part of your enum set, we’ll return Suit.UNKNOWN in order to avoid a NullPointerException.

On the downside, this approach is case-sensitive. While solutions like the aforementioned LowercaseEnumTypeAdapterFactory are more flexible because of their case-insensitivity, they usually require more code to be written and need to be registered with a GsonBuilder. However, most of the time you should know what the response of the server you’re talking to looks like, so the annotation-based approach is generally the simpler and more concise solution.

How to include Jenkins CI build number in Android APK name & app label

2014-10-01T16:44:24+01:00

Here are two quick tips that let you include your current Jenkins CI build number in both your .apk’s file name and/or the app label.

When Jenkins executes a job, it sets some environment variables that you can refer to in your build script. Here’s a full list of all the variables that are available: Jenkins Set Environment Variables

The one we’re interested in is called BUILD_NUMBER. And here’s how you can refer to it in your build script using the Groovy DSL:

Setting the APK name:

The default APK base name can be changed with the project’s archivesBaseName property:

defaultConfig {
	versionCode System.getenv("BUILD_NUMBER") as Integer ?: 0
    versionName 1.0
	project.ext.set("archivesBaseName", "MyApp-" + versionName + "-" + versionCode);
}

This code snippet would produce the following APK names:

MyApp-1.0-55.apk for build no. 55 from Jenkins CI and

MyApp-1.0-0.apk for local builds from your IDE.

It’s as simple as that. You can use System.getenv("foobar") to grab any of the environment variables that are available.

Ok, now let’s change the app label. That’s the actual name of your app, the way you see it in the app launcher.

Setting the app label:

Let’s assume in your AndroidManifest.xml you are referring to the app label like this: android:label="@string/app_name" The Android Gradle plugin let’s you override resource values using the resValue command. So in order to include your current Jenkins build number in the app label you can use the following snippet:

resValue "string", "app_name", "MyApp " + (System.getenv("BUILD_NUMBER") ?: "IDE")

This will override the app_name resource with whatever you pass as the 3rd parameter. In our case that’s again the Jenkins build number (if available) or “IDE” for local builds. Note that you can use that command in both the defaultConfig, the buildTypes and the productFlavors closure. Pretty cool, eh?

Btw I’ve been using the Elvis operator to keep the commands nice and concise. Have you ever wondered why it’s called like that? Just turn your head to the left.

?:

How to publish API level specific Android library implementations to Maven Central

2014-09-27T10:02:00+01:00

So what’s this article all about? I’m sure the title can’t be any more puzzling…

I’ve recently gradlefied one of my open-source libraries: Android-UndoBar

One of the requirements was to offer two implementations. One variant with minSdkVersion set to API Level 8 using nineoldandroids for the animations and another variant for API Level 15 using the native animations framework. The reason being that developers targeting API Level 15 or later shouldn’t have to include the 9OA library which is about 110 kb in size.

Ok, so Gradle’s declarative build system seems to be the perfect problem solver for this. Let’s start with the build.gradle file: Firstly, we have to obviously specify the different API levels we wanna target. The productFlavors closure is the right place for this:

productFlavors {
        api8 {
            minSdkVersion 8
        }
        api15 {
            minSdkVersion 15
        }
    }

Secondly, we need to tell Gradle to publish all variants of our library which results in multiple .aar files being created:

defaultPublishConfig "api15Release"
publishNonDefault true

Also, since we’re now publishing multiple variants, we should specify a default config. I picked the API level 15 variant in my case. Note that you need to specify the full build variant, so it’s api15Release and not just ~~api15~~. You can read more about these commands for library publication in the official user guide.

Finally, don’t forget to list your dependencies. Since we only wanna include the 9OA library for the variant targeting API level 8, we use api8Compile instead of just compile.

dependencies {
    api8Compile files("libs/nineoldandroids-2.4.0.jar")
}

Kuul, so that’s the Gradle part done.

Next, let’s write some Java!

To restate the problem: For api8 we wanna use the 90A library to perform the animations, for api15 the native animations framework.

So, how are we gonna do that? The main idea is to create an interface or an abstract base class to hold common logic and provide two API level specific implementations of it.

Here’s an excerpt of the base class. I decided to call it ViewCompat:

public abstract class ViewCompat {

    protected final View mView;

    public ViewCompat(View view) {
    	mView = view;
    }

    protected abstract void animateIn(long duration);

    /* omitted for brevity */
}

It just keeps a reference to the view we wanna animate and lists some abstract animation methods. No big deal.

And now the two API level specific implementations. ViewCompatImpl for API Level 15:

import android.view.ViewPropertyAnimator;

public class ViewCompatImpl extends ViewCompat {

    private final ViewPropertyAnimator mViewPropertyAnimator;

    public ViewCompatImpl(View view) {
        super(view);
        mViewPropertyAnimator = view.animate();
    }

    @Override
    protected void animateIn(long duration) {
        mViewPropertyAnimator.cancel();
        mViewPropertyAnimator.alpha(1)//
                .setDuration(duration);
    }

    /* omitted for brevity */
}

ViewCompatImpl for API Level 8:

import com.nineoldandroids.view.ViewPropertyAnimator;

public class ViewCompatImpl extends ViewCompat {

    private final ViewPropertyAnimator mViewPropertyAnimator;

    public ViewCompatImpl(View view) {
        super(view);
        mViewPropertyAnimator = ViewPropertyAnimator.animate(view);
    }

    @Override
    protected void animateIn(long duration) {
        mViewPropertyAnimator.cancel();
        mViewPropertyAnimator.alpha(1)//
                .setDuration(duration);
    }

}

As you can see the code is pretty similar. The crucial difference is the import and use of android.view.ViewPropertyAnimator; vs com.nineoldandroids.view.ViewPropertyAnimator. It’s native animations vs 90A.

So assuming you comply with the default Android project structure, your library module should look something like this:

The ViewCompat interface resides in the main folder whereas the two API level specific implementations should be placed in respective api8 and api15 folders based on the product flavors we have defined earlier on.

So that’s it. If you now create an instance of your ViewCompat class, like so

ViewCompat viewCompat = new ViewCompatImpl(view);

Gradle will make sure to pick up the right implementation for you depending on the variant you are building. If you’re using Android Studio you will see that the java package of the selected build variant gets a blue tint just like the main java source package. So you can see right away which implementation is currently being used and will be picked up by the build system. Classes of other, inactive variants are badged with a red exclamation mark. Pretty cool!

One more thing: If you’re publishing your library to Maven Central (and you really should!), you have to specify the full build variant in your dependencies, just like this:

compile 'com.github.jenzz.undobar:library:1.1:api15Release@aar'

compile 'com.github.jenzz.undobar:library:1.1:api8Release@aar'

It’s not really nice, but it works!

If you’re aware of better, cleaner way to achieve this, please let me know in the comments.