RSS Feed
Nov 2

GnuCash Android v2.0.0 release

Posted on Monday, November 2, 2015 in Coding, GnuCash

Hard to believe it’s been 3 years already since the first release of GnuCash Android to the Google Play store. Since then, the app has come a long way from it’s humble beginnings as a simple expense tracker which saved a transaction and an amount and exported them to OFX.

GnuCash Android v2.0 v2.0.0_reports GnuCash transaction

Over several iterations in the 1.x series, we added support for double-entry accounting, split transactions, import and export of GnuCash XML files, support for QIF export format and more. We also now have 4 regular contributors instead of just one which bids well for the future 😉

Today we are announcing release of v2.0.0 of GnuCash Android which is the first major design overhaul. The app now follows the material design guidelines with bold use of color for distinguishing accounts, calculator for transaction entry, improved reporting, multi-currency transactions and so much more.

The full changelog for the v2.0.0 release can be found on GitHub. There is also a GnuCash Android Google+ community where you can discuss with other users, suggest ideas, and interact with the developers.

I am also pleased to announce that starting with v2.0.0, Kindle Fire users can also download GnuCash Android directly from the Amazon App Store for Android

The app has been slowly rolling out in the Google Play store over the past week, so some of you may have it already. Today, we are making it fully available to everyone. We look forward to your feedback and hope you enjoy using it as much as we did developing it.

Jul 13

Android Contact Picker Library Update

Posted on Monday, July 13, 2015 in Coding

26 January 2013´- That is the date when the Android Contact Picker library first went live in the Maven central repository. The Android contact picker library enables you to support the workflow of opening the contact list, user picks a contact, selects a number and then have that number returned to your application through an Android Intent.

Since that time, several things have happened in the Android universe; new Android releases, migration to Gradle as the preferred build system for Android, introduction of Android Studio, Material Design and much more. acp_library_screenshot

Well, over the weekend, I updated and published v3.0.0 of the Android Contact Picker library to maven central. This update includes the following:

  • Update to Material design
  • New menu option for searching contacts
  • Menu option for adding a new contact
  • Added a new sample application for testing the app
  • Bug fixes

The new library is deployed as an .aar artifact to the Maven central repository. This is the library format currently preferred by gradle and eases integration with your current application. To use the library, simply add the dependency to your Gradle file as follows:

compile ''

The minimum supported Android API level has also been increased from API level 7 to 8 and the library uses the AppCompat library for backwards compatibility support.

As always, your feedback is welcome! Tell me in the comments how you use the library, and what kinds of things you are missing, or just that you like it Winking smile

Jun 30

How to create Shadow classes in Robolectric 3

Posted on Tuesday, June 30, 2015 in Coding

Mobile application testing is one very important feature of app development. So is diagnostic logging for debugging purposes. Robolectric is one of the good frameworks out there for running very fast tests of your Android application inside the Java virtual machine.

Robolectric can be extended by use of shadow classes which modify the behaviour of certain classes in the Android OS. However, your application also depends on other libraries which are not included in the Android framework. Fortunately, Robolectric gives you the means to create shadow classes for external libraries which you use so you can modify or extend the behaviour of the library during testing.

Shadow classes for classes in the Android framework are automatically picked up and loaded by Robolectric during testing, but shadow classes for third-party libraries need a bit more work for Robolectric to use them. In Robolectric 3, the way to create shadow classes has changed from previous versions. There isn’t much documentation for the new release yet, so after some experimentation, I found a way to create shadow classes which I am documenting here for future reference.

In my case, I was creating a shadow class for the Crashlytics logging library so that I could disable all logging to the service during testing. I created my shadow class as follows:

public class ShadowCrashlytics {

    public static void start(Context context){
        System.out.println("Shadowing crashlytics start");
        //nothing to see here, move along

The @Implements annotation allows you to specify which class you are shadowing. Also you need to implement the methods with the exact same signatures as in the original class. In this case, I only needed one method, the start() method which should do nothing.

Next thing to do is to implement a test runner which you can use to load the tests into the app. An example of such class looks like this (code adapted from this link):

public class GnucashTestRunner extends RobolectricGradleTestRunner {

    private static final List<String> CUSTOM_SHADOW_TARGETS =
    public GnucashTestRunner(Class<?> klass) throws InitializationError {

    protected ShadowMap createShadowMap() {
        return super.createShadowMap()

    public InstrumentingClassLoaderConfig createSetup() {
        return new InstrumenterConfig();

    private class InstrumenterConfig extends InstrumentingClassLoaderConfig {

        public boolean shouldInstrument(ClassInfo classInfo) {
            return CUSTOM_SHADOW_TARGETS.contains(classInfo.getName())
                    || super.shouldInstrument(classInfo);



The test runner needs to be declared in your Gradle file in the defaultConfig section as follows:

testInstrumentationRunner ""

Also, all the test classes should have the annotation:

@Config(constants = BuildConfig.class, shadows = {ShadowCrashlytics.class})

Note that we declare our shadow class in the annotation so that it is loaded. If you have more than one shadow class, add it to the list separated by commas.

And that’s it! Now when you run your tests, your custom shadow classes should be loaded and executed.