Clojure Development on Android: State of Clojure on Android 2013

   My last year's participation was successful enough to bring some attention of the community to CoA. My work resulted in creation of lein-droid - a plugin for Leiningen to seamlessly build CoA projets in Clojure-way; and fork of Neko - a convenience library that claims to bring idiomatic Clojure development practices to Android. Lein-droid managed to get 149 watchers over the year, which I suppose is a good result considering the limited target audience of the project (for comparison, Leiningen has ~2600 watchers - so roughly 5% of the community got interested in CoA).

   Neko is in a bit afloat right now. Daniel and me haven't merged our branches yet, so officially Neko still supports and prefers building with Ant and use of some concepts deprecated in my branch. I sincerely hope that we are able to finally combine our work and deliver stable version 2.0.0, again before I resume active development.

   So what can you do with CoA today and what are the current limits?

   Well, obviously you can create complete CoA applications. Lein-droid simplifies the build process to usage of a single command, without the need to touch Ant or Eclipse along the way. You can use Clojure libraries as dependencies just like you do in your JVM Clojure projects (with the only difference that the library shouldn't use JVM-specific classes that are absent on Dalvik). Besides lein-droid (when used in conjunction with neko which is by default) injects a nrepl server into your application which allows to connect to your running application on the device from the computer and develop interactively just like you are used to. Lein-droid provides a distinction between debug build and release build, and doing the latter one removes the nrepl thing automatically, so there is no overhead (although you can deliberately enable it in release builds as well). There is a brief tutorial on getting started here.

   Neko provides a bunch of useful functions and macros to simplify your CoA development. First of all, neko.ui is a namespace where the most magic happens. It allows you to define your UI declaratively and interactively in Clojure, without touching XML, and without any overhead. neko.ui takes UI specified in Clojure data structures and transforms it into Java interop calls in compile time. Right now, the number of UI widgets and properties supported by neko.ui is limited, and extending it is the first objective of my GSoC 2013 proposal. Additionally, there are utilities to work with SQLite, notifications, shared preferences, resources, logging. Neko source code is well documented, and you can also find usage documentation on project's wiki.

   Now to the said part. The main problem and limiting factor for CoA adoption remains the size of Clojure runtime. Android devices are getting more powerful everyday, but so are user expectations in terms of performance. CoA applications take some noticeable time to load (up to 10 seconds on some old devices, up to 4-5 on the latest ones); also due to high memory usage they often become candidates for the operating system to be cleaned up after they are minimized. As an example, I once wrote a simple app in Clojure that shows active processes, and a plugin for it (as a separate application, also written in Clojure); as a result, when the main app opened the plugin it was often itself closed the OS. This is certainly a repulsive experience for Android users. Fortunately though, the talks of developing a leaner Clojure runtime are out there for quite some time, and more and more people become obsessed with this idea. I think, that now when we have quite an efficient ClojureScript compiler written in Clojure, it is feasible to adapt it to compiling native Clojure code into something more lightweight.

   You still have to know Android to be able to use CoA. Actually, it was never a purpose to completely hide Java-Android behind Neko abstractions; but more than that there is a big amount of code you have to write using interop where Clojure would be more elegant. Zach has a lot to say about this. So this year' efforts are directed towards this goal too - reduce the number of interop where it makes sense to do so. Yes, you have to know Android SDK, but you don't have to care about it all the time.

   IDE support is well non-existent right now. Since CoA uses nrepl for remote interactive development, you can use Emacs/Vim/ST/Eclipse to connect to your application. Fancy stuff like jump-to-definition is currently unavailable. Moreover Android developers are quite used to IDE-driven development, especially with the goodies presented in new Android Studio. It is quite hard to win these developers over without providing them something of equal power. So yet another intent of this summer is to research if some of these IDE features can be harnessed from Clojure. The UI side is the tastiest, and since neko.ui would most probably be rewritten (I describe the reasons in my proposal), I will do it with the IDE argument in mind.