Fork me on GitHub

Tuesday, April 22, 2014

Android API 8 is incompatible with mutable collections from Scala 2.11

I've found that newly introduced class scala.collection.mutable.AnyRefMap and mutable.LongMap, which uses java.util.Arrays.copyOf(...) functions, that is available only on Android API level 9 and above. This means your Android app might not work with Froyo devices if you build it with Scala 2.11. Because the current market share of the API level < 9 is less than 1 percent, this limitation is not serious.

However, if you stick to support older Android devices, here is a workaround:
  • Add -dontwarn scala.collection.mutable.** in your proguard settings.
  • Do not use scala.collection.mutable.LongMap and mutable.AnyRefMap. Make sure these classes not be called in transitive way.

Sunday, April 20, 2014

Scaloid 3.3 is released

Today I released Scaloid 3.3. This version achieves some feature enhancements including:

Scala 2.11 support

Scala 2.11 is out! We release this version of Scaloid in both of Scala 2.10 and 2.11.

Press-and-Hold action

We support press-and-hold action listener for any subtype of android.view.View object.

Any return type of event listener is accepted

Please refer to issue #78

Scaloid is released to central maven repository.

For a maven project:
or for an sbt project:
libraryDependencies += "org.scaloid" %% "scaloid" % "3.3-8"

Saturday, April 19, 2014

Press-and-hold action on Android

Sometimes we need to receive repeated callback when a user pressing a button continuously. For example, when we make a number picker, press-and-hold on "+" button will constantly increase the number.

Android does not support this explicitly, but we can handle this behavior with postDelayed event. Here is a link to a code snippet doing this:

This works fine, but a little remaining problem is that this code should be encapsulated to be reused in other places. I wrote the following trait doing the encapsulation:

trait PressAndHoldable {
  def basis: android.view.View

  class PressAndHoldListener(interval: Int, onPressed: () => Unit) extends View.OnTouchListener with View.OnLongClickListener {
    var autoIncrementing: Boolean = false
    private val repeatUpdateHandler = new android.os.Handler()

    override def onTouch(v: View, event: MotionEvent): Boolean = {
      if (event.getAction == MotionEvent.ACTION_UP && autoIncrementing) {
        autoIncrementing = false

    override def onLongClick(p1: View): Boolean = {
      autoIncrementing = true RptUpdater)

    class RptUpdater extends Runnable {
      override def run() {
        if (autoIncrementing) {
          repeatUpdateHandler.postDelayed(this, interval)

  def onPressAndHold(interval: Int, onPressed: => Unit) {
    val listener = new PressAndHoldListener(interval, () => onPressed)

This trait is added on Scaloid 3.3 release. So you can just use onPressAndHold method for any android.view.View objects:
val num = STextView("0")
SButton("Increase").onPressAndHold(100, num.text = (num.text.toString.toInt + 1).toString)

Saturday, February 1, 2014

Scaloid 3.2 is released

Today I released Scaloid 3.2. This version achieves some feature enhancements including:

Properly handle TableLayout

Enriched android.database.Cursor

Now we can access database in more functional style.

px2sp and px2dip

We can simply convert pixel unit into sp unit or dip unit.
32.px2dip  // convert 32 pixel into dip unit

Scaloid is released to central maven repository.

For a maven project:
or for an sbt project:
libraryDependencies += "org.scaloid" %% "scaloid" % "3.2-8"

Simple enhancements on accessing Android built-in Sqlite

Functional programming rocks. However, legacy Java libraries prevent us to stay in such an ideal world. The job objective of Scaloid is to help write Android code in more elegant style. Although Scaloid doing good job on layout building, I haven't do much things about databases yet.

There are many DB frameworks for Scala. If you writing an app relying on DB extensively, I recommend to use one of them. But when you are using the built-in Sqlite just for storing some casual data, it is not a bad idea that using Android APIs for database access. The biggest problem in this case is that the code is not neat, because of its API architecture. Let's see a common example:

def readDailyPractice(query: String, params: Array[String]) = {
  var dailyTime: List[DailyPractice] = List()
  val c = getReadableDatabase.rawQuery(query, params)
  try {
    while (c.moveToNext()) {
      dailyTime = dailyTime :+ 
        new DailyPractice(c.getString(0), c.getString(1), c.getLong(2))
  } finally c.close()

We have to use variable for the return object because the android.database.Cursor does not provide Scala-compatible iterator. Another clutter is close() call in try-finally section. This can be reduced in more functional-style:

def readDailyPractice(query: String, params: Array[String]) = 
  getReadableDatabase.rawQuery(query, params).closeAfter( => 
    new DailyPractice(c.getString(0), c.getString(1), c.getLong(2)).toList)

By declaring implicit def cursor2RichCursor(c: Cursor) = new RichCursor(c), or extending the trait org.scaloid.common.DatabaseImplicits to your class, The android.database.Cursor implicitly converted into RichCursor, which implements Iterable[Cursor]. Now, we can use many useful iterator methods such as map, foreach, and foldLeft.

I also introduce a function closeAfter[T](body: RichCursor => T):T that closes the cursor after evaluating its parameter.

One of the important thing that can be missed is to convert the mapped result into a List. returns another Iterator that evaluate the original iterator(RichCursor in this case) on demand. The implementation of looks like this:

def map[B](f: A => B): Iterator[B] = new AbstractIterator[B] {
  def hasNext = self.hasNext
  def next() = f(

So if we missed to convert the iterator to List or other form, newly created Iterator generated from the mapping will evaluate the Cursor that is already closed, and vomit the exception. This issue is too detailed, and very easy to miss at first. What we just need is iterate each rows and map a row with a domain object, and forget about cursor. So I created a wrapper function that does this mission simply:

def readDailyPractice(query: String, params: Array[String]) = 
  getReadableDatabase.rawQuery(query, params).orm(c => 
    new DailyPractice(c.getString(0), c.getString(1), c.getLong(2)))

As the name of the function implies, it does very simple form of Object-Relation-Mapping.

In other cases, we often need just one record from the query result. For example, getting count of something, or retrieving some column about a particular user. Even such a simple requirement, we have to write a verbose code as:

def readOneRecord(query: String, params: Array[String], default: String) = 
  try {
    val c = getReadableDatabase.rawQuery(query, params)
    if (c.moveToFirst()) c.getString(0) else default
  } finally c.close()

I created a helper method toString(defaultVal) for this purpose. We can rewrite the code above as:

def readOneRecord(query: String, params: Array[String], default: String) = 
  getReadableDatabase.rawQuery(query, params).toString(default)

Other accessors, toShort, toLong, toInt, toFloat, and toDouble is available as well.

All of these magic can be done by the implicitly converted class RichCursor. The source code of RichCursor is very simple.

class RichCursor(c: Cursor) extends Iterable[Cursor] {
  def iterator = new CursorIterator

  class CursorIterator extends Iterator[Cursor] {
    def hasNext = c.getPosition < c.getCount - 1

    def next() = {

  def closeAfter[T](body: RichCursor => T) = try body(this) finally c.close()

  def orm[T](body: Cursor => T) = closeAfter(

  def toLong(default: Long): Long = closeAfter(csr => if (c.moveToFirst()) c.getLong(0) else default)

  // definitions of toString, toShort... is straightforward

This class is also available on Scaloid 3.2.1

Thursday, November 28, 2013

Scaloid 3.0 is released

Today we are pleased to announce Scaloid 3.0. Some new feature highlights are as shown below:

Redesign of LocalServiceConnection

LocalServiceConnection is redesigned to use Option, and prevents possibility of NullPointerException, which was very frequent when accessing service with LocalServiceConnection.

This is a breaking change in source code level. Please migrate the code as introduced in a blog post below:

Changed SImageView(r: Int) to SImageView(r: Drawable)

We believe that source level compatibility is not broken. However, rebuild is required because the parameter signature is changed.

SPaint support

We added an initial attempt to embrace graphics feature of Android API. Please refer to this blog post for a design principle behind this addition.

For a maven project:
or for an sbt project:
libraryDependencies += "org.scaloid" %% "scaloid" % "3.0-8"

Sunday, November 17, 2013

Usage driven design - choosing parameters

Scaloid is originally made to improve my daily life that codes Android apps. Although Scaloid relies on some core design principles that is behind of automatic wrapper generator, sometimes code can be improved from some heuristics. For example, I found that my code has several functions much like this:

def createMyPaint(): Paint = {
    val p = new Paint()

Soon I added a wrapper class of to Scaloid. Then the code above is improved as:

def createMyPaint() = SPaint().color(0xffff6666).textSize(14.sp)

All of my codes and a Google search reveals that setColor() is always called after a new Paint instance is initialized. It is very natural to think about a color when we tried to paint something. So I added it as the first parameter of the method SPaint.apply(); then the code can be rewritten as:

def createMyPaint() = SPaint(0xffff6666).textSize(14.sp)

We have reached the minimum code as possible.

This feature is shipped with Scaloid 3.0-M2. You can include this version of Scaloid into a maven project by:
or a sbt project by:
libraryDependencies += "org.scaloid" %% "scaloid" % "3.0-8-M2"