AsyncMvp

• English (PDF)
• Russian (PDF)

Summary

AsyncMvp is a design pattern framework for the quick development of Android applications. The framework architecture is based on a message-based system.

Overview

AsyncMvp is a Design Pattern Framework for the quick development and strict structuring of Android applications. AsyncMvp has been used in several applications with different logic and the number of this applications is constantly growing, such as: Geo Tasker, 24minutes and Beacon

Before describing the goals of the framework it’s necessary to explain some terms. <u>Module</u> - a component of the framework which realizes some technology, for example, data exchange over HTTP, data caching. Module is a model in terms of MVP template.

Layer is an interface of module for message handling like making some computations with message and executing module methods.

View is an instance of Activity or Service or View class in Android OS.

When we talk about components of framework we mean Views and Models(Modules) of MVP template.

The goals of framework are:

1. The framework architecture is based on a messaging system: framework components are able to interchange information and perform computations by sending, receiving and processing messages. A messaging API provides simplicity, strong encapsulation and loose coupling; framework components - modules - can be plugged into complex applications using a "constructor/messaging" architecture. Framework modules can be both open source and compiled libraries. Framework messages can be two-way processed and asynchronous. Generally, all modules are executed in separate threads, so that we can’t get an ANR error in application. But messages which are being sent to modules are being putted to the message queue and being processed one after another. But if we want to process messages in parallel in a module we need to create an additional concurrency logic. The framework takes full advantage of the power and simplicity of the messaging design pattern/API.
2. The framework constructor/messaging architecture provides transparent access to module components.
3. The framework can provide transparent integration with many technologies via framework modules. These technologies include Data Access Object implementations (DAO), XML parser, XMPP support. In current version framework provides integration with network data exchange over HTTP technology, data caching technology and quick identification of a user's location module.
4. The framework is designed to be lightweight and fast.
5. The framework messaging/constructor architecture improves and simplifies design/development efforts. There is a connection between UML design diagrams and the framework messaging based modules in application.
6. The framework messaging architecture facilitates testing efforts. The framework provides capabilities for testing modules and views as independent units by sending messages to them and verifying reply messages with the expected ones.

Message design pattern

Intent: The message-based system allows the interchange of messages between modules and applications views.

Motivations (forces): This design pattern can be applied to solve a great variety of problems in many diverse scenarios. A messaging paradigm is widely used in nature and the real world. Messages are interchanged all around us. Entities are constantly sending, receiving and processing messages. Human beings for instance: when we watch TV, listen to music, talk over the phone, or communicate via the internet. Right now, you are reading this written message. Since applications seek to model the real world, it is only natural to design and write applications using a messaging approach. As a consequence, software engineering processes are significantly improved by the use of the message-based system.

Participants:

Message Sender: View or Model(usual View) in MVP template that sends the messages for getting or updating data.

Message Recipient: View or Model in MVP template(usual Model) that receives the input message and may produce a reply (output message) after processing it. The message may contain any type of information. View or Model is instructed to perform computations based on the input message. It is common to interchange messages between View and View or Model and Model.

Presenter: Intermediary that transfers the message from the sender to the recipient. The sender and the recipient don’t need to be concerned about how the message is transferred (communication protocol, message format, encryption/security mechanism, etc.) and the transformations performed on the message along the way. Message is sent according protocol. Special class contains list of protocols and their description. Several modes of communication are possible: asynchronous and two-way messaging.

Message: instance of Message class which contains information that needs to be sent to the recipient. Message.what field defines the protocol of message. Information can be stored in Message.arg1, Message.arg2 and Message.obj fields and also in a Bundle which is accessed through Message.getData() method. Two messages are usually involved: input message and output message (or reply message). The reply message is not required.

Consequences:

• Encapsulation. The message-based system maximizes encapsulation. Each component is a self-contained/independent unit. The only mechanism of communication between view and models is via messaging.
• Decoupling. Message-based system minimizes coupling. Again each module is a self-contained unit that can perform independently from the rest of the system.
• Reusability. Message-based system improves reusability. This is similar to the building blocks in a constructor. Very complex models can be built based on simple pieces that share a simple way of interconnecting them. The power of the approach is derived from the number of combinations in which these pieces can be assembled. Modules that use the message-based system can be plugged into complex applications. The user of a component only needs to know the input/output messages that the module handles.
• Testing process. Message-based system facilitates testing and debugging efforts. Modules are tested as independent units by sending messages to the module and verifying the expected reply messages (black-box testing). No need to include testing code inside the module code which can be time consuming and lead to the unexpected introduction of software defects.
• Design process. MBS improves and simplifies the design process. The bulk of the design work becomes defining the set of modules needed to meet the system requirements and the input/output messages that each component needs to handle. There is a tight correspondence between UML design diagrams and the modules needed for the implementation.
• Development process. Since each module that relies on messaging is self-contained, a large team of people can cooperate in the development effort without stepping on each other's code/work. In the ideal situation, responsibility for one module can be given to an individual. The rest of the team only needs to know the protocols and its description of input/output messages that someone else’s module is designed to handle. No need to change someone else’s code. The need for creating, maintaining and merging several versions of the code is also minimized or eliminated.
• Speed of development and its cost. Because of all the reasons outlined above, the messaging design pattern is able to substantially improve the speed of development and reduce cost.
• In order to take full advantage of this design pattern, people need to think in terms of messaging when they model, design and build software applications: view and model interchanging messages among each other. This may require learning time and training.

Implementation and Code Examples:

The message-based system is implemented using the AsyncMvp model messaging interface (ModelLayerInterface) and Android view message interface Handler.Callback. The ModelLayerInterface consists of 3 methods one of them is required to implement:

public interface ModelLayerInterface   {

    public void init(Context context);

    public boolean handleMessage(Message msg);

    public LayerStatus getStatus();
}

And Handler.Callback interface consists of a single method handleMessage(Message msg). The messaging interfaces are simple but powerful. One method is all that is needed! It acts as a universal messaging interface that applies to framework components.

Asynchronous messaging, two-way messaging and multithreading

Messages are sent asynchronously and placed in a message queue until you are ready to "process" them. MBS is able to handle the complexities it associated with, asynchronous messaging and multithreading.

Framework modules are executed in a separate independent thread. This is a natural representation of the real world: each component (entity) is a self-contained unit able to execute independently for the rest of the system.

Messages are processed asynchronously using the component’s own independent thread. This capability is implemented in the context of the AsyncMvp framework via a messaging queue.

The module does not need to add logic to manage multithreading if you do not want it. You can also decide to send a message back asynchronously establishing a two-way communication.

Disadvantage and plans

1. The framework does not provide secure access to module components. This means that if we have two modules with the same protocols they will intersect each other.
2. In future versions of the framework, it should be possible for application modules to be generated directly from the UML design diagrams.