If course I may ignore your wishes anyway, cause I’m a lazy ass =). The Survey is below the stick-figures.

Chaos FTW

Best Organized Kitchen Ever?

In Scala I rarely use annotations. However when you need to interoperate with a framework which relies on annotations you need use them. So lately I wanted to store some simple case classes with JPA. As you know, JPA relies quite heavily on annotations, unless you move everything out to XML descriptors.

I wanted to store something like this:

@Entity
case class MyStoredData(userName:String,
                         realName:String,
                         @Id id:Long =0) {
  // JPA requires a parameter-free constructor
  def this() = this("","")
}

Unfortunately this results in exceptions like the one below. Basically the annotation is not placed on the ‘field’ but rather on the parameter of the constructor.

Caused by: com.versant.jpa.enhancer.exceptions.MissingIdException: missing ID annotation or mapping for info.gamlor.vjpa.model.MyStoredData
	at com.versant.jpa.enhancer.JpaClassEnhancer.enhance(JpaClassEnhancer.java:123)
	at com.versant.jpa.enhancer.JpaClassEnhancer.enhance(JpaClassEnhancer.java:50)
	at com.versant.jpa.enhancer.JpaClassTransformer.transform(JpaClassTransformer.java:51)
	at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
	at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)

Now you actually can specify on which elements such an annotation is added. So in this situation we can tell the Scala to ensure that the annotation is also placed on the id field:

@Entity
case class MyStoredData(userName:String,
                         realName:String,
                         // ensure that the field is also annotated
                         @(Id @field) id:Long =0) {
  // JPA requires a parameter-free constructor
  def this() = this("","")
}

This will fix the issue. There are more possible targets, like Scala accessors and Java Beans getter/setters for @BeanProperty annotated fields. Take a look at the documentation here.

That’s all. Nothing more to tell =)

Relational Stuff fits Scala well

A while back I needed to read some data from a relational database in Scala. What I wanted was a small library, which removes most of the JDBC boiler plate, but not a full blown ORM. I ended up using is ScalaQuery.

This library gives you a thin, rational layer on top of JDBC. This is how it works. First you define a ‘table’. This is done extending a table class and adding field definitions to it:

val ApiKeys = new ExtendedTable[(String, String)]("googleApiKeys") {
	def deviceId = column[String]("deviceId", O.PrimaryKey)

	def apiKey = column[String]("apiKey")

	def * = deviceId ~ apiKey
}

Afterwards you need to create a database instance:

val database: Database = Database.forURL("jdbc:h2:~/apiKeyStore", driver = "org.h2.Driver")

To do an operation we need a transaction / session. On way to create such a session is to use the withSession method. Basically all operations require a session. We can manually pass the session to the methods. Or we can declare an implicit session which is used. For example the built in thread local session:

// We use the thread local session management
// So we import this implicit parameter which returns the current session
// Of course we pass any other session / use our own implicits
import org.scalaquery.session.Database.threadLocalSession


// and we do stuff in our session
database withSession {
  // do stuff
}

For example we can create the database schema:

database withSession {
    ApiKeys.ddl.create
}

Now to the important part: We can query and update data with our table object. The cool thing is that we just can use the Scala for-construct to do so. The library will transform our code into the appropriate SQL statement. Everything lives in the ‘Scala’ world, no strings and casts etc. are required. Also not that some imports are required for these API features:

// Imports for the query API
import org.scalaquery.ql.extended.H2Driver.Implicit._
import org.scalaquery.session.{Session, Database}
import org.scalaquery.ResultSetInvoker
import org.scalaquery.simple.StaticQuery
import org.scalaquery.ql.Query


// Query
val devicesByApiKey = for {
	a <- ApiKeys if a.deviceId.like(deviceId)
} yield a.apiKey

// Do stuff with the result
devicesByApiKey.foreach(i=>doStuff(i))

We also can insert and update tables:

val devicesByApiKey = for {
	a <- ApiKeys if a.deviceId.like(deviceId)
} yield a.apiKey

devicesByApiKey.firstOption match {
	case None => {
	  ApiKeys.insert(deviceId, googleKey)
	}
	case Some(_) => {
	  query.update(googleKey)
	}
}

My Opinion & State of the Library

I really like the approach of this library. It is lightweight, close the SQL-metal and yet it blends perfectly with the Scala code. It really doesn’t feel like you entering into a new domain when talking to the database. It only surfaces operations which work in SQL and doesn’t do any operations behind the scenes. For many use cases this works way better than heavy weight ORM frameworks.

However I have to point out that many features are not there and there doesn’t seem any active development going on. For example you cannot check if a table already exists before calling the ‘create schema’ method. I also miss a nice method for using raw SQL in case you need a missing feature.

So right now I only would use it for pet projects, or when you are willing to invest your time to patch and improve things.

Akka 2.0 is available as a preview version. Here’s a short guide how to get it to run on Android. This pretty much work in progress. Maybe someone else has even has a better strategy. Let me know if that’s the case=). Also I didn’t do much with Akka 2.0 on Android yet, so maybe there are major issues yet to discover =).

Let's master this Akka-beast, little Android =)

In general I just assume that you have a working Scala build and know how to include new Scala libraries. And I also assume that you are using Proguard to shrink the jar file. I use a build based on this. In case you are having trouble, just ask for help =).

First add the Akka 2.0 M3 jar-file to the project (The M2 bits won’t work). Make sure that it is in your directories of libraries which are compacted by Proguard. Unfortunately you will get tons of warnings by Proguard about classes which couldn’t be found, because they are not part of the Android platform. These are three categories of classes which are not available:

• ‘ akka.util.JMX’: There is no JMX on Android.
• ‘sun.misc.Unsafe’: Well at first sight Android doesn’t have this implementation-detail class. Luckily it actually does have it (at least in newer versions), but it’s only available at runtime. The jars which you compile against do not have this class.
• ‘org.omg.CORBA’-stuff. The Akka library has a UUID implementation which implements some interfaces from CORBA.

So it is time for some Proguard trickery to get rid of warnings.

Bye Bye JMX

Well there is definitely no JMX on Android. So I just excluded the JMX stuff from Akka:

## No JMX for Android
-dontwarn akka.util.JMX*

Ignoring ‘sun.misc.Unsafe’ Warnings

The next step is to configure Proguard to ignore the ‘sun.misc.Unsafe’ warnings. It is there on the device (If not, please tell me).

## Unsafe is there at runtime
-dontwarn sun.misc.Unsafe
-keep class sun.misc.Unsafe{
    *;
}

Fixing the CORBA Stuff

## UUID helpers are not used
-dontwarn com.eaio.uuid.**

Remove the FSM Forward Reference

The core Akka library contains a forward reference to its finite state machine (FSM) implementation. In a usual class loader environment this doesn’t matter, since classes are lazily loaded. However Proguard is going to bitch about it. So in case you are not using the FSM library remove that reference with Proguard:

## No Finate State Machines Support needed
-dontwarn akka.actor.FSM

Keep Important Classes

Also we need to keep some classes which are loaded at runtime. Maybe there are more required for some features, just watch for class loader errors. These are the ones you need for sure:

## Stuff referenced at runtime
-keep public class akka.actor.LocalActorRefProvider {
   public <init>(...);
}
-keep class akka.event.Logging*
-keep class akka.event.Logging$LogExt{
    *;
}

Work Around the Reference Configuration Issue?

I’m not sure what exactly the issue is here and probably I’m doing something wrong. At least with my setup Akka cannot find its internal reference.conf resource file. Looks like resources are only loaded from the *.apk file? Anyway, for now I just copied the reference.conf file from the Akka source code to my project (Or do it with a build task). Then everything runs.

Conclusion

Yes, it is a little hairy to get Akka 2.0 to run on Android. I certainly will work a little more on it. And in case it gets too bad I’ll do a shallow fork of Akka .

Void Is Not Cool Enough

In my code I often end up doing something like this:

class Example
{
	// Stuff like transactions, run in contexts, binding methods etc etc.
	public T WithSomeContext<T>(Func<T> runInContext)
	{
		// do magic and stuff
		var result = runInContext();
		// do other stuff
		return result;
	}

	// Doublicate to also accept Void returns
	public void WithSomeContext(Action runInContext)
	{
		WithSomeContext<object>(() =>
			{
				runInContext();
				return null;
			});
	}

	public void UseIt()
	{
		var valueOne = 1;
		var valueTwo = 2;
		// with return value
		var sum = WithSomeContext(() => valueOne + valueTwo);

		WithSomeContext(() => Console.WriteLine("Hi-There"));
	}
}

That’s just boilerplate which I really don’t need. In many other languages, for example Scala, this is handled more elegantly. The void-type (often called Unit) is a regular type. And void/unit values just represent ‘void/unit‘:

class Example{

  def withContext[T](runInContext:()=>T):T ={
            // do magic and stuff
            val result = runInContext();
            // do other stuff
            return result;
  }
  
  // no need for another method. 
  // Our withContext also can accept 'void'-returns aka Unit 

  def useIt() {
    val valueOne = 1;
    val valueTwo = 2;
    
    var sum = withContext(() => valueOne + valueTwo);

    withContext(() => println("Hi-There"));

  }
}

Yes, I know, it’s not the end of the (programming) world. There are tons of other issues which lead to more boiler-plate. Anyhow, it is such a little thing and still so god damn annoying. God help us that no new programming includes the same little weakness =).

It feels like it can be the back-bone of an application, even when you use it to organizing big chunks of distinct functionality. When you start a project / experiment now start with Akka 2.0! It’s a much better experience than 1.2!

Akka 2.0

What I Really Like About it

• No god damn Singleton anymore. In Akka 1.2 the configuration and the remoting instance where hard wired Singletons. That made it really annoying to set up elaborate test cases, shut down the system cleanly etc. In Akka 2.0 you can start up as many ‘ActorSystem’-instances as you want, each one with its own configuration, setup etc.
• Supervision is mandatory and easier to configure. In Akka 1.2 you can create actors without any parent and supervision. This basically also meant that errors just ‘disappeared’ and you only noticed stuff the log. In Akka 2.0 a supervision hierarchy is enforced. Error are past up to the appropriate supervisor. If you don’t specify anything the error basically will end up at the top level actor system.
• The path-system. Now actors are basically addressed by file-system like paths. This is handy to get to the right actors. It’s also handy for error-logs: Instead of a cryptic UUID you get a ‘human-readable’ path.
• Streamlined API. Nearly all API’s have been improved and streamlined.

Supervision Mandatory

What I Don’t Like About It

• Many, many breaking changes in the API, behavior etc. Of course all these fundamental improvements are not possible without breaking the API. However, porting stuff to new API’s is just no fun work.
• The core jar is larger. Not a big deal for most cases, except for Android. Anyway, I run everything through Proguard anyway. And I believe that the internals got more efficient. =)

Akka 2.0 is a tiny bit larger (and a lot stronger)

Akka-Mobile and Akka 2.0

In general I’m stabilizing my Akka-Mobile code right now and fix some catastrophic bugs. After that I certainly will move everything to 2.0. I’m not planning to keep it on the 1.2/1.3 release. This is the plan:

• Stabilize stuff.
• Move to Akka 2.0
• Write documentation and a tiny demo App
• Keep on improving the thing =)

Ok, this was kind of a lazy ass blog-post. For more information go the Akka-blog & Snapshot-documentation.

First Look at Code

The Server

First let’s start a server. This is easily done by calling NettyRemoteServer.start() which starts up the server and listens to the specified port. Don’t confuse this with the regular Akka 1.2 remote actors. The mobile actors will use their own server-implementation. That’s also quite intentional: We want to expose only certain ‘service’ actors to our mobile clients and keep the rest internal to our cluster / internal infrastructure.

After that we can register regular actor to the given server instance. These actors then are reachable by the mobile clients under the given id. For example a ultra simple actor which just echoes the request:

val chatServer = NettyRemoteServer.start(2552);

chatServer.register("chat-service", Actor.actorOf[ChatServerActor])


class ChatServerActor extends Actor{
  protected def receive = {
    case msg =>{
       self.reply("Answer for: "+msg)
    }
  }
}

Well that’s not very exiting. It’s nearly identical to the regular Akka 1.2 remote actor.

On The Android Device

Now let’s move on to the Android device. The first thing we need to do is to get Scala running =). Then we start with a normal ‘main’ activity. Optionally we can use the trait ‘ActivityActor’ which turns our activity into an actor. Any message send to the activity will be dispatched on the ‘activity’ thread, so that we can update the UI etc. Like this:

class AkkaDroidActivity extends Activity with ActivityActor {

  override def onCreate(savedInstanceState: Bundle) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main)
    
    actorOf[DoSomeWork].start()
  }

  protected def receive = {
    case WorkDone(happend) => {
      val inputTextBox = findViewById(R.id.enterMsgBox).asInstanceOf[EditText]
      inputTextBox.setText("happend")
    }
  }
}

case class WorkDone(result:String)

class DoSomeWork extends Actor{

  protected def receive = {
    case "Start" =>{
      val result = workForAWhile()
      self.reply(result)
    }
  } 
  
  private def workForAWhile() :String ={
    // work work 
    "work-done"
  }
}

Remote Actors

For remote actors we need a client instance, usually one per application. When creating such an instance we need to pass in a Android context, which allows the remote implementation to get to Android resources. The other arguments are optional or loaded from the configuration.  I’ve put my remote instance in the global application object which is then registered in the Android manifest.

// Registred in the AndroidManifest as our application object
class MyApplication extends android.app.Application {

  lazy val remote = MobileRemoteClient.createClient(
    AndroidDevice(this))

}

In the akka.conf we specify the host, port and preferably the Logcat logger:

akka {
  event-handlers = ["akka.mobile.android.LogcatLogger"]
  event-handler-level = "DEBUG" # Options: ERROR, WARNING, INFO, DEBUG

  mobile{
      client{
          host = "our.server.host"
          port = 2552
      }
  }
}

After that we can get references to actors on the server by name and send messages to them. So we now can communicate with the actors on the server. Nice =)

class ChatClientActor extends Actor{

  protected def receive = {
    case SentToServer(msg) =>{
	  val chatService = MyApplication.remote.actorFor("chat-service")
      chatService ! msg
    }
    case MessageFromServer(msg) =>{
      // well, show the message or do what is needed	
    }

  } 
}

‘Push’-Messages

So far so good, we’ve connected from the Android device to the server, got a reference to it and started communicating with it.

But what if the server wants to initiate the communication with a client? To do that we register an actor on our remote instace! The server will later be able to contact this client-actor by its name:

The first thing we need is an ‘address’ for a client. Since mobile devices are on the move, they don’t permanent IP address. Akka mobile provides a ‘clientId’ as a replacement. You can get that id in multiple way. For example when a server-side actor is communicatong with a Android device the self-reference will contain this client id. With the trait ServiceActor you get a nice accessor:

class TalksToMobileDevices extends Actor with ServiceActor{
  protected def receive = {
    case msg =>{
       self.reply("Answer for: "+msg)
       val clientId = this.clientId;
       if(clientId.isDefined){
           // store it in database. So that you later can talk to this client
       }
    }
  }
}

As soon as we have a client id  we can get an reference for an actor running on the device and start sending messages to it.

val clientId = // clientId. Like from the database
val serviceOnPhone = chatServer.actorOf(clientId, "notifications")
serviceOnPhone ! "Hi Phone"

Pushing Messages to the Client

But Wait, What if the Device is Offline?

Now the stuff I’ve showed so far only works as long as the Phone has a connection to the Server. What if the Phone is offline? Or the application isn’t running. Well here’s where the C2MD integration comes in. Akka mobile can deliver messages via C2MD. Here’s a short overview how it works.

Preparation on the Server

First we need to configure the Server to support C2MD: We need to add two things: The C2MD authentication key for talking to the C2MD servers and a database backend. The database backend is required to store the registration ids of all devices.

So in the akka.conf configuration we add:

akka {
  event-handlers = ["akka.mobile.android.LogcatLogger"]
  event-handler-level = "DEBUG" # Options: ERROR, WARNING, INFO, DEBUG

  mobile{
      client{
          host = "our.server.host"
          port = 2552
      }
      c2md{
          email="the-c2md-email@thecompany"
          register-mode = "AUTO" # Possible values: MANUAL, AUTO, default is MANUAL
      }
  }
}

And we start the server with a given database :

val chatServer = NettyRemoteServer.start(port=2552,
    database = Some(new H2Database("jdbc:h2:~/apiKeyStore")));

Preparation on the Client

On the client we also update the akka.conf. We add the email for which the C2MD service is registered:

akka {
    mobile{
        c2md{
            key="Your Application Key for C2MD"
        }

    }
}

Additionally we need a broad cast receiver which handles the C2MD intents. We inherit the ‘C2MDReceiver’ -trait and implement the ‘remoteClient’ method. In that method we return our instance of the akka-mobile remote client which our application is using. In this example I’ve that instance  in the application object and get it from there (via ugly cast, don’t hit me).

class DispatchToAkka extends C2MDReceiver {
  def remoteClient(context: Context) = {
    context.getApplicationContext.asInstanceOf[MyApplication].remote;
  }
}

In the Android Manifest you need to get the permissions for C2MD and register the broadcast receiver previously created:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="info.gamlor.akkamobile"
          android:versionCode="1"
          android:versionName="1.0"
          android:debuggable="true">
    <uses-sdk android:minSdkVersion="10"/>

    <permission android:name="info.gamlor.akkamobile.permission.C2D_MESSAGE" android:protectionLevel="signature"/>
    <uses-permission android:name="info.gamlor.akkamobile.permission.C2D_MESSAGE"/>
    <uses-permission
            android:name="android.permission.INTERNET"/>
    <uses-permission android:name="com.google.android.c2dm.permission.RECEIVE"/>

    <application android:name=".MyApplication" android:label="@string/app_name" android:icon="@drawable/icon"
                 android:debuggable="true">
        <!-- Activities etc -->

        <!-- Our Broadcast receiver for integration C2MD with akka-mobile -->
        <receiver android:name=".DispatchToAkka"
                  android:permission="com.google.android.c2dm.permission.SEND">
            <intent-filter>
                <action android:name="com.google.android.c2dm.intent.REGISTRATION"/>
                <category android:name="info.gamlor.akkamobile"/>
            </intent-filter>
            <intent-filter>
                <action android:name="com.google.android.c2dm.intent.RECEIVE"/>
                <category android:name="info.gamlor.akkamobile"/>
            </intent-filter>
        </receiver>
    </application>
</manifest> 

After that akka mobile is ready to use C2MD. It will register the application automatically and report its registration-id to out server as soon as the remote-instance is created. Or you can optionally disable the auto-registration and use ‘requestC2MDRegistration()’ to start the C2MD registration at a certain point in time.

Sending a Message over C2MD

Now messages are still not sent with C2MD if no connection is available. The reason is that akka-mobile wants to prevent that we send hundreds of messages via C2MD by accident. We should be very careful and only sent important notifications over C2MD. There are two ways to achieve that.

One is to use the marker-trait  ’SentThroughC2MDIfNoConnectionIsAvailable’  in your message. If a message implements this trait it will be delivered via C2MD if no connection is found.

case class ImportantNotification(msg:String) extends SentThroughC2MDIfNoConnectionIsAvailable

The other possibility is by using a ‘error’-handler which falls back on C2MD if no connection can be established. However I explain error-handlers next time, since they are quite central to the whole communication stack.

Stuff Still To Implement for a Proper Prototype

So, that the first look at how akka-mobile will work. There still tons of things to do. Also very basic stuff:

• Improve stability, test-suite and build-process.
• Better integration with Android, especially the connection-manager. Maybe also with power management.
• ‘Session’ actors on the server
• Better serialization story. Currently only Java Serialization is supported. Java serialization always makes me nervous.
• Error-Handler API has to improve, a lot. More about that next time.
• Do some basic performance analysis.
• Finally start on ‘cool’ features….

Otherwise I’ve tons of other features I want to tackle, but those above are really needed to get to a more stable state.

Lot's of Things to Do

Conclusion and Next Time

So we’ve seen how we can setup the akka mobile remote actors. It allows us to have nice device to server communication between actors. It also allows us to fall back on C2MD messages when a client doesn’t have a connection to a server.

Next time I’m going to talk about error-handlers. These are responsible for managing connection loses etc.

Client-Server Oriented Remote Actors

The regular Akka remote actors in Akka 1.2 have an almost ‘symmetric’ implementation. To get the full ‘send’, ‘reply’ behavior you have to start up a full Netty server on the ‘client’ and the ‘server’. And with the upcoming Akka 2.0 clustering this won’t change that much.

In a mobile-device scenario this is bit different. We have a clear distinction: A small, lightweight application which is the client and a server (-cluster) which runs the service. The client should be small and lightweight and usually maintains one connection to the server. The server can be large, but needs to maintain many connections to many devices.

Furthermore a connection is only in one way, from the client to the server. The server cannot directly contact a client. The client has almost certainly a dynamic, no public IP which changes a lot: Walking away from your Wi-Fi at home to a mobile network to another Wi-Fi hotspot. For an implementation that means the client needs to able to reconnect on network changes back to the server. And the server needs to use the latest connection when he wants to reply to a client.

Bad Company for the Server

Unreliable Connections

The implementation needs to deal somehow with unreliable connections. I want to have a ‘supervisior’ hierarchy in place for this. For example the first layer just tries to reconnect immediately; the second layer waits a little to reconnect. The next layer it stores the message away for later or escalates the issue to the user etc. This should be configurable of course.

Push-Notifications/Message from the Server

One thing I want have in Akka-Mobile is ‘push-notification’ support. Basically I want be able to send a message to a mobile device and let the device react to it. The server maintains a database of known mobile devices. When he wants to notify a mobile device he grabs an Actor reference which represents that device and sends the message to the client. Then the implementation looks up if there’s an active connection available to that device. If that’s the case, it just sends the message to the device. Otherwise it will fall back to some other push-notification mechanism, for example the Android Cloud to Device Messaging Framework (C2MD).

Behavior Overview

Here’s a little sketch how it should work during active communication:

Communication With Akka Mobile

1. The Mobile Device / Client connects to the server, gets a reference to a remote actor, for example the actor “John” and sends a message to it.
2. The server associates TCP connection with the device id (here “Green Devil”) and the forwards the message to the right actor.
3. The actor does its thing. The actor can send as many messages back to the ‘sender’. It also can pass the actor reference to other actors and those actors can answer.
4. When a message has to go back to the mobile device the server implementation looks up if there still a connection to the mobile device…
5. …and sends the answers to the right actor on the mobile device.

Now what happens when there’s no connection from the mobile device to the server? That’s when the C2MD service comes in. Then a message is send via that service to tell the mobile device that there are answers available on the server. Of course the has to be some kind of configuration which types of messages are important enough to cause this behavior. So the behaviors changes at step 4:

Cloud To Mobile Device Integration

4. The server detects that there is no active connection to the client. So he has to fall back to alternatives.
5. He could issue a C2MD request to notify the client that there’s stuff available for him.
6. Let’s Google do its job
7. The client reconnects to get the answers/messages

Conclusion

Akka Mobile has to deal with the changing and unreliable network topography. That’s means tons of tedious implementation details and tons of work for me.

Anyway, next time I will show code and talk less =)

Scala on Android

The Build Script

So you need to include Proguard in your build script. There are different ways to do it. I tried several existing build scripts from different people with mixed results. Finally I’ve settled with a script from here. This site contains a description and steps you need to take.

Basically you can download the build-scala.xml and the proguard-template from that website. Then you add this task to the default build.xml, right below the ‘setup’-tag:

<setup />

<import file="build-scala.xml" />

<!-- Converts this project's .class files into .dex files -->
<target name="-post-compile" depends="-post-compile-scala" />

Of course you need to set the right paths in the local.properties file on your dev machines. For example on mine:

sdk.dir=C:\\progs\\android\\sdk

scala.dir=C:\\progs\\scala

Note that Proguard doesn’t like spaces and other special characters in file paths. I had trouble initially because of that. You either can ensure that everything is properly escaped or that you put everything in an appropriate location.

I also added a newer version Proguard to my project, because the version shipped with Android had some bugs. So in the build.properties I have:

# Current proguard location for this project
proguard.dir=./tools/proguard/

That’s all. Of course I’ve done some project specific modifications to the original build file. Anyway, when you follow the instructions of the original page you should be fine.

The IDE Setup

Of course the build script is only half the story. I want to use my IDE to edit and debug the code. I’m an IntelliJ user, so this is my IntelliJ setup. (I should check out Eclipse’s Scala support, I’ve heard that they put a lot of effort into it).

First create (or import) the project like a regular Android project. Then also add the Scala facetted to the project. Now in theory you can compile and run that project. Unfortunately the dexing step will fail due to the large Scala runtime.

Android and Scala Facette

Basically you need to replace the build step with your costume build step. I ‘unchecked’ the ‘make’ step in the run configuration and added an Ant step. Like this:

Run Configuration

You can run any Ant target which builds the .apk for you. The only thing you need to ensure is that IntelliJ finds the apk-file. I created a special ‘debug-install’ target which compiles the project and copies the apk to the location where IntelliJ usually puts it. An alternative would be to configure IntelliJ to use your location. Here’s the Ant-Task for my IDE debugging:

<target name="debug-install" depends="debug">
	<copy file="./bin/AkkaDroidApp-debug.apk"
		tofile="./out/production/AkkaDroidApp/AkkaDroidApp.apk"/>
</target>

After these steps everything should run in IntelliJ. When you use Run / Debug the Ant script will build the apk and IntelliJ will load it into the Emulator / Phone. Afterwards it just attaches to the process like normal. Everything should work, like the debugger etc.

Update For Android 4.0 SDK

With the 4.0 SDK the standard Android build file has changed, so that the original script above doesn’t seem to work anymore. You will get an error telling you that the build script is outdated. Here’s what I’ve done to get it to run:

• I followed the instructions of the error message. I deleted the existing build.xml and then upgraded the project with: ‘android update project –path ./’. (You need the android tools path in your PATH variable. Or use the complete path to the ‘android’ command of your SDK).
• Then I re.added my Scala tasks in the build.xml:
  

  <!-- version-tag: 1 -->
  <import file="${sdk.dir}/tools/ant/build.xml" />	
  
  <import file="build-scala.xml" />
  
  <target name="-post-compile" depends="-post-compile-scala" />

  view raw build.xml This Gist brought to you by GitHub.
• Unfortunately the ‘build-scala.xml’ file still had issues with the new SDK. I fixed two things. First the ‘compile-scala’ task new depends on ‘-compile’ instead of ‘compile’. I also removed the ‘<src refid=”project.libraries.src”/>’ entry. Looks like this property isn’t there anymore, but it wasn’t used anyway in my project. The compile-scala task look now like this:
  

  <target name="compile-scala" depends="-compile"
              if="contains.scala.sources" unless="do.not.compile"
              description="Compiles project's .scala files into .class files">
          <condition property="logging" value="verbose" else="none">
              <istrue value="${verbose}"/>
          </condition>
          <echo message="${scalac.banner}" level="info" taskname="scalac"/>
          <scalac
                  destdir="${out.classes.absolute.dir}"
                  bootclasspathref="android.target.classpath"
                  logging="${logging}" addparams="${scalac.addparams}"
                  classpath="${extensible.classpath}"
                  classpathref="jar.libs.ref">
              <src path="${source.absolute.dir}"/>
              <src path="${gen.absolute.dir}"/>
              <classpath>
                  <pathelement location="${scala-library.jar}"/>
                  <fileset dir="${akka-lib-dir}" includes="*.jar"></fileset>
                  <pathelement location=""/>
                  <!-- include compiled resources -->
                  <pathelement location="${out.classes.absolute.dir}"/>
                  <fileset dir="${extensible.libs.classpath}" includes="*.jar"/>
              </classpath>
          </scalac>
      </target>

  view raw build-scala.xml This Gist brought to you by GitHub.
• I added the property ‘manifest.package’ which holds name of the top package. Looks like this property isn’t defined anymore by the standard build. This property is used for Progard to keep those classes in your project. So for my project the ‘ant.properties’ file now looks like this:
  

  scalac.addparams=-deprecation
  proguard.dir=./tools/proguard
  manifest.package=info.gamlor.akkamobile

  view raw ant.properties This Gist brought to you by GitHub.
• The last change I’ve done is in the ‘-post-compile-scala’ task. Here the ‘build.mode.debug’ and ‘build.mode.release’ flags are no longer set. Instead the ‘build.target’ property contains the build type. So I’ve changed that in the ‘-post-compile-scala’ task:

  <target name="-post-compile-scala" depends="compile-scala" unless="do.not.compile"
  		description="Shrink project class files and Scala library into one .jar file">
  	<condition property="debug.mode" value="" else="#DEBUG#">
  		 <equals arg1="${build.target}" arg2="debug"/>
  	</condition>
  	<condition property="release.mode" value="" else="#RELEASE#">
  		 <equals arg1="${build.target}" arg2="release"/>
  	</condition>
  	<!-- priority is given to local ProGuard configuration if present -->

  view raw build-scala-second-change.xml This Gist brought to you by GitHub.

Second & Third Update

First I’ve fixed another thing above so that debugging works with the Android 4.0 SDK. Then I’ve created an example project which should work with the Android 4.0 SDK and incorporates all my changes as explained above. Then Patrick Boos improved that even further. Thanks a lot. You can find the example project on GitHub (https://github.com/pboos/scala-on-android-example#readme) . Don’t forget to fix the local.properties for your environment. And remember that Proguard doesn’t like spaces in paths. My build file won’t work with spaces in file paths right now =(.

Conclusion

That’s it for now. If you know a better way, have tips or problems: Tell me =).

What is Akka?

Akka is a framework for Scala (and also Java) to bring Erlang style actors (and tons of other things) to the JVM. In the actor model we have actors which communicate through message passing with each other. Each actor can react to messages, do some computation and sent messages to other actors which he knows. The message passing it the only way actors can communicate, there not shared state or other communication channels.

Why Actors?

I just cite from the Akka website:

“We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it’s because we are using the wrong tools and the wrong level of abstraction.  Akka is here to change that.  Using the Actor Model together with Software Transactional Memory we raise the abstraction level and provide a better platform to build correct concurrent and scalable applications.”

And:

“For fault-tolerance we adopt the “Let it crash” / “Embrace failure” model which have been used with great success in the telecom industry to build applications that self-heal, systems that never stop.”

Akka Mobile?

The Actor Model works well for distributed, ‘event’-oriented and fault tolerant environments. Where do we have such systems? Yes, in the mobile space! Think about all the phones our there running tons of applications. Many of these applications communicate with a central service or even between devices. Think about all the applications on your phone which have ‘real-time’ communication features? Chat apps, social apps like Facebook & Twitter, GPS apps which incorporates the latest traffic information etc. And all these applications have to deal with network faults, message delivery and coordination.

So I think the Actor model is a good fit for these kinds of ‘real time’ applications on the phone. That’s why I want to get the Actor goodness on the phone.

Actors and Phones Don't Get Along (Yet)

30’000 Feet Overview

Ok, the basic idea is very simple. We simply bring the actors to the phone. These actors can communication locally or with a remote service. On the phone we can send messages to some actors running on the Server. On the server we can access each phone like an actor and send messages to it.

For example on the phone we simply can send a message to the server like this:

theServiceOnTheServer ! “Hi”

And on the server we can react to this and reply:

onMessage “Hi” =>  reply(“Hi there”)

These messages are then delivered to each mailbox of the actors running on the server and phone. There the actors then can read and reacht to these messages. The framework handles the communication, failures, etc. of the messages. Of course it won’t be a silver bullet and you still need to deal with errors. However with an Actor model dealing with errors is easier than with more traditional models (like exceptions).

Actor Communication

Tons of Details

While the actor model provides are very simple model, there are tons of details which need to go into the implementation. How do deal with connection losses and offline devices? How are communication errors exposed to the actors? And of course additions for the mobile space should also be considered. For example messages which are only delivered when the device is actively used and other messages which are always delivered.

Back To Akka

Now of course I could go with a green field approach and implement everything from scratch, but that would be a lot of wasted effort. Akka already has solid implemented Actors including remote communications. However Akka is intended for servers and clusters. The current remote implementation isn’t really intended to be used on mobile devices. So my goal it the change that and bring parts of the Akka goodness to the mobile space.

Conclusion & Next Time

Ok, I want bring Akka actors to the mobile space. The motivation for this is that the actor model is a good fit for complex distributed computing, like in the mobile space.

Anyway, I will go into more details in future posts. Next time I will explain how to get Scala running on Android.