Cut The Rope 2

It's not often that I blog about games, but one I've been introduced to by my sister's grandson is the mildly addictive and infinitely charming Cut The Rope 2 by ZeptoLab, available online or for various mobile platforms. It centers around Om Nom, the tubby little green character and his attempt to find (and eat) swirly little sweets. You have to solve little physics puzzles to get him the sweets:

You can even get stickers and plush toys based on the game. Sweet!

Badoo Londroid

Just for giggle, and potentially free food, 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.

It also gave me the excuse to meetup with my erstwhile colleague Matt, who has finally had enough of working for airline companies and has gone contacting at a fitness firm. Very fitting.

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 no Spring-like frameworks in Android, again due to the limitations of platform, RxJava has taken off somewhat, 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 looks interesting.

Yoel and Flavio's talk was very engaging and only marred by the fact that everyone was hungry by the end and expecting the promised food. This was at a place over towards Old Street and well out of my way, so I made my excuses and left the group hungry (for knowledge as well).

Wednesday - Android Livecode, RxJava Architectures on Android at Microsoft

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

Yeah, I didn't get it either, and the Microsoft people were not exactly convincing in their reasons for hosting what is, essentially, a presentation for the competition. (For those who don't know, Android is the mobile phone\embedded operating system owned by Google and in competition with Microsoft's Windows 8).

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 models 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) {
 listenerList.add(listener);
}

public void removeSwitchListener(SwitchListener listener) {
 listenerList.remove(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) {
  listener.switchChange(e);
 }
}

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?

Overall, the presentation wasn't brilliant as Timo is not a natural presenter, plus he seemed unaware of any of the alternatives (although his boss was there and stepped in to answer the awkward question or two that arose), which was a shame because it does seem like an interesting subject.

Android Live Code: Monetization and Augmented Reality

Last night I attended the first Android Live Code seminar at Hub Westminster, based in New Zealand House just off Trafalgar Square (very swanky!).

The first presentation was on the best plans for the monetization of Android applications given by Yinon Horwitz from StartApp.

He gave a very slick presentation (which subtly plugged his company's services), about the different ways in which Android Apps can be made to generate revenue. Mostly this consisted of either paying up front for an application; the "freemium" model, where you get a basic app for free and then pay to get various functionality enabled; and various ad-based options.

The second talk was by Lukasz Piliszczuk who went through the source code of his augmented reality application, especially regarding image recognition.

While this was informative, it could have done with a few more diagrams to illustrate how the code fitted together, especially given his very stong accent.

Scratch from MIT

MIT have made this little programming IDE called Scratch which is very similar to the Android AppInventor I blogged about last year:

It's main use is education, but it's also used for simple games programming and animation.

Adventures in Android Programming

Someone I know recently bought themselves an Android phone. This reminded me that I managed to get an early Beta of the AppInventor from Google which allows you to program the phones using a really easy user interface, so I decided to build them a simple app (they have a cat, so the app plays a purring sound or meowing sound when they click on the picture).

The AppInventor is web based but involves using a Java WebApp and an emulator, which you have to download. The designer is relatively straightforward, but it's the blocks editor which is the great bit for the programmer. Look at this:

It even clicks when you place the components. How cool is that. It's like Lego for programmers, not that most programmers don't already have Lego.