Home

Welcome to the audience wiki!

Audience is a pseudo-actor framework. It is heavily inspired by Erlang and the BEAM virtual machine. See the project's README for more details on usage and installation.

Why would I use this?

Given the number of different scenarios and states an application can have in an Android device and that most asynchronous frameworks don't take that into consideration, things get a bit too hard.

The basic constraints a mobile application must face are:

• limited resources (battery, network, cpu)
• constantly changing configuration (orientation changes, keyboard attachment changes, etc)
• no control of lifecycle (OS decides when and how it must passivate an application)

To handle all that a lot of error prone code is needed. Indeterminism is rule and not an exception. Mainly with asynchronous models. Trying to provide a better alternative, some alternatives were born in the Android community: event buses and reactive streams. Both have their advantages and disadvantages.

1. Event Buses

This kind of async model is mainly represented by Otto and EventBus. The premise is that there is a model object that represents an event defined by the application that can be sent to processing either on background or foreground. This follows the message queue approach of publisher/subscriber pattern.

One advertised advantage of this approach is that you can "decouple" your sender from your receiver. In my experience on the field, this helps but the problem is that it is too easy to decouple. So, any layer of your architecture can produce events and any layer can receive events. Still nice but you don't know exactly who sent what. That is for the developer to worry about. More than that: you don't even have to know if there is a subscriber.

These frameworks are not built with Android in mind. They are built with Android compatibility but they can also be used on a pure JVM setup. That is good but it can't target the constraints we have specifically. For example, none of these implementations have Android defaults. You have to register and unregister all your activities, fragments and the like.

Another common issue with this approach for asynchronous processing is that you narrow your receiver selection purely by event type. You must have a well defined type. It is common to create opaque types only to adhere to this requirement.

2. Reactive Streams

// TODO ... it is late... I have to work early in the morning tomorrow...