Badoo Londroid

Last night I went to a meeting of that alternative Java (i.e. Android) development group Londroid, sponsored by Badoo, a social networking tool, and hosted at Skill Matter/CodeNode. William Gibson once refered to Britain as Mirror World, like America but oddly different, and the same is true of Android to Java. It’s where the Java desktop world went when the internet turned up and everything went all server-side, so the meeting had a certain surreal quality for me.

Building a framework with Clean Architecture with Rich King
First up was Rich from the sponsor Badoo. Rich discussed how the Clean Architecure principals, as described in “Uncle” Bob Martin’s blog post, impacted on the development of the Badoo Android application. Here’s a description of Clean from the man himself:

What Rich described in his presentation is separating the parts of the system into domains (shades of DDD here), usually done in the Java world when designing for a Microservice architecture. Because of the limited nature of the Android platform, all this is in what might be described as a micro-monolith (think there’s a niche for nano-services on Android?). All-in-all a nice presentation, only spoilt by ghost transmissions from the presentation upstairs.

Presentation Patterns Using Rx with Yoel Gluschnaider and Flavio Zanda
Although there are few Spring-like frameworks in Android, again due to the limitations of platform, RxJava has taken off, mostly as a more sophisticated option or supplement to data-binding.

However, there’s still a need for what frameworks usually implement, in this case the Model-View-Controller (MVC) design pattern for managing the interactions between the screen and what goes on the the back. Alternatives to this pattern are the Model-View-Presentor (MVP) and the Model-View-ViewModel (MVVM) patterns. The former, and the one they recommended, is a variation on MVC pattern and, like this, the view makes a request to the controller and the controller consults the model about how to respond. MVC assumes the controller is pretty dumb, just acting as a junction box separating the View from the Model. MVP moves most of the decision making to the controller, to the point that View does almost nothing (a Passive View pattern, as it’s been called). MVVM is more complicated, by the sounds of it, and I haven’t had time to do any research on it at the moment, but that also looks interesting.

Yoel and Flavio’s talk was very engaging and interesting, despite it’s short length.

Android Livecode, RxJava Architectures on Android at Microsoft

This was an Android Livecode presentation I attended, hosted at the Microsoft offices in sunny Westminster.

After the introduction, the main presentation was given by a Berliner, Timo Tuominen from Futurice, concerning the use of Functional Reactive programming on Android. This centred around the use of RxJava, an open source library based on a Microsoft library and implemented by Netflix, the video streaming company.

(A well attended presentation, as you can see, but there was free beer and pizza).

RxJava is centered around the use of an Observable class i.e. an implementation of the Observer design pattern from the “Gang of Four” book, on which most event model are based. It seems that the difference between, say, the standard Java listeners and RxJava is that the listeners have to be implemented within the class as you’re coding it. Here’s something I’ve been working on for the College:

//custom event maintenance
//this is a list of events that have to
//be serviced when something happens
private List<SwitchListener> listenerList = new ArrayList<SwitchListener>();

public void addSwitchListener(SwitchListener listener) {

public void removeSwitchListener(SwitchListener listener) {

private void fireSwitchListener() {
    //parcel up the state of the switch in a SwitchEvent object
    SwitchEvent e = new SwitchEvent(this, isSwitchOn());
    //then send it to every listener in the list
    for(SwitchListener listener: listenerList) {

Listeners are all over Java components as it provides a way of passing messages between the components and their containers without the components having references to the latter (a problem known as “coupling”).

What RxJava seems to do is wrapper up listeners, or something like them, into a framework that can be applied to any other object. For example, if you want to “listen” to an object so that when it changes you can do something else, or react to it, you can use the Observable class to do it:

Observable.from(names).subscribe(new Action1<String>() {
    public void call(String s) {
        System.out.println("Hello " + s + "!");

It does seem to be something that you would think was already in function programming languages, like Clojure and Scala, by default, but RxJava can be used by these, so maybe it isn’t?