As I've mentioned in my previous blog post, I am working on several Android projects. Once you've done some larger projects and you have already worked with alternative JVM languages like Groovy  or Scala , one quickly feels the need for reducing common code patterns found in every Android project. That was the main reason I chose to use Scala as main programming language for one of my free-time Android projects.
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 and worked with the following package/software versions:
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  you can use a giter8 template  to jump-start with an sbt supported project structure holding an empty Android application and test setup (for more information see ).
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.
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:
Next we'll register a View.OnClickListener to react on button clicks/touches:
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.
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:
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.
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.
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:
Favorite 2: Implicit type conversions
Wouldn't it be nice to implement the View.OnClickListener interface with a Scala function, like that
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.
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:
The trait can now be used in all classes that directly or indirectly extend from Activity - and this includes ListActivity!
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.
Wit the base class shown above the HomeActivity can be minimized to the following code piece.
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.
Pattern matching in Scala is mighty. It does not work for integer values only, it works for strings and various other types . 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.
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 .