The problem

The Grails plugin collective (GPC) offers the so-called “Spring-Cache Plugin” [1], a great plugin by Robert Fletcher. The plugin comes with a @Cacheable annotation. Whenever a type, method or field is annotated as “cacheable” the result is put into a Ehcache instance and further calls might return a cached result (depending on the cache settings).

Let’s start with the default settings. The default Ehcache cache setting look like this (extracted from ehcache-failsafe.xml):

<defaultCache
            maxElementsInMemory="10000"
            eternal="false"
            timeToIdleSeconds="120"
            timeToLiveSeconds="120"
            overflowToDisk="true"
            maxElementsOnDisk="10000000"
            diskPersistent="false"
            diskExpiryThreadIntervalSeconds="120"
            memoryStoreEvictionPolicy="LRU"
            />

The attribute overflowToDisk is true, meaning that whenever the maximum number of in-memory objects is reached, objects are swapped to disk. However, diskPersistent is false, meaning that between subsequent server/application restarts, the in-memory cache is lost and all swapped objects will be cleaned on startup.

Our requirement was to activate disk persistency and configure a diskStorePath, based on a given customer configuration. The customer configuration diskStore directory path would be based on the build settings, ie. a custom Config.groovy file.

Specifying a custom diskStorePath would be done in a custom ehcache.xml file like this:

<diskStore path="here comes the customer-specific directory"/>

Setting the diskStorePath

The Springcache plugin works with Spring’s EhCacheManagerFactoryBean and EhCacheFactoryBean. Given the following configuration in Config.groovy …

springcache.enabled = true

springcache {
    defaults {
        // set default cache properties that will apply to all caches that do not override them
        eternal = false
        diskPersistent = true
        maxElementsInMemory = 1000
        maxElementsOnDisk = 10000

//        24 hours
        timeToIdle = 86400
        timeToLive = 86400

        overflowToDisk = true
        memoryStoreEvictionPolicy = "LRU"
    }

    caches {
        myCache {
            // set any properties unique to this cache
        }
        // more caches follow ...
}

… the plugin will create one or multiple EhCacheFactoryBean instances, by iterating over springcache.defaults.

    springcacheDefaultCache(EhCacheFactoryBean) { bean ->
        bean."abstract" = true
        cacheManager = ref("springcacheCacheManager")
        application.config.springcache.defaults.each {
            bean.setPropertyValue it.key, it.value
        }
    }

    application.config.springcache.caches.each {String name, ConfigObject cacheConfig ->
        "$name"(EhCacheFactoryBean) {bean ->
            bean.parent = springcacheDefaultCache
            cacheName = name
            cacheConfig.each {
                bean.setPropertyValue it.key, it.value
            }
        }
    }

The diskStorePath is actually held by Ehcache’s CacheManager. It is a singleton managing the default cache and all the other cache instances. Bad news is that EhcacheManagerFactoryBean does not provide a way to define a diskStorePath [2]. The only way to configure a custom path is to reference a custom ehcache.xml configuration:

public class EhCacheManagerFactoryBean {
    // ...
    public void setConfigLocation(org.springframework.core.io.Resource configLocation)
}

As we have multiple customers and therefore potentially multiple diskStore paths and wanted to control the path through the customer-specific Config.groovy, we had to find a way to dynamically generate a temporary ehcache.xml.

As it turns out, with Groovy’s XML support this is a pretty straight-forward process in resources.groovy:

springcacheCacheManager(EhCacheManagerFactoryBean) {
         // ... set other props

        def writer = new StringWriter()
        def xml = new MarkupBuilder(writer)

        xml.ehcache() {
          diskStore(path: config.app.cache.diskStorePath ?: 'java.io.tmpdir/springcache')
          defaultCache(config.springcache.defaults)
        }

        def ehCacheXmlTempFile   = File.createTempFile("ehcache-springcache", ".xml")
        ehCacheXmlTempFile.setText(writer.toString())

        // set the spring bean property
        configLocation = new FileSystemResource(ehCacheXmlTempFile)
}

As you can see from the code snippet above, XmlSlurper is used to slurp a ehcache.xml configuration template, without any predefined settings. As the Springcache plugin has already been configured in Config.groovy, it ‘synchronizes’ those settings and injects all properties into the slurped DOM. The best thing is that diskStorePath can be set accordingly to the current configuration setting in config.app.cache.diskStorePath, defaulting to the default temporary directory. Last, StreamingMarkupBuilder is used to write the resulting XML to a newly created temporary file.

Conclusion

This article shows how using a dynamic programming language for bean definitions is just awesome and how Groovy’s excellent XML support can be used in places XML gurus only can dream of.

[0] Ehcache – http://ehcache.org/
[1] Grails Springcache Plugin
[2] Spring JIRA – [EhCacheFactoryBean] diskStorePath property has no effect

public class Default {

    // ...
    public static Float floatObject(Float n) {
        return n != null ? n : 0.0f;
    }

    public static Integer integerObject(Integer i) {
        return i != null ? i : 0;
    }

    // ...
}

Doin it the Groovy way

With the upcoming popularity of Groovy AST transformations, I thought it would be time to write a small NullSafeASTTransformation with the attached @NullSafe annotation.

As Groovy is dynamically typed, @NullSafe is restricted to work on statically declared local variables.

@NullSafe String name = data.name
@NullSafe Integer count = data.count
@NullSafe BigDecimal amount = data.amount

assert name == ''
assert count == 0
assert amount == 0.0

As you can see in the code sample above, @NullSafe ensures that the according variable value is at least of the variables type’s default value, after the initial expression has been executed at runtime.

In addition, the NullSafeASTTransformation checks all variable assignments with a custom class code visitor, to ensure that a variable assignment will result in the default value and not null.

def doSomeStuff()  {

    @NullSafe BigDecimal bd = 12.0
    bd = compute()
    assert bd == 0.0
}

def compute() { return null }

The NullSafeASTTransformation is a local AST transformation [0], injecting static method calls to a hidden NullSafeUtil class:

@GroovyASTTransformation(phase=CompilePhase.SEMANTIC_ANALYSIS)
class NullSafeASTTransformation implements ASTTransformation {

    SourceUnit sourceUnit
    ClassNode NULL_SAFE_UTIL_CLASS = ClassHelper.make(NullSafeUtil.class)

    void visit(org.codehaus.groovy.ast.ASTNode[] nodes, org.codehaus.groovy.control.SourceUnit source) {
        this.sourceUnit = source

        if (sourceUnit.getAST().classes.size() != 1)  {
            addError('@NullSafe annotation can only be applied on local variables!', nodes[0])
            return
        }

        if (nodes.length != 2 || !(nodes[0] instanceof AnnotationNode) || !(nodes[1] instanceof DeclarationExpression)) {
            addError('@NullSafe annotation can only be applied on local variables!', nodes[0])
            return
        }

        DeclarationExpression declarationExpression = nodes[1]

        if (!(declarationExpression.leftExpression instanceof VariableExpression)) {
            addError('@NullSafe can only be applied on the left side of a variable declaration!', declarationExpression)
            return
        }

        injectDeclarationNullSafeCheck(declarationExpression)
        injectAssignmentNullSafeCheck(declarationExpression)
    }

    void injectDeclarationNullSafeCheck(DeclarationExpression declarationExpression)  {
        VariableExpression variableExpression = declarationExpression.leftExpression

        if (variableExpression.dynamicTyped || variableExpression.accessedVariable.type == ClassHelper.DYNAMIC_TYPE)  {
            addError('@NullSafe is not supported on dynamically typed variables!', variableExpression)
            return
        }

        def rightExpression = declarationExpression.getRightExpression()
        if (rightExpression == null)  {
            addError("@NullSafeNumber right expression is empty", declarationExpression)
            return
        }

        ClassNode variableType = variableExpression.accessedVariable.type
        declarationExpression.rightExpression = new StaticMethodCallExpression(NULL_SAFE_UTIL_CLASS, "nullSafe", new ArgumentListExpression([new CastExpression(variableType, rightExpression)]))
    }

    void injectAssignmentNullSafeCheck(DeclarationExpression declarationExpression)  {
        VariableExpression variableExpression = declarationExpression.leftExpression

        if (variableExpression.dynamicTyped || variableExpression.accessedVariable.type == ClassHelper.DYNAMIC_TYPE)  {
            addError('@NullSafe is not supported on dynamically typed variables!', variableExpression)
            return
        }

        def rightExpression = declarationExpression.getRightExpression()
        if (rightExpression == null)  {
            addError("@NullSafeNumber right expression is empty", declarationExpression)
            return
        }

        NullSafeClassCodeVisitor visitor = new NullSafeClassCodeVisitor(sourceUnit, variableExpression.accessedVariable)
        visitor.visitClass(sourceUnit.getAST().classes[0])
    }

    protected void addError(String msg, ASTNode expr) {
        int line = expr.getLineNumber();
        int col = expr.getColumnNumber();
        sourceUnit.getErrorCollector().addErrorAndContinue(
                new SyntaxErrorMessage(new SyntaxException(msg + '\n', line, col), sourceUnit)
        );
    }
}

The most important points besides checking if the annotation has been applied in a valid context, is the injection of the static method call to NullSafeUtil.nullSafe. As Groovy dynamically dispatches static method calls it is ensured that static method selection is based on the variables runtime type.

Conclusion

The @NullSafe annotation currently works on statically typed local variables. At time of writing, the types cover all Number descendants, String and Character.

You can have a look at the complete source at Github [1], please contribute or leave comments!

[0] Groovy Documentation on local AST transformations – http://groovy.codehaus.org/Local+AST+Transformations
[1] @NullSafe Github Project – https://github.com/andresteingress/groovy-null-safe-ast/

This release covers bug fixes, Groovy 1.8.4 and above compatibility and fixed a compilation error in Spock specifications.

Release Notes

• [33] Unable to apply GContracts annotation on Spock methods
• [34] support for Groovy 1.8.x

[0] GContracts 1.2.5 @ Central Maven Repository
[1] Github Download Page

Special thanks to Evgeny Goldin for all of his contributions and testing!

So I decided to setup a new Github project (what else?) named GSheets [3]. At the current point of time it consists of a single class called ExcelFile, a Groovy builder for Excel workbooks based on HSSF [4].

Workbook workbook = new ExcelFile().workbook {

            // section for workbook formatting styles
            styles {
                font("bold")  { Font font ->
                    font.setBoldweight(Font.BOLDWEIGHT_BOLD)
                }

                cellStyle ("header")  { CellStyle cellStyle ->
                    cellStyle.setAlignment(CellStyle.ALIGN_CENTER)

                }
            }

	    // section for workbook data
            data {
                sheet ("Export")  {
                    header(["Column1", "Column2", "Column3"])

                    row(["a", "b", "c"])
                }
            }

            // section for applying commands i.e. apply a cell style, merge cells etc.
            commands {
                applyCellStyle(cellStyle: "header", font: "bold", rows: 1, columns: 1..3)
            }
        }

As can be seen in the code sample above, ExcelFile gives a simple DSL for specifying styles, table data and commands. The styles section is used to define CellStyle objects. The data section specifies all the (header) rows and the commands section is used to apply styles, merge cells, and do various other operations on the current workbook sheet.

What’s next?

I plan to continuously extend ExcelFile with all the spreadsheet generating features HSSF provides. If you want to contribute, feel free to ping me on Twitter (@asteingr) or this blog.

[0] Apache POI – http://poi.apache.org/
[1] http://skepticalhumorist.blogspot.com/2010/12/groovy-dslbuilders-poi-spreadsheets.html
[2] http://www.technipelago.se/content/technipelago/blog/44
[3] GSheets Github – https://github.com/andresteingress/gsheets
[4] Apache POI Spreadsheets – http://poi.apache.org/spreadsheet/

Die Ausgabe des Android360 Magazins [0] enthält einen Artikel von mir über Android Entwicklung mit Scala als alternative Dalvik VM Programmiersprache.

Kaufen, lesen und endlich glücklich werden

[0] Android360 Magazin – http://android360.de/

Let’s have a look at the following code:

public class OuterClass {

    private String someInstanceVariable = "";

    private InnerClass anonymous = new InnerClass() {

        @Override public void someMethod() {
            someInstanceVariable = "Test";
        }
    };
}

As InnerClass is a so-called “anonymous private inner class”, it might reference instance variables from the enclosing class. What does this mean at runtime?

In Java, whenever an OuterClass instance is created, the InnerClass instance will automatically have a reference to its client, the object of type OuterClass, implying that there is no inner class instance without an outer class instance. Let’s take a look at the compilation result of the above example.

The compilation results in two class files: OuterClass.class and OuterClass$1.class, whereas the latter holds the implementation of the anonymous inner class. After throwing both classes into a Java disassembler, we end up with the following source code:

package org.example;

public class OuterClass
{

    public OuterClass()
    {
    	super();
    	someInstanceVariable = "";
    	anonymous = new OuterClass$1(this);
    }

    static String access$002(OuterClass x0, String x1)
    {
    	this.someInstanceVariable = x1;
    	return this.someInstanceVariable;
    }

    private String someInstanceVariable;
    private InnerClass anonymous;

    class OuterClass$1 extends InnerClass
    {

        OuterClass$1(OuterClass outerClass)
        {
        	this$0 = outerClass;
        	super();
        }

        public void someMethod()
        {
        	OuterClass.access$002(this$0, "Test");
        }

        final OuterClass this$0;
    }
}

The most important part in the Java disassembled code is the OuterClass$1 class holding a reference to the actual OuterClass instance. This is an important issue to understand when working with the Android framework, as it makes heavy use of anonymous classes and non-static inner classes.

Anonymous Inner Classes & Android

Let us now consider the following Activity implementation:

public class SomeActivity extends Activity
{

    private View.OnClickListener onClickListener = new View.OnClickListener() {

        public void onClick(View view) {
            new SomeLongRunningTask().execute();
        }
    };

    private Button someButton;

    private class SomeLongRunningTask extends AsyncTask<Void, Void, Boolean> {

        @Override
        protected Boolean doInBackground(Void... voids) {

            try {
                Thread.sleep(30000);
            } catch (InterruptedException e) {}

            return true;
        }

        @Override
        protected void onPostExecute(Boolean aBoolean) {
            someButton.setText(aBoolean ? "Successful" : "Fail");
        }
    }

    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        someButton = (Button) findViewById(R.id.someButton);
        someButton.setOnClickListener(onClickListener);
    }
}

As you can see the reference to the current Activity is implicitly embedded two times:

• it is embedded in the anonymous OnClickListener implementation class and
• it is embedded in the SomeLongRunningTask class

In effect, this means these are two potential places in this very simple activity where e.g. an orientation change might indirectly cause the listener or asynchronous task to leak the current Activity instance.

Let us consider the classic case of device rotation. The OnClickListener is not the problem in this case as the activity object is completely destroyed and a new activity object instance is created by the framework (although it could be a problem depending on the code that is executed by the listener).

But it gets interesting with the SomeLongRunningTask class. As long as a task instance is running in the background, it keeps a reference to the activity object that created it, no matter if Android already re-created a new Activity instance or not.

How to remove implicit references?

One way to solve this problem would be to use a static inner class. One property of these classes is their missing reference to the outer class. As we will still need the reference to the Button to update its text message, we have to introduce a Handler. The Handler is the one that should be responsible for ui updates, as it has a reference to the current UI thread.

public class SomeActivity extends Activity
{
    private static final int UPDATE_BUTTON_TEXT = 1;
    private static final SomeActivity me = null;

    private static Handler handler = new Handler() {
        public void handleMessage(Message msg)  {
          if (me == null) return;

          switch (msg.what)  {
            case UPDATE_BUTTON_TEXT:
              Button btn = (Button) me.findViewById(R.id.someButton);
              btn.setText((String) msg.obj);
          }
        }
    };

    private View.OnClickListener onClickListener = new View.OnClickListener() {
       public void onClick(View view) {
            new SomeLongRunningTask().execute();
        }
    };

    private static class SomeLongRunningTask extends AsyncTask<Void, Void, Boolean> {

        private Handler handler;

        public SomeLongRunningTask(Handler handler)  {
            this.handler = handler;
        }

        @Override
        protected Boolean doInBackground(Void... voids) {

            try {
                Thread.sleep(30000); // replace with some background logic
            } catch (InterruptedException e) {}

            return true;
        }

        @Override
        protected void onPostExecute(Boolean aBoolean) {
            Message msg = handler.obtainMessage(UPDATE_BUTTON_TEXT);
            msg.obj = "success"
            handler.sendMessage(msg);
        }
    }

    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        final Button someButton = (Button) findViewById(R.id.someButton);
        someButton.setOnClickListener(onClickListener);
    }

    @Override
    protected void onStart() {
        super.onStart();

        me = this;
    }

    @Override
    protected void onStop() {
        me = null;

        super.onStop();
    }
}

Conclusion

After all, this is a very stripped down example. But when thinking of elaborate applications, programmers should know about anonymous classes and their (invisible) side-effects.

[0] Romain Guy – Avoiding Memory Leaks – http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html
[1] Attacking Memory Problems on Android – http://ttlnews.blogspot.com/2010/01/attacking-memory-problems-on-android.html

As a consequence, I had to do some research on full-text search capabilities in Android. While reading through the dev guide on search dialogs, a sentence triggered my attention [0]:

If your data is stored in a SQLite database on the device, performing a full-text search (using FTS3, rather than a LIKE query) can provide a more robust search across text data and can produce results significantly faster.

FTS3? That sounded interesting and I did some research into that direction.

The FTS3 SQLite Extension

FTS is the acronym for “full-text search”. FTS3 itself is an SQLite extension that is now part of SQLite that provides support for creating virtual tables which in fact maintain an inverted index for full-text searches. That means you can use FTS tables to enable full-text search in Android applications.

Let us see how this was done in the dictionary application. The DatabaseOpenHelper class extended SQLiteOpenHelper and created (among others) a virtual table.

public class DatabaseOpenHelper extends SQLiteOpenHelper {

	private static final int DATABASE_VERSION = 1;

	public static final String TABLE_WORDS = "WORDS";
	public static final String TABLE_WORDS_FTS = "WORDS_FTS";
        // ...

	public static final String COL_ID = BaseColumns._ID;

	public static final String COL_KEY_LABEL = "LABEL";
	public static final String COL_KEY_DESCRIPTION = "DESCRIPTION";
	public static final String COL_KEY_LANGUAGE = "LANGUAGE";

	public static final String COL_KEY_CODE = "CODE";
	public static final String COL_KEY_NAME = "NAME";

	public static final String COL_KEY_TERM = "TERM";
	public static final String COL_KEY_LINKED_TERM = "LINKED_TERM";

	public static final String COL_ACC_TIME = "ACC_TIME";
	public static final String COL_ACC_DATE = "ACC_DATE";
	public static final String COL_TERM_ID = "WORD_ID";
	public static final String COL_ICON_ID = "ICON_ID";

	public DatabaseOpenHelper(final Context context) {
		super(context, ApplicationConstants.DATABASE_NAME, null, DATABASE_VERSION);
	}

	@Override
	public void onCreate(final SQLiteDatabase db) {
		executeDDL(db);
	}

	@Override
	public void onUpgrade(final SQLiteDatabase db, final int oldVersion, final int newVersion) {
		dropIfExists(db);
		onCreate(db);
	}

	private void dropIfExists(final SQLiteDatabase db) {
		db.execSQL("DROP TABLE IF EXISTS " + TABLE_WORDS);
		db.execSQL("DROP TABLE IF EXISTS " + TABLE_WORDS_FTS);
		// ...
	}

	private void executeDDL(final SQLiteDatabase db) {
		Log.d("Database", "Updating dictionary db ...");
		db.execSQL("CREATE TABLE " + TABLE_WORDS + "(" + COL_ID + " INTEGER PRIMARY KEY AUTOINCREMENT, "
				+ COL_KEY_LABEL + " VARCHAR(128), " + COL_KEY_DESCRIPTION + " TEXT, " + COL_KEY_LANGUAGE + " INTEGER, "
				+ COL_KEY_TERM + " INTEGER " + ");");

		db.execSQL("CREATE INDEX IF NOT EXISTS IDX_WORDS_TERM ON " + TABLE_WORDS + " (" + COL_KEY_TERM + ")");
		db.execSQL("CREATE INDEX IF NOT EXISTS IDX_WORDS_LANGUAGE ON " + TABLE_WORDS + " (" + COL_KEY_LANGUAGE + ")");

		db.execSQL("CREATE VIRTUAL TABLE " + TABLE_WORDS_FTS + " USING fts3(" + COL_ID + ", " + COL_KEY_LABEL + ", "
				+ COL_KEY_DESCRIPTION + " , " + COL_KEY_LANGUAGE + ", " + COL_KEY_TERM + " " + ");");

	}
}

The statement

db.execSQL("CREATE VIRTUAL TABLE " + TABLE_WORDS_FTS + " USING fts3(" + COL_ID + ", " + COL_KEY_LABEL + ", " + COL_KEY_DESCRIPTION + " , " + COL_KEY_LANGUAGE + ", " + COL_KEY_TERM + " " + ");");

creates a virtual table using the FTS3 extension. The table can be filled and updated with the usual SQL commands but uses an inverted index for fast full-text searches underneath.

The interesting part is the query syntax. FTS3 tables are queried using the MATCH keyword.

public class DictionaryRepository {

   // ...
   public Cursor queryFulltextTermsForLanguage(String query, final Long languageId) {
        assert !TextUtils.isEmpty(query) : "query must not be an empty string!";
        assert languageId >= 0: "LanguageId must be greater or equal than 0";

        return database.query(DatabaseOpenHelper.TABLE_WORDS_FTS,
                new String[] { DatabaseOpenHelper.COL_KEY_TERM, DatabaseOpenHelper.COL_KEY_LABEL, DatabaseOpenHelper.COL_KEY_LANGUAGE, DatabaseOpenHelper.COL_ID },
                DatabaseOpenHelper.TABLE_WORDS_FTS + " MATCH ?",
                new String[] { appendWildcard(query) + " " + DatabaseOpenHelper.COL_KEY_LANGUAGE + ": " + languageId.toString() },
                null, null, null);
    }

    private String appendWildcard(String query) {
        if (TextUtils.isEmpty(query)) return query;

        final StringBuilder builder = new StringBuilder();
        final String[] splits = TextUtils.split(query, " ");

        for (String split : splits)
          builder.append(split).append("*").append(" ");

        return builder.toString().trim();
    }
    // ...
}

As can be seen from the example above, the FTS3 supports not even unqualified queries like

SELECT * FROM words_fts WHERE words_fts MATCH 'company';

but also qualified queries identifying the query columns by column: columnName

SELECT * FROM words_fts WHERE words_fts MATCH 'description: company';

and the * operator

SELECT * FROM words_fts WHERE words_fts MATCH 'description: comp*';

A complete guide on FTS full-text queries can be found at [2].

[0] Creating a Search Interface – Android Developer
[1] Introduction to FTS3 and FTS4
[2] FTS3 Full-Text Index Queries

This behavior can be pretty disturbing in applications with multiple background threads/asynchronous tasks. This article shows how to handle background threads when the current activity instance is destroyed and created back and forth.

Orientation Change Behavior

For the matter of purpose let us assume we have an Activity that shows a large Image using an ImageView loaded from a web server. As the image is very large we decided to show a progress dialog during loading the image.

public class RemoteImageViewActivity extends Activity {

  private ImageView imageView;
  private ProgressDialog dialog;

  private class DownloadImageTask extends AsyncTask<URL, Integer, Bitmap> {
     protected Bitmap doInBackground(URL... urls) {
         return Downloader.downloadFile(urls[0]); // or for testing purpose just Thread.sleep(30000);
     }

     protected void onPostExecute(Bitmap bitmap) {
         imageView.setImageBitmap(bitmap);
         dialog.dismiss();
     }
 }

    @Override public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        imageView = (ImageView) findViewById(R.id.imageView);
        dialog = ProgressDialog.show(this, "", "Loading. Please wait...", true);

        try {
            new DownloadImageTask().execute(new URL("http://blog.andresteingress.com/"));

        } catch (MalformedURLException e) {
            throw new RuntimeException(e);
        }
    }
}

The example above shows a straight-forward implementation I’ve already seen in a handful of Android applications (mine included ).

Now let us see what happens when an orientation change happens during the image is downloaded. As can be seen from the stack trace below, when orientation is changed, our code somehow leaks an activity instance

ERROR/WindowManager(1336): Activity com.example.RemoteImageViewActivity has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@4051c210 that was originally added here
        android.view.WindowLeaked: Activity com.example.RemoteImageViewActivity has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@4051c210 that was originally added here
        at android.view.ViewRoot.<init>(ViewRoot.java:258)
        at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:148)
        at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91)
        at android.view.Window$LocalWindowManager.addView(Window.java:424)
        at android.app.Dialog.show(Dialog.java:241)
        at android.app.ProgressDialog.show(ProgressDialog.java:107)
        at android.app.ProgressDialog.show(ProgressDialog.java:90)
        at com.example.RemoteImageViewActivity.onCreate(RemoteImageViewActivity.java:44)
        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1611)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1663)
        at android.app.ActivityThread.access$1500(ActivityThread.java:117)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:931)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:130)
        at android.app.ActivityThread.main(ActivityThread.java:3683)

and after a while when the dialog needs to be dismissed another exception happens

ERROR/AndroidRuntime(1336): FATAL EXCEPTION: main
        java.lang.IllegalArgumentException: View not attached to window manager
        at android.view.WindowManagerImpl.findViewLocked(WindowManagerImpl.java:355)
        at android.view.WindowManagerImpl.removeView(WindowManagerImpl.java:200)
        at android.view.Window$LocalWindowManager.removeView(Window.java:432)
        at android.app.Dialog.dismissDialog(Dialog.java:278)
        at android.app.Dialog.access$000(Dialog.java:71)
        at android.app.Dialog$1.run(Dialog.java:111)
        at android.app.Dialog.dismiss(Dialog.java:268)

The behavior seems odd at first glance, but when digging into the Android documentation, one finds the reason: per default Android recreates the currently running activity whenever the orientation is changed. That explains why onPostExecute can’t access the current application window and throws an exception (the first exception with the leaking activity instance is explained in a minute).

Handling Orientation changes

There are several ways how to handle an orientation change without leaking windows or accessing “dead” views. In our example above, one way would be to leave the dialog management over to the current Activity. This is done by overriding onCreateDialog and using its companion methods showDialog and dismissDialog.

public class RemoteImageViewActivity extends Activity
{

    protected static final int PROGRESS_BAR_DIALOG = 1;

    private ImageView imageView;

    private class DownloadImageTask extends AsyncTask<URL, Integer, Bitmap> {
        protected Bitmap doInBackground(URL... urls) {

            try {
                Thread.sleep(30000);

                return Bitmap.createBitmap(200, 200, Bitmap.Config.ARGB_8888);

            } catch (InterruptedException e) {
                return null;
            }
        }

        protected void onPostExecute(Bitmap bitmap) {
            imageView.setImageBitmap(bitmap);

            dismissDialog(PROGRESS_BAR_DIALOG);
        }
    }

    @Override public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        imageView = (ImageView) findViewById(R.id.imageView);

        showDialog(PROGRESS_BAR_DIALOG);

        try {
            new DownloadImageTask().execute(new URL("http://blog.andresteingress.com/"));

        } catch (MalformedURLException e) {
            throw new RuntimeException(e);
        }
    }

    @Override protected Dialog onCreateDialog(int id) {
        switch (id)  {
            case PROGRESS_BAR_DIALOG:
                return new ProgressDialog.Builder(this).setTitle("").setMessage("Loading. Please wait...").setCancelable(false).create();
        }

        return null;
    }
}

Overriding the onCreateDialog has the advantage that the Activity base class handles persisting the dialogs state and recreating the dialog on orientation changes.

The problem with the example above is that changing the orientation twice or more times, leads again to the view leaking exception from above as the onCreate method of the activity is called whenever the orientation is changed.

ERROR/WindowManager(1336): Activity com.example.RemoteImageViewActivity has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@4051c210 that was originally added here
        android.view.WindowLeaked: Activity com.example.RemoteImageViewActivity has leaked window com.android.internal.policy.impl.PhoneWindow$DecorView@4051c210 that was originally added here
        at android.view.ViewRoot.<init>(ViewRoot.java:258)
        at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:148)
        at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91)
        at android.view.Window$LocalWindowManager.addView(Window.java:424)
        at android.app.Dialog.show(Dialog.java:241)
        at android.app.ProgressDialog.show(ProgressDialog.java:107)
        at android.app.ProgressDialog.show(ProgressDialog.java:90)
        at com.example.RemoteImageViewActivity.onCreate(RemoteImageViewActivity.java:44)
        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1611)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1663)
        at android.app.ActivityThread.access$1500(ActivityThread.java:117)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:931)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:130)
        at android.app.ActivityThread.main(ActivityThread.java:3683)

This behavior is caused by DownloadImageTask being an inner class. After the orientation change, the asynchronous task refers to the old activity instance and, even worse, it additionally has a reference to the imageView to set the downloaded image accordingly.

But how could we solve that binding to the outer activity instance in our DownloadImageTask task class?

Using a static Handler/Activity Combo

In order to handle the problem with references to the old activity inside inner class object instances, we could use static variables in combination with Android’s Handler class.

public class RemoteImageViewActivity extends Activity
{
    private static RemoteImageViewActivity ACTIVITY = null;

    private static final int SHOW_PROGRESS_BAR_DIALOG = 1;
    private static final int HIDE_PROGRESS_BAR_DIALOG = 2;
    private static final int SHOW_IMAGE = 3;

    private Handler handler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            if (ACTIVITY == null) return;

            switch (msg.what)  {
                case SHOW_PROGRESS_BAR_DIALOG:
                     ACTIVITY.showDialog(PROGRESS_BAR_DIALOG);
                    break;

                case HIDE_PROGRESS_BAR_DIALOG:
                    ACTIVITY.dismissDialog(PROGRESS_BAR_DIALOG);
                    break;

                case SHOW_IMAGE:
                    ImageView imageView = (ImageView) ACTIVITY.findViewById(R.id.imageView);
                    imageView.setImageBitmap((Bitmap) msg.obj);

            }
        }
    };

    protected static final int PROGRESS_BAR_DIALOG = 1;

    private static class DownloadImageTask extends AsyncTask<URL, Integer, Bitmap> {

        private Handler handler;

        public DownloadImageTask(Handler handler)  {
            this.handler = handler;
        }

        protected Bitmap doInBackground(URL... urls) {

            try {
                Thread.sleep(30000);

                return Bitmap.createBitmap(200, 200, Bitmap.Config.ARGB_8888);

            } catch (InterruptedException e) {
                return null;
            }
        }

        protected void onPostExecute(Bitmap bitmap) {
            handler.sendEmptyMessage(HIDE_PROGRESS_BAR_DIALOG);
            handler.sendMessage(Message.obtain(handler, SHOW_IMAGE, bitmap));
        }
    }

    @Override public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        handler.sendEmptyMessage(SHOW_PROGRESS_BAR_DIALOG);

        try {
            new DownloadImageTask(handler).execute(new URL("http://blog.andresteingress.com/"));

        } catch (MalformedURLException e) {
            throw new RuntimeException(e);
        }
    }

    @Override
    protected void onStart() {
        super.onStart();

        ACTIVITY = this;
    }

    @Override
    protected void onStop() {
        ACTIVITY = null;

        super.onStop();
    }

    @Override
    protected Dialog onCreateDialog(int id) {
        switch (id)  {
            case PROGRESS_BAR_DIALOG:
                return new ProgressDialog.Builder(this).setTitle("").setMessage("Loading. Please wait...").setCancelable(false).create();
        }

        return null;
    }
}

The code above always keeps a reference to the current Activity in a static class variable. The asynchronous task implementation now keeps a reference to the Handler instance, avoiding to refer to the old Activity instance. With this little trick we can now safely switch orientations while the background task is running.

But wait, didn’t we see that onCreate is called multiple times during orientation changes? That means, whenever the orientation is changed we create a new instance of DownloadImageTask and start the task again!

Overriding android:configChanges

One way to solve the problem is to introduce another static variable indicating whether the download is currently running in the background or not. But there is another way: we can provide the android:configChanges="orientation" XML attribute in our AndroidManifest.xml.

The configChanges attribute is documented [0] as

Lists configuration changes that the activity will handle itself. When a configuration change occurs at runtime, the activity is shut down and restarted by default, but declaring a configuration with this attribute will prevent the activity from being restarted. Instead, the activity remains running and its onConfigurationChanged() method is called.

where as orientation is used to react on orientation changes.

Let’s add android:configChanges="orientation" to our activity XML declaration and modify the code to

public class RemoteImageViewActivity extends Activity
{

    protected static final int PROGRESS_BAR_DIALOG = 1;

    private ImageView imageView;

    private class DownloadImageTask extends AsyncTask<URL, Integer, Bitmap> {
        protected Bitmap doInBackground(URL... urls) {

            try {
                Thread.sleep(30000);

                return Bitmap.createBitmap(200, 200, Bitmap.Config.ARGB_8888);

            } catch (InterruptedException e) {
                return null;
            }
        }

        protected void onPostExecute(Bitmap bitmap) {
            imageView.setImageBitmap(bitmap);

            dismissDialog(PROGRESS_BAR_DIALOG);
        }
    }

    @Override public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        imageView = (ImageView) findViewById(R.id.imageView);

        showDialog(PROGRESS_BAR_DIALOG);

        try {
            new DownloadImageTask().execute(new URL("http://blog.andresteingress.com/"));

        } catch (MalformedURLException e) {
            throw new RuntimeException(e);
        }
    }

    @Override
    protected Dialog onCreateDialog(int id) {
        switch (id)  {
            case PROGRESS_BAR_DIALOG:
                return new ProgressDialog.Builder(this).setTitle("").setMessage("Loading. Please wait...").setCancelable(false).create();
        }

        return null;
    }

    @Override
    public void onConfigurationChanged(Configuration newConfig) {
        super.onConfigurationChanged(newConfig);

        // some work that needs to be done on orientation change
    }
}

By overriding the onConfigurationChanged method we have avoided activity recreation, which – in our case – does not seem to be necessary. As you can see in the code above, with this approach we do avoid the use of static class variables and the Handler object instance.

Conclusion

There are various ways to handle orientation changes and activity recreations in Android. If you have any other tips or preferred ways to do so, you are free to mention them in this article’s comments section.

[0] android:configChanges Documentation – http://developer.android.com/guide/topics/manifest/activity-element.html#config

The ImageView died that day

Android’s ImageView class is used to draw arbitrary Drawable objects [0]. For the purpose of better understanding its internals, let us assume this class was not part of the Android framework and we would have to introduce a similar class for our project. How should the implementation look like?

The DrawableView

Let’s name our class DrawableView as it is used solely to show object instances of type Drawable and extend it from View as this is the case with every other UI widget.

public class DrawableView extends View {

    public DrawableView(Context context) {
        super(context);
    }

    public DrawableView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public DrawableView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }
}

Now we have to add a custom drawable attribute to be used in the XML layout definition. So let’s create a res/values/attrs.xml

<resources>
    <declare-styleable name="com.example.DrawableView">
        <attr name="src" format="reference"/>
    </declare-styleable>
</resources>

And add code to our DrawableView to retrieve the Drawable instance that will later on be referenced via the newly created src XML attribute

// ...

private Drawable drawable;

public DrawableView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);

        TypedArray typedArray = context.obtainStyledAttributes(attrs, R.styleable.com_example_DrawableView, defStyle, 0);
        drawable = typedArray.getDrawable(R.styleable.com_example_DrawableView_src);

        typedArray.recycle();
}

// ...

Reading the src XML attribute in combination with the standard Android XML attributes already allows us to specify a header image in our layout view.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:example="http://schemas.android.com/apk/res/com.example"

    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">

    <com.example.DrawableView
        android:id="@+id/header"
        android:layout_height="wrap_content"
        android:layout_width="fill_parent"
        example:src="@drawable/header"/>

</LinearLayout>

As you can see in the code snippet above, android:layout_width and android:layout_height are used to specify the View‘s size. In my case the header image is 800 x 200 pixels, now the question raises what to do if a) the view is larger than the referenced image or b) the view is smaller than the referenced image.

Let’s start with the first case – the view is larger than the image.

Case 1 – View > Image

If the available view space is larger than the image, we want a way to specify that the image should be centered horizontally and vertically within the available space – this is exactly the case with ImageView.ScaleType.CENTER. The image is centered without scaling.

To make our DrawableView work we will have to implement onMeasure first.

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {

        int width  = drawable.getIntrinsicWidth();
        int height = drawable.getIntrinsicHeight();

        width  = Math.max(width, getSuggestedMinimumWidth());
        height = Math.max(height, getSuggestedMinimumHeight());

        setMeasuredDimension(resolveSize(width, widthMeasureSpec), resolveSize(height, heightMeasureSpec));
    }

First of all we’ll have to read the drawable’s width and height. If a minimum size is specified we’ll have to take that into account using the Math.max static method. The most important part is the final line: here we used the View.resolveSize method to set the measured width and height accordingly.

resolveSize acts upon the parent views measure specification. In our case we are using a linear layout that fills its parent view and we have specified android:layout_width="fill_parent" and android:layout_height="wrap_content". Given we use a very small header file for testing purposes (e.g. with 200 x 50 pixels), resolveSize would return the width of the actual screen (e.g. 320) but the height of the drawable we suggested. If we would have declared the height to fill the parent view, resolveSize would return the total height otherwise.

Now let us implement the drawing functionality.

    private Drawable drawable;
    private Matrix matrix = new Matrix();

    private int drawableWidth, drawableHeight;
    private int viewWidth, viewHeight;

    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {

        drawableWidth  = drawable.getIntrinsicWidth();
        drawableHeight = drawable.getIntrinsicHeight();

        int width  = Math.max(drawableWidth, getSuggestedMinimumWidth());
        int height = Math.max(drawableHeight, getSuggestedMinimumHeight());

        viewWidth  = resolveSize(width, widthMeasureSpec);
        viewHeight = resolveSize(height, heightMeasureSpec);

        setMeasuredDimension(viewWidth, viewHeight);
    }

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);

        int saveCount = canvas.save();

        // this will center the small header image
        matrix.setTranslate((int) ((viewWidth - drawableWidth) * 0.5f + 0.5f), (int) ((viewHeight - drawableHeight) * 0.5f + 0.5f));

        canvas.concat(matrix);

        drawable.setBounds(0, 0, drawableWidth, drawableHeight);
        drawable.draw(canvas);

        canvas.restoreToCount(saveCount);
    }

I had to refactor the previous code in onMeasure, to store the measured width and height in instance variables. Just drawing the given drawable on the canvas is easy and is done by a call to drawable.draw(canvas). But we want our drawable to be centered in the middle of our DrawableView bounds. This is done by applying a matrix which translates every single pixel of the drawable by a given amount of pixels.

Translation is nothing but a simple calculation whereas each point in matrix M gets translated via M’ = M * T(dx, dy).

With the code above we have already implemented exactly the same functionality as if we applied android:scaleType="center" to an Android ImageView. Cool, isn’t it? Now let’s consider a case that includes image scaling.

Case 2 – View < Drawable

Let us assume we replace the small header image with a large one, say 800 x 200 px. With a screen height of 480 px the height of the image would fit, but the width of the image is too large. What to do in that case? One approach would be to still keep the image ratio, but scale the image so that at least one axis fits for the view and center the result – which leads to cropping the left/right and/or upper/lower part of the image.

That means for our 800 x 200 px image, that the full height is drawn (assuming the screen height has 480 px), but the image width is cropped by 480 pixels, 240 left and 240 right.

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);

        int saveCount = canvas.save();

        float scale;
        float dx = 0, dy = 0;

        if (drawableWidth * viewHeight > viewWidth * drawableHeight) {
            scale = (float) viewHeight / (float) drawableHeight;
            dx = (viewWidth - drawableWidth * scale) * 0.5f;
        } else {
            scale = (float) viewWidth / (float) drawableWidth;
            dy = (viewHeight - drawableHeight * scale) * 0.5f;
        }

        matrix.setScale(scale, scale);
        matrix.postTranslate((int) (dx + 0.5f), (int) (dy + 0.5f));

        canvas.concat(matrix);

        drawable.setBounds(0, 0, drawableWidth, drawableHeight);
        drawable.draw(canvas);

        canvas.restoreToCount(saveCount);
    }

The scaling mechanism seen in the onDraw method above is used to scale the image accordingly to the view’s bounds. In our case, we specified fill_parent and wrap_content, but that could have been also absolute measures or other layout measures.

Ah, and the code above is exactly what android:scaleType="centerCrop" causes.

But cropping isn’t that beautiful, is it? Let’s implement the onDraw method to scale the image so that it fits within the given view bounds, still keeping the image ratio.

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);

        int saveCount = canvas.save();

        float scale;
        float dx;
        float dy;

        if (drawableWidth <= viewWidth && drawableHeight <= viewHeight) {
            scale = 1.0f;
        } else {
            scale = Math.min((float) viewWidth / (float) drawableWidth,
                    (float) viewHeight / (float) drawableHeight);
        }

        dx = (int) ((viewWidth - drawableWidth * scale) * 0.5f + 0.5f);
        dy = (int) ((viewHeight - drawableHeight * scale) * 0.5f + 0.5f);

        matrix.setScale(scale, scale);
        matrix.postTranslate(dx, dy);

        canvas.concat(matrix);

        drawable.setBounds(0, 0, drawableWidth, drawableHeight);
        drawable.draw(canvas);

        canvas.restoreToCount(saveCount);
    }

As you can see in the screenshot below, the actual View bounds are now larger than the drawable height what we returned in onMeasure. Android’s ImageView behaves exactly the same, but it provides an attribute to adjust the view bounds to the image bounds: android:adjustViewBounds.

To apply the view bounds to the scaled drawable dimensions, we would need to write

<ImageView
        android:id="@+id/header"

        android:layout_height="wrap_content"
        android:layout_width="fill_parent"
        android:scaleType="centerInside"

        android:adjustViewBounds="true"

        android:src="@drawable/header"/>

Which results in

What about the other ScaleType configuration values?

What we did not see so far is the implementation of ImageView.ScaleType.FIT_* attributes and ImageView.ScaleType.MATRIX.

The ImageView.ScaleType.MATRIX attribute can be set to use a custom matrix when drawing the image. With ImageView.setImageMatrix arbitrary operations can be executed during drawing the drawable.

All FIT_* scale types actually use the Matrix.setRectToRect method, which allows to translate between two given rectangular bounds.

Rect src = new Rect(0, 0, drawableWidth, drawableHeight);
Rect dst = new Rect(0, 0, viewWidth, viewHeight);

matrix.setRectToRect(src, dst, scaleType);

The interesting part in the example above is the scaleType. This can be one of Matrix.ScaleToFit enumeration values: CENTER, START, END and FILL which exactly map to ImageView.ScaleType‘s FIT_CENTER, FIT_START, FIT_END and FIT_XY. This means that all fit operations internally use a drawing matrix that scale from the drawl bounds to the actual view bounds.

Conclusion

This article tried to bring light into Android’s ImageView various scaling options. In fact, with some basic knowledge about the View, Canvas and Matrix classes and some Matrix operations we were able to implement our DrawableViewclone.

The code for this blog post can be found at Github: https://github.com/andresteingress/android-drawable-view [1]

[0] The ImageView Documentation – http://developer.android.com/reference/android/widget/ImageView.html
[1] android-drawable-view Example Project @ Github – https://github.com/andresteingress/android-drawable-view

This article is about my experiences with Scala and the language features I found most useful when working with the Android framework.

Environment and Prerequisites

First of all: I am an IntelliJ user, working on a MBP. I did not test how writing an Android app with Scala works out in Eclipse. I usually develop all my Android projects in IntelliJ as Eclipse and the Android plugin just did not work out for me (it constantly slows down, hangs, of course your mileage may vary).

I installed the android-sdk, scala, sbt etc. with Homebrew

brew install scala sbt android-sdk

and worked with the following package/software versions:

• Scala: 2.9.1
• Sbt: 0.10.1
• android-sdk: r12
• IntelliJ: 10.5.2
• Mac OSX: 10.7.1

Setting up the project structure and environment

First of all: I don’t want to scare you right away, but neither IntelliJ nor Eclipse (to my knowledge) offers support for developing Android projects with Scala in a continuous process from project creation to APK creation. There is no out-of-the-box configuration, you’ll need to have some manual or scripted steps when developing outside the standard Android environment.

On the other side, IntelliJ offers seperate module facets for Android and Scala projects. When combining the Scala and Android facet you’ll get syntax completion for Scala and Android-specific files, automatic R.java file compilation, sbt APK debug package generation (with a separate run configuration) and, well, the joy to use Scala instead of Java for your Android project .

I don’t want to go into details of IntelliJ module configuration, but in case you chose to work with sbt [3] you can use a giter8 template [2] to jump-start with an sbt supported project structure holding an empty Android application and test setup (for more information see [4]).

Using Scala for your Activity classes

Once you are done setting up the environment, you can start with your first activity, let’s call it HomeActivity. Let’s take a look at the Java implementation.

public class HomeActivity extends Activity {

    public void onCreate(Bundle savedState)  {
        super.onCreate(savedState);
        setContentView(R.layout.home);
    }
}

Since we do need some UI widgets, we will add a login and password EditText field and a Button and add the according code to the Activity class:

public class HomeActivity extends Activity {

private EditText usernameEditText;
private EditText passwordEditText;
private Button   loginButton;

public void onCreate(Bundle savedState)  {
  super.onCreate(savedState);
  setContentView(R.layout.home);

  usernameEditText = (EditText) findViewById(R.id.usernameEditText);
  passwordEditText = (EditText) findViewById(R.id.passwordEditText);
  loginButton = (Button) findViewById(R.id.loginButton);
}
}

Next we’ll register a View.OnClickListener to react on button clicks/touches:

public class HomeActivity extends Activity {

private EditText usernameEditText;
private EditText passwordEditText;
private Button   loginButton;

public void onCreate(Bundle savedState)  {
  super.onCreate(savedState);
  setContentView(R.layout.home);

  usernameEditText = (EditText) findViewById(R.id.usernameEditText);
  passwordEditText = (EditText) findViewById(R.id.passwordEditText);
  loginButton = (Button) findViewById(R.id.loginButton);

  loginButton.setOnClickListener(new View.OnClickListener() {
    public void onClickListener(View view)  {
        // do some validation stuff
        startActivity(new Intent(HomeActivity.this, NextActivity.class));
    }
  });
}
}

That’s it for now with our sample Java-based activity. Now let’s see how the same Activity can be done using the Scala programming language.

As can bee seen from the source samples above, Java quickly produces very bloated code. When working with the Android framework that bloat is typically driven by type casts, anonymous class definitions, inner class definitions, common code to initialize menu items, etc.

Let’s translate the HomeActivity into a Scala class. First of all we’ll consider getting rid of the findViewById method calls and the type casts that have to be done for the return types. The sbt Android plugin generates a special singleton object for that purpose: the TR (typed resources) object. Within that class it creates typed references of type TypedResource for all the UI elements defined in the application’s XML layout files.

case class TypedResource[T](id: Int)

object TR {
  val usernameEditText = TypedResource[EditText](R.id.usernameEditText)
  val passwordEditText = TypedResource[EditText](R.id.passwordEditText)

  val loginButton = TypedResource[Button](R.id.loginButton)
}

trait TypedViewHolder {
  def view: View
  def findView[T](tr: TypedResource[T]) = view.findViewById(tr.id).asInstanceOf[T]
}

trait TypedView extends View with TypedViewHolder { def view = this }

trait TypedActivityHolder {
  def activity: Activity
  def findView[T](tr: TypedResource[T]) = activity.findViewById(tr.id).asInstanceOf[T]
}

trait TypedActivity extends Activity with TypedActivityHolder { def activity = this }

object TypedResource {
  implicit def view2typed(v: View) = new TypedViewHolder { def view = v }
  implicit def activity2typed(act: Activity) = new TypedActivityHolder { def activity = act }
}

The TR object defines typed source objects for all XML defined widgets and some traits to be reused in activity classes and views. Once the TR class is generated by sbt we can use the TypedActivity trait (more about traits in a short moment) to reference our UI widgets in a type-safe way:

class HomeActivity with TypedActivity {

   override def onCreate(savedState: Bundle) {
      super.onCreate(savedState)

      val usernameEditText = findView(TR.usernameEditText)
      val passwordEditText = findView(TR.passwordEditText)
      val loginButton = findView(TR.loginButton)

      // ...
   }
}

In case you are wondering where the findView method comes from, it is defined by TypedActivity. In comparison to the Java implementation we have saved the type casts. Now let us register the button click listener.

class HomeActivity with TypedActivity {

   override def onCreate(savedState: Bundle) {
      super.onCreate(savedState)
      setContentView(R.layout.home)

      val usernameEditText = findView(TR.usernameEditText)
      val passwordEditText = findView(TR.passwordEditText)

      val loginButton = findView(TR.loginButton)
      loginButton.setOnClickListener(new View.OnClickListener() {

       override def onClickListener(View view)  {
           startActivity(new Intent(HomeActivity.this, classOf[NextActivity]))
         }
       })
     }
}

OOOOkay – there is not much difference compared to the Java implementation, that’s true. But now comes the interesting part. Scala provides certain languages features which allow you to greatly reduce code. And here comes a list with my top-five favorite Scala language features.

Please note that I do not consider myself being a Scala expert – I would say I have average Scala knowledge. There might be better ways that lead to better results, please feel free to post them in the article’s comment section!

Favorite 1: Lazy Vals

As you can see in the code sample above, we have still the burden to use findView in the onCreate method. If we wanted other methods to access these references we would have to introduce instance variables, which again increases our LOCs. We can avoid that circumstance by using so-called lazy vals. In fact, Scala provides a keyword for specifying lazy attributes: not surprisingly, lazy.

class HomeActivity with TypedActivity {

   lazy val usernameEditText = findView(TR.usernameEditText)
   lazy val passwordEditText = findView(TR.passwordEditText)

   lazy val loginButton = findView(TR.loginButton)

   override def onCreate(savedState: Bundle) {
      super.onCreate(savedState)
      setContentView(R.layout.home)

      loginButton.setOnClickListener(new View.OnClickListener() {

       override def onClickListener(View view)  {
           startActivity(new Intent(HomeActivity.this, classOf[NextActivity]))
         }
       })
     }
}

This makes all UI element lookup operations lazy, meaning that the widget reference is looked up only once on first access during runtime. If the lazy instance variable is not accessed, the findView method will not be executed, therefore saving lookup operations.

In the example above, we could even further defer the registration of the OnClickListener:

class HomeActivity with TypedActivity {

   lazy val usernameEditText = findView(TR.usernameEditText)
   lazy val passwordEditText = findView(TR.passwordEditText)

   lazy val loginButton = {
      val b = findView(TR.loginButton)
      b.setOnClickListener(new View.OnClickListener() {

       override def onClickListener(View view)  {
           startActivity(new Intent(HomeActivity.this, classOf[NextActivity]))
         }
       })

       b
   }

   override def onCreate(savedState: Bundle) {
      super.onCreate(savedState)
      setContentView(R.layout.home)
    }
}

Favorite 2: Implicit type conversions

Wouldn’t it be nice to implement the View.OnClickListener interface with a Scala function, like that

     loginButton.setOnClickListener((v: View) => startActivity(new Intent(HomeActivity.this, classOf[NextActivity])))

To be honest, in a real world example you would have to enclose the functions body with curly braces (the example uses a single statement in the function body), but at least we got rid of the method interface declaration.

The code above can be left as it is, by introducing an implicit type conversion.

implicit def function2ViewOnClickListener(f: View => Unit) : View.OnClickListener = {

   new View.OnClickListener() {
     def onClick(view: View) {
       f(view)
     }
   }

}

As long as the implicit conversion is in the appropriate scope every function from source scope View to target scope Unit will be automatically converted to an instance of the anonymous class implementing the View.OnClickListener interface. Of course there are bunch of interfaces to write implicit conversions for, in my first Scala Android project I put them all in a trait to reuse them accross activities.

Favorite 3: Traits

A Java interface is very abstract. It is as abstract as an interface can be (even the interface contracts are omitted ). An abstract class is better in a way that it can provide method implementations, but than the problem swaps over to single inheritance as you can’t use multiple abstract classes as parent classes.

When your classes are defined in a framework context, this gets a real problem because the single inheritance line is most of the time already reserved for framework descending classes, meaning that custom classes extending from framework classes can’t extend custom classes anymore. That reuse restriction causes by single inheritance strikes me with its full power in my Java-based Android projects.

Let us assume that we need to extend both, class Activity and class ListActivity. Since the framework and Java’s single inheritance mechanism forces us to extend both activity classes, there is no way to extend from a common OptionsMenu base class that uniformly creates the application options menu.

With Scala we can create a so-called trait. A trait can be imagined as an abstract or concrete class that can be mixed into another class. A Scala class can mix-in several traits, but can only extend from a single descendant class. The Scala guys to to speak of “mix-in classes” instead of “multiple inheritance of classes” since traits differ in some ways from how multiple inheritance is implemented in other programming languages.

A trait for the OptionsMenu could be written as:

trait OptionsMenu extends Activity {

  override def onCreateOptionsMenu(menu: Menu) : Boolean = {
    menu.addSubMenu("Test")

    true
  }
}

The trait can now be used in all classes that directly or indirectly extend from Activity – and this includes ListActivity!

class NextActivity extends ListActivity with OptionsMenu {

  // ...
}

Another example would be further shortening the code for our HomeActivityby providing a base trait that extends from TypedActivity and the newly created OptionsMenu trait.

trait Activity with TypedActivity with OptionsMenu {

  lazy val usernameEditText = findView(TR.usernameEditText)
  lazy val passwordEditText = findView(TR.passwordEditText)
  lazy val loginButton = findView(TR.loginButton)

  val contentView: Int

  val init: Unit

  override def onCreate(savedInstanceState: Bundle) {
    setContentView(contentView)

    init
  }
}

Wit the base class shown above the HomeActivity can be minimized to the following code piece.

class HomeActivity extends Activity {

  val contentView: Int = R.layout.activity_home

  val init = {
    loginButton.setOnClickListener( (v: View) => startActivity(new Intent(HomeActivity.this, classOf[NextActivity] )))
  }
}

If we compare this class with our initial Java class in the first source code example, you’ll see that with the help of lazy vals, implicit conversions and traits we already reduced the source code to a great extent.

Favorite 4: Pattern matching and Case Classes

If you have ever taken a look at Erlang you’ll have with no doubt a clear picture of how integral pattern matching can be a very characteristic programming language property. Scala provides various pattern matching mechanisms by providing the match and case keywords.

override def onCreateDialog(dialogId: Int) : Dialog = {
   dialogIg match {
     case SHOW_ALERT_DIALOG => // create the dialog instance
     case _ => throw new IllegalArgumentException("Dialog " + dialogId + " could not be created!")
   }
}

Pattern matching in Scala is mighty. It does not work for integer values only, it works for strings and various other types [5]. A special case of pattern matching can be realized with so-called case classes.

A case class defines an immutable type with a pre-generated toString/hashCode/equals method implementations, a factory apply method, and automatic val prefixing.

Case classes can be used like good-old records in several corners of the Android framework, e.g. for implementing a view holder.

case class ViewHolder (checkBox: CheckBox, textView: TextView)

Conclusion

Scala does not aim to be an evolutionary successor of the Java programming language. It is a functional and object-oriented language with its own type system, features and – hard to grasp for hardcore Java hackers at first sight – its own language syntax. On the other hand, the Android SDK is a Java-based framework, naturally using Java concepts and patterns found in other Java frameworks. Scala provides neat features to greatly reduce framework clue code allowing to concentrate on application logic and domain classes.

You can find the article’s source code examples at Github [6].

[0] The Groovy Programming Language – http://groovy.codehaus.org/
[1] Learning Scala – http://www.scala-lang.org/node/1305
[2] Giter8 Templates – https://github.com/n8han/giter8#readme
[3] SBT Scala Simple Build Tool – https://github.com/harrah/xsbt/wiki
[4] SBT Android Plugin
[5] Scala Pattern Matching – http://www.scala-lang.org/node/120
[6] Scala Android Examples – https://github.com/andresteingress/scala-android-examples