Activity is an inevitable component of the Android appli- cation. Previous experience of the Android community shows Activity does not fit well on the MVC model, while it seems to be well adapted to developers’ needs. We decided to create MVC model around Activity making the Activity the fourth component. We can also think of Activity as a main screen (parent) controller in HMVC model.
Observer-observable pattern is relevant for multi-screen systems but only one screen is active at a time in Android application. This pattern supposes keeping in memory Views and Models that appear heavy for the mobile environment, therefore we chose the Passive Model MVC as a base for our architecture.
In our model, Activity becomes an intermediate component between the Views and the Controllers, thereby Controllers take the event handling responsibility and the Views take the presentation logic making the Activity lightweight. The scheme of the Android Passive MVC model is shown in Figure 1. The grey dashed arrows show the interaction via Android native methods. Black arrows indicate direct calls and grey arrows represent listener events.
The Activity is like a screen controller. The starting Ac- tivity creates a link between a View and a corresponding Controller to make them communicate directly. The commu- nication between Controllers is made via Activity. The Views are the interface components, such as a form, a menu or a list of elements. View components contain methods that allow the setting or obtaining of data from the user interface on Controller demand, the setting of event listeners on visual components and the modification of visual components (set errors, change colours, etc.). Views are independent and do not communicate.
The Controller handles events from the user action (e.g. button click), calls necessary methods from the Model and then notifies the View to be updated on Model response. The Controllers are independent from one another and do not communicate directly.
This solution makes Activity lightweight by moving all event handlers to Controllers and interface management to Views. Views and Controllers created on demand avoid unnec- essary objects, saving memory. Developers can easily modify or remove application components by only modifying or deleting the corresponding view-controller couple. Application can be extended with view-controller couples. The Model is independent from the View, the Controller and the Activity. The user interface could be replaced without any impact on Model thereby the maintainability of the application is high.
We perform the communication between Activity, Con- troller and Model via message listeners implemented via interfaces as proposed by . Figure 2 shows the Android Passive MVC implementation diagram. Listeners increase the performance of the application and create a weak coupling between components that improve maintainability.
B. Android Passive MVC Implementation
This section presents an implementation example of com- munication between Android Passive MVC components. This implementation is suitable for the new manually created Ac- tivities. Some predefined Activities, especially from third-party libraries, will possibly not fit the implementation. We created a login screen with a classic login form to enter the login and password; if the login is successful the user goes to the welcome page, otherwise the error message appears.
The example contains two Activities: Login Activity managing the login page and Welcome Activity for the wel- come page. The login form is managed by Login View and Login Controller. Login Activity implements the LoginCon- trollerListener interface to be able to receive calls from the Login Controller. The schema is shown in Figure 3.
Login View contains methods for obtaining login and password (getters), methods to set button listener and methods to set errors. Login Controller handles event from the login form implementing the onClickListener; while the button is pressed Controller launches simple verifications and calls the model. If login is successful, the answer goes back to the Login Activity, which opens a welcome screen. To simplify the example we do not include the model, but the communication between the Controller and the Model can be implemented similarly. A full code example can be found on .
C. Android Domain Model
The Model of Android Passive MVC is a Domain Model con- taining business methods, web service call methods, database access objects, reusable methods and data model objects.
A Domain Model architecture should include components usually used in Android applications, such as Database man- ager, Web services manager and Business logic. Those com- ponents should be independent, as the architecture should be adaptable. Reusable components should be also separated. The basic model architecture is shown in Figure 4.
The architecture of Domain Model proposed in this doc- ument is inspired by 3-tier architecture that separates the presentation, the business and the data access layers .
The business layer of our model regroups objects and meth- ods that use web services, business services and reusable tools. Business services contain business logic. If an application works via Internet as well as locally, all necessary verifications are done in Business services, which calls corresponding methods. The communication between a presentation and a domain model layer are made via Business services.
The data layer contains Models, Data Access Objects (DAO) and Database Manager. DAO and Model are the implementation of the Data Access Object pattern. Model contains data being persisted in the database or retrieved by web services calls. Model is a simple Plain Old Java Object (POJO) that contains only variables and their getter and setter methods. Data is manipulated and transferred through the application using those lightweight objects that are often called Data Transfer Object (DTO).
Persistence methods are organized in DAOs. DAO contains methods that enable the data in a database to be saved, deleted, updated and retrieved. Even if Android proposes an abstraction on the data access level with Content Provider, DAO simplifies the code of the application. The DAO design pattern creates a weak coupling between components and use a lightweight Model object instead of an Android cursor object in the application. DAO can also be used for the data stored in XML or text files. Good practice is to make DAO accessible via interfaces. It allows DAO modification (for example the change of SQLite to XML storage) without any change in Business services, which increases maintainability.
Database manager is in charge of the database creation. Database manager exists only if SQlite database is used by the application. It stores the name of the database, and of its tables and methods to be able to create, drop, open and close the database.
This architecture regroups logically similar methods to- gether, increases cohesion. High cohesion facilitates the main- tainability of the software. The final code of the application could be organized in packages by architectural components: Activities, Views, Controllers, Business Services, Tools, Web Services, Model, DAOs and Database. It gives the clear structure of an application and limits the package number. Additional packages could be created for interfaces, parsers (e.g. XML, JSON) and constants.