A Naked Objects based Framework for Developing Android Business

Applications

Fabiano Freitas and Paulo Henrique M. Maia

Academic Master in Computer Science, State University of Ceara, Fortaleza, Brazil

Keywords:

Naked Objects, Framework, Android Application.

Abstract:

Naked Objects is an architectural pattern in which the business objects are handled directly in the user interface.

In this pattern, developers are responsible only for the creation of business classes and do not need to concern

with the implementation of the other layers. Although used in several frameworks for making the development

of web and desktop systems faster, there is still a lack of tools that add the beneﬁts of that pattern to the creation

of Android applications. This paper introduces JustBusiness, a Naked Objects based framework that aims at

supporting the creation of Android applications through automatic generation of user interfaces and persistence

code from mapping the business classes. Two case studies that describe how the framework was used and its

evaluation are also provided.

1 INTRODUCTION

The attention that the Android platform has gained

over the recent years has resulted in an increasing

demand for applications, a situation justiﬁed by the

growth of the Android community. According to data

from Net Marketshare

for March 2015, Android is

the most widely used platform on the planet, with a

percentage of 47.51%, reaching more than a billion

mobile devices among smartphones and tablets.

To answer the market demands, developers and

companies are increasingly using frameworks and li-

braries that can ease the development of applications,

thus helping to boost productivity. Among these, we

can cite Ormlite (ICE, 2015c), a framework to sim-

plify the access and communication between the An-

droid application and the SQLite database, and Robo-

letric (ICE, 2010c), a framework to facilitate testing

Android applications.

Although useful, those frameworks do not solve or

mitigate one of the main application development bot-

tlenecks, which is the creation of user interfaces (UIs)

and CRUD (create, read, update and delete) code for

business objects, since they do not provide automatic

generation mechanisms of those artifacts. That task is

already commonly performed to web (Milosavljevi

et al., 2003) and desktop systems (da Cruz and Faria,

2010). According to Pawson (Pawson, 2004), the de-

https://www.netmarketshare.com

velopment of user interfaces is, most of the times, the

task responsible for a signiﬁcant proportion of all the

effort involved in developing an interactive business

system due to not only the complexity of coding, but

also to the time spent with the presentation details.

As a result, the developer must manually build each

of those interfaces and CRUD code, which is a tiring,

time consuming and error prone task. Moreover, if

the user wants to migrate an existing application from

another platform, he/she may have difﬁcult on reusing

the business classes code, which implies in a rework

to create them on the Android platform.

To ﬁll that gap, this paper presents JustBusiness

a framework for developing Android business appli-

cations that provides automatic generation of user in-

terfaces and CRUD code from information obtained

from the object-user interface mapping of the business

classes. For that, the framework implements the archi-

tectural pattern Naked Objects (Pawson and Matthews,

2001) (Pawson, 2004), in which the main applica-

tion parts (the domain objects) are displayed in the

interface and the user can manipulate them directly

by using those objects’ methods. With JustBusiness,

the developer is only responsible for implementing

the business classes, while the framework performs

the heavy task of generation and conﬁguration of all

necessary classes and ﬁles for running an Android

Download available at https://jbframework.

wordpress.com

348

Freitas, F. and Maia, P.

A Naked Objects based Framework for Developing Android Business Applications.

In Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016) - Volume 1, pages 348-358

ISBN: 978-989-758-187-8

application.

The rest of this paper is divided as follow: section

2 explains the main concepts of Naked Objects, while

the related work are discussed in Section 3. Section

4 presents the JustBusiness framework, describing its

architecture and key features. In Section 5, two case

studies describing the implementation of the frame-

work and its evaluation are shown. Finally, Section 6

presents the conclusions and future work.

2 NAKED OBJECTS

The Naked Objects pattern is an object-oriented ap-

proach where the domain objects are exposed in the

user interface, and the user has the power to manipu-

late them directly by performing invocations of meth-

ods implemented by those objects (Pawson, 2004). In

that approach, the code of all classes must respect

the object behavioral completeness, one of the most

important principles of the object-oriented paradigm

and that states that objects must fully implement what

they represent (Pawson and Matthews, 2002) (Pawson,

2004) (Raja and Lakshmanan, 2010). The applica-

tion of that pattern removes from the programmer the

need for implementing user interface or security and

persistence mechanisms, making him/her responsible

only for creating the application domain objects, which

must implement all behavior they propose to represent

completely.

According to Raja and Lakshmanan (Raja and

Lakshmanan, 2010), the Naked Objects approach has

three principles that characterize the pattern: (i) the

whole business logic should be encapsulated by busi-

ness objects; (ii) the user interface should reﬂect the

business objects; and (iii) the user interface generation

should be automated from the domain objects. Also

according to the authors, those principles boost the

software development cycle, ease the requirements

analysis, bring greater agility and produce more efﬁ-

cient user interfaces.

Naked Objects is an alternative to 4-layers (presen-

tation, control, domain and persistence) architectural

pattern. It uses a ratio 1:1 between elements of differ-

ent layers, where for each domain object there exists

only one match in the other layers, while in the 4-layers

pattern there may be more complex mappings between

the layers (Brandao et al., 2012). The comparison

between the two architectural patterns is illustrated in

Figure 1.

In (Pawson and Wade, 2003), Pawson and Wade

conducted a study about using Naked Objects in an

agile software development process. Among the found

beneﬁts, the authors point out that the approach foster

Figure 1: 4-layers (left) and Naked Objects (right) architec-

tural patterns (Pawson, 2004).

the concept of exploration phase, in which users and/or

customers, along with the development team, perform

the UI prototyping simultaneously to the business ob-

jects modeling activity.

3 RELATED WORK

There are several frameworks and tools that promote

the development of Naked Objects-based systems. We

can highlight the following ones.

Naked Objects Framework (ICE, 2015a): one of

the pioneer tools. It was developed in Java and

used the concept of reﬂection, which was consid-

ered one of the main factors that inﬂuenced the

choice of the programming language, according to

its creator. It is focused on assisting the web and

desktop application development.

Naked Objects MVC (ICE, 2015b): built upon the

Microsoft ASP.NET platform, it aims at creating

web applications, providing full-generation of user

interfaces using ASP.NET MVC.

Apache Isis (ICE, 2010a): an open source frame-

work implemented and focused on Java platform

for rapid development of web applications. The

Java reﬂection feature is used along with annota-

tions, with which the programmer makes conﬁgu-

ration speciﬁcations in the domain objects that will

be treated by the framework. With this, Isis is re-

sponsible for managing the user interface, security

and data persistence resources.

JMatter (ICE, 2008): a Java open source project

that implements the Naked Objects pattern using,

among other resources, Swing and Hibernate. It

aims at helping the development of Java web appli-

cations by implementing their necessary infrastruc-

ture, including all CRUD structures, persistence

and search mechanisms. As well as other similar

frameworks, JMatter supports the UI automatic

generation at runtime.

A Naked Objects based Framework for Developing Android Business Applications

349

Entities (ICE, 2013a): framework implemented in

Java to help developing web applications. One of

its main beneﬁts is the possibility of generation of

customizable interfaces to the application through

an object-user interface mapping. The generated

interfaces can be customized through the annota-

tions in the domain classes.

Isis Android Viewer (ICE, 2013b): this framework

is not a tool to assist the development of Naked

Objects-based applications, but rather an Android

project to communicate to a web application de-

veloped with the Apache Isis framework. An Isis

Android Viewer application creates representations

of both user interface and persistence based on the

domain objects present in the web application.

Naked Object for Android (ICE, 2010b): Accord-

ing to the tool’s website, this is the ﬁrst framework

implemented to accelerate the Android application

development using the Naked Objects principles.

The tool, unlike the previous ones, does not support

automatic generation of user interfaces nor persis-

tence mechanisms. Currently it is not working, and

there has not been recent updates nor maintenance

activities.

An extension of the Naked Objects framework us-

ing annotations to allow the manipulation of higher-

level abstractions, such as specialization of object re-

lationships, is proposed by Broinizi et al in (Broinizi

et al., 2008). According to the authors, using that ap-

proach to validate requirements brings as beneﬁts the

reduction of conceptual speciﬁcation problems, like

a weak identiﬁcation of requirements, decreases the

distance between domain and project experts, and al-

lows the simultaneous exploration of conceptual data

design and system requirements.

Keranen and Abrahamsson present in (Keranen

and Abrahamsson, 2005) a study that compared two

mobile development projects of the same mobile ap-

plication for Java ME platform, where the ﬁrst one

used the traditional development, while the second

one was developed using the Naked Objects Frame-

work (NOF). As a result, there was a reduction of 79%

in application code and 91% in interface code for the

application with NOF. Despite those beneﬁts, the au-

thors concluded that NOF is still not mature enough to

develop mobile applications.

Model-driven approaches for the creation and man-

agement of user interfaces, in which the software

engineer develops the project of the system concep-

tual models from object oriented meta-models, are

described in (Milosavljevi

c et al., 2003) and (da Cruz

and Faria, 2010). By applying pre-deﬁned mapping

rules, it performs the reﬁnement and transformation

of conceptual models, generating user interface and

CRUD code from meta-models automatically.

All aforementioned approaches and tools do not

support development for current mobile platforms, but

rather only for web or desktop ones. Although the

approaches proposed in (Keranen and Abrahamsson,

2005) and (Nilsson, 2009) use Naked Objects, they

were designed for obsolete mobile platforms. Regard-

ing the Android platform, the only found work was

the Naked Objects for Android, but it has been discon-

tinued. The framework proposed in this paper aims

at bringing the beneﬁts of Naked Objects to Android

developers.

4 JustBusiness

JustBusiness is a framework based on the Naked Ob-

jects architectural pattern that provides support for the

development of object-oriented business applications

in the Android platform and that simpliﬁes the mi-

gration of applications from other platforms, such as

web ans desktop, to that mobile one. Like in other

existing Naked Objects-based frameworks, such as the

Naked Objects Framework, Apache Isis, JMatter and

Entities, JustBusiness exposes the domain objects in

the user interface, allowing users to manipulate them

directly via invocations of methods implemented by

those objects. Furthermore, it also removes from the

programmer the responsibility of building user inter-

faces and persistence mechanisms, since it supports

the automatic generation of those artifacts.

Besides being used for development and migration

of business applications for the Android platform, Just-

Business can be used in the generation of the initial

skeleton of the application. By providing automatic

code generation, the developer can give up from using

JustBusiness at any time in the development applica-

tion process without the loss of source code that has

already been produced.

More details about the JustBusiness framework are

shown in the following sections.

4.1 Architecture

The framework has in its class structure, the abstract

superclass JBEntity, which must be specialized by all

business classes of the application project. The JBEn-

tity class has no attributes and contains only two meth-

ods: toPrimaryDescription and toSecondaryDescrip-

tion, which must be implemented by its subclasses, as

shown in Figure 2.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

350

Figure 2: Extending the superclass JBEntity.

Those methods provide information about the ob-

ject in the user interface, focusing on list screens (Lis-

tActivities). By default, the list of cells that are used

by ListActivities has one or two ﬁelds to display in-

formation, as shown in Figure 3. Instead of using a

single toString method, the structure with two methods

supports more details in the interface, as well as the

use of the two types of basic standard Android cells.

Figure 3: Listing cell standard Android platform.

The business classes should be implemented in a

simpliﬁed way using a standard constructor, private

attributes, and its respective get and set methods. The

structure of the business classes is similar to a POJO

(Plain Old Java Object) class, but differs from it be-

cause they extend the JBEntity superclass and use pre-

deﬁned notes in its construction.

JustBusiness uses a processor that analyzes, at com-

pile time, each annotation used in the conﬁguration of

the business classes. Information obtained from the

processing are stored in a data dictionary that contains

all the information of classes, enumerations, attributes,

methods and mapped parameters. When a "clean and

rebuild" action is performed in the project, the saved

information in the data dictionary are processed by

code generators, which are responsible for creating

and conﬁguring all the needed ﬁles to deploy the ap-

plication and run the project.

For each business class in the project, at least 25

ﬁles are created, as illustrated by Figure 4. Those ﬁles

consist of control and data access classes and resource

ﬁles, which are divided into layout and menu. For

each of those ﬁles, there is a code generator that en-

codes them based on information obtained from the

annotations. In addition, JustBusiness also creates a

Figure 4: Structure of generated ﬁles to the business classes.

set of classes and resource ﬁles, based on informa-

tion from annotations and business classes, for project

organization and execution.

From the mapped information, three control classes

are created to support the business application initial

screen, which brings the list of entities contained in the

application. The dimension and styles resource ﬁles are

modiﬁed, bringing general information for dimensions

and layout styles, respectively, while the strings ﬁle is

modiﬁed to store all text content that will be used in the

application. Furthermore, the persistence ﬁle, which

contains persistence settings to access the database,

is created. Finally, the AndroidManifest ﬁle is also

altered.

For each new ﬁle creation or existing project ﬁle

update, there is a code generator associated. The struc-

ture of project ﬁles generated or updated is shown in

Figure 5.

4.2 Main Features

JustBusiness provides a set of annotations to enable

A Naked Objects based Framework for Developing Android Business Applications

351

Figure 5: Structure of generated or changed project ﬁles.

the mapping information and to conﬁgure the business

classes. Through those annotations, the programmer

can detail information ranging from presentation set-

tings in the UI to data persistence parameters.

In addition to the annotations feature, the frame-

work uses a code generation mechanism that consists

of a set of classes that, using information obtained

from the mapping, generate automatically classes, re-

sources and settings required for the production of an

Android application.

4.2.1 Annotations

In order to conﬁgure and map information in the busi-

ness classes, two sets of annotations have been deﬁned:

one for user interface and the other one for persistence.

The former aims at providing details of the visual set-

tings, while the latter details information for the object-

relational mapping. The information and values passed

through those annotations provide a greater level of

detail about the mapped elements.

Annotations for User Interface.

A single class,

with its attributes and methods, does not have all nec-

essary information for the complete generation of a

graphical interface. To ﬁll this gap, JustBusiness pro-

vides a set of annotations that allows the programmer

to inform the missing information needed to perform

that task.

Using the annotations, it is possible to deﬁne

settings such as the business classes that will be

recognized by the framework, the attributes that will

be displayed on the screen and in which order, and

the methods that will be available in the interface.

JustBusiness uses the annotations @Entity, @At-

tribute, @Action, @Parameter and @Enumeration

to identify and conﬁgure the classes, attributes,

methods, parameters from methods and enumerations,

respectively. Those annotations are detailed in Table 1.

Annotations for Persistence.

The Android mobile

platform, by default, uses the SQLite database, a very

simple and limited database. One of its main limita-

tions refers to the few supported data types (only INTE-

GER, TEXT, NONE, REAL and NUMERIC). Another

important factor that should be considered is that the

Android platform does not support the Java Persistence

API (JPA) and does not recognize the javax.persistence

package, which consists of a set of annotations and

other classes aimed at mapping persistence informa-

tion.

Given those limitations, JustBusiness has added

some persistence features to provide object-relational

mapping between business classes and SQLite

database tables. For this, a set of annotations, inspired

on the javax.persistence annotations, has been deﬁned.

Furthermore, the framework provides a mechanism

for creating tables and SQLite database access from

the information mapped with those persistence annota-

tions. The set of annotations used for data persistence

is listed in Table 2.

4.2.2 Automatic Code Generation

The framework supports the automatic generation of

all necessary infrastructure for an Android application,

including classes and user interface resources, and the

SQLite database and data access classes. The program-

mer is responsible only for implementing the business

classes and conﬁguring them to use the framework.

The code generation occurs at compile time, since, at

that moment, interface classes and resource ﬁles are

created, and some project conﬁguration ﬁles, such as

the AndroidManifest, are modiﬁed to incorporate the

changes made by the framework.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

352

Table 1: Annotations for User Interface.

Annotation Description

@Entity

Describes and conﬁgures the

classes that will be recognized by

the JustBusiness.

Parameters:

label - Name that will be

displayed for the entity

collectionLabel - Plural name

for the entity

icon - Name of the image to be

used as icon by the entity.

The image must be in

the folder (res/drawable)

@Attribute

Describes and conﬁgures

the class attributes.

Parameters:

name - Name that will be

displayed for the attribute

order - Order in which

the attribute is shown

in the user interface

views - Screens in which the

attribute is displayed.

It can be used more than

one value.

The possible values are:

KindView.ALL: All screens

KindView.INSERT: Entry screen

KindView.EDIT: Update screen

KindView.DETAIL: Detail screen

KindView.FIND: Search screen

@Action

Describes and conﬁgures

the class methods.

Parameters:

name - Name that will be

displayed for the method

order - Order in which

the method is shown in menu

@Parameter

Describes and conﬁgures

parameters of class methods.

Parâmetros:

name - Name that will be

displayed for the parameter

order - Order of the parameter

in the form

@Enumeration

Describes enumerations.

User Interface Code Generation.

Through the in-

formation obtained from the mapping of classes, at-

tributes, relationships, and methods using the afore-

mentioned notes, the framework generates the whole

user interface mechanism.

Table 2: Annotations for Persistence.

Annotation Description

@Table

Identiﬁes a class and sets it

as a table in the database.

@Id

Identiﬁes an attribute as a key

in the table.

@Column

Identiﬁes and conﬁgures an

attribute as a column in the

table.

@JoinColumn

Identiﬁes and conﬁgures a

column as an attribute

to perform a join operation

with another table.

@Transient

Identiﬁes an attribute that is

not mapped in the table.

@OneToMany

Identiﬁes and conﬁgures an

attribute as a 1:N relationship.

@OneToOne

Identiﬁes and conﬁgures an

attribute as a 1:1 relationship.

@ManyToOne

Identiﬁes and conﬁgures an

attribute as a N:1 relationship.

@ManyToMany

Identiﬁes and conﬁgures an

attribute as a N:M relationship.

@JoinTable

Identiﬁes and conﬁgures an

attribute as a column for the

operation join with another

table.

@Enumerated

Identiﬁes an attribute as an

enumeration.

@Temporal

Sets an attribute that stores

temporal information.

For each business class, the framework constructs

the interfaces for inserting, editing, detailing and

searching information as forms, where the components

associated with each class attribute are arranged on

the screen in a single vertical column according to the

sequence determined by the developer in the business

class. Those components can be enabled or disabled

on the interface by setting the @Attribute annotation

in the business class.

According to the Naked Objects pattern, changes

are made exclusively in the business model, so the de-

veloper does not need to modify the interfaces directly.

Therefore, in a project using JustBusiness, changes

occur only in the business classes and, to incorporate

that modiﬁcations in the project, the programmer only

needs to recompile it, thus increasing the application’s

maintenance and evolution level.

Persistence Code Generation.

By mapping the

classes and their attributes and relationships using the

proposed annotations, the framework generates the en-

tire SQLite database automatically, including tables

and keys. In addition, for each mapped class in the

A Naked Objects based Framework for Developing Android Business Applications

353

project, the framework automatically generates a data

access class using the Data Access Object (DAO) pat-

tern.

Project Files Conﬁguration.

In addition to generat-

ing the control classes (Activities) and interface layout

ﬁles, JustBusiness is also responsible for modifying

the project conﬁguration ﬁles, such as the Android-

Manifest, which should be modiﬁed at compile time

so that the project can identify all control classes that

have been added, as well as receive information such

as nomenclature and application icon. Besides the An-

droidManifest, the resource ﬁles strings, dimens and

styles are also modiﬁed.

Internationalization.

The textual information

mapped by the programmer using the annotations in

business classes are compiled and stored in the strings

resource ﬁle, which contains the words used within

the application context. By using this approach, the

application can be easily adapted to support a new

language or dialect further.

4.3 Setting Up a Project with

JustBusiness

To use the JustBusiness framework in an Android

project, it is necessary to follow the steps depicted

in Figure 6. As JustBusiness was designed, initially, to

be used with Eclipse, we consider the use of that IDE

to perform the following steps.

Figure 6: Flowchart for the use of JustBusiness.

Firstly, the developer must create an empty An-

droid project and then conﬁgure it to recognize the

framework. The project conﬁguration consists of two

activities: adding the framework to the project libraries

and conﬁguring JustBusiness as an annotation proces-

sor in the project properties.

The next step consists of implementing the busi-

ness classes, which must inherit the JBEntity super-

class and override its abstract methods. Subsequently,

the business classes must be consistently annotated

with annotations provided by the framework in order

to build the interface and persistence mechanisms.

Finally, the project should be cleaned and rebuilt,

since the code generation occurs at compile time. After

that, the project is ready to be executed. If a new

change in a business class is carried out, the developer

must verify whether it is necessary to reconﬁgure the

classes using the annotations and, if so, repeat the

project clean and rebuild step.

5 CASE STUDY

To demonstrate the use of JustBusiness, a case study

that consisted of the development of an application

for request and approval of service overtime, as

used in (Brandao et al., 2012), was carried out. The

scenario starts with the employee requesting a service

overtime, stating the justiﬁcation and the initial

and ﬁnal date. The requests are ﬁrstly reviewed by

the supervisor, who can either authorize or reject

them. The authorized requests will be reviewed by

the Human Resources (HR) sector to calculate and

approve the payment of the hours. If HR has some

questions, the request may return to the supervisor.

Figure 7 is the resulting class diagram of the proposed

case study.

Figure 7: Class diagram. Source: (Brandao et al., 2012).

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

354

5.1 Applying JustBusiness to the

Described Scenario

To use JustBusiness, the developer needs to implement

only the business classes with their attributes, methods

and relationships. He/she should ﬁrstly identify which

business model elements are classes and which ones

are enumerations, since there is a different treatment

for each one. Classes must specialize the superclass

JBEntity, have a default constructor with no arguments,

get and set methods for each attribute, and must be

mapped with the annotations @Entity and @Table.

Enumerations should only be mapped with the anno-

tations @Enumeration and @Table. Listing 1 shows

part of the Overtime class source code. For the sake

of simplicity, some details like gets and sets, as well

as of some attributes and methods settings have been

omitted.

In line 1 the @Entity annotation is used to indicate

that Overtime class will be recognized by JustBusiness

as a business class. Using it, the developer should

inform the class label, that corresponds to the class

name, and the collectionLabel, which is equivalent to

the class plural name. In line 2, the @Table annotation

is used to create the overtime table, whose name was

informed in the name parameter, and to create the DAO

classes with the SQL queries.

After, in line 4, the @Id annotation is used to in-

dicate that the attribute id is a key in the overtime

table. The @Column annotation determines, in line 5,

that the id attribute correspond to the id_overtime col-

umn in the table. In line 6, the @Attribute annotation

speciﬁes that an element should be recognized as an

attribute with label Identiﬁer, has order 1, i.e., it will

be ﬁrst element on screen, and will appear just in the

detail view in the user interface.

Then, in line 9, the @ManyToOne annotation spec-

iﬁes that an attribute represents a relationship N:1 with

the Employee class, mapped through the targetEntity

parameter. In the next line, the @JoinColumn annota-

tion informs that an attribute will perform a join opera-

tion through the id_employee with the table mapped by

the Employee class. In line 11, the @Attribute annota-

tion speciﬁes that an element should be recognized as

an attribute with label Employee, has order 2, i.e., it

will be second element on screen, and will appear in

all views in the user interface.

Finally, the maps relating to methods approve and

pay can be seen in the lines 24 and 29, respectively.

The @Action annotation is used to identify a method

that will be available for the user. The name parameter

value is the title of the button that calls the method,

while the order parameter speciﬁes the position in the

menu where the method appears.

1 @Entity ( l a b e l =" Ov e rt i m e " , c o l l e c t i o n L a b e l =" O v e r t i m es " )

2 @Table ( name= " o v e r t i m e " )

3 p u b l i c c l a s s Ove r t im e e x t e n d s J B E n t i t y {

4 @Id

5 @Column ( name=" i d _ o v e r t i m e " , n u l l a b l e = f a l s e , un i q u e =

t r u e )

6 @ A t t r i b u t e ( name= " I d e n t i f i e r " , o r d e r =1 , vi e w s ={ KindView

. DETAIL } )

7 I n t e g e r i d ;

9 @ManyToOne( t a r g e t E n t i t y =" b u s i n e s s . Emplo yee " )

10 @JoinColumn ( name= " id _ e mp l oy e e " , n u l l a b l e = f a l s e , un i q u e

= f a l s e )

11 @ A t t r i b u t e ( name= " Emplo yee " , o r d e r = 2 , v i ews ={ KindView .

ALL } )

12 Emplo yee employee ;

14 / / A n n o t a t i o n s o m i t t e d

15 D a t e b e g i n n i n g ;

16 D a t e e n di n g ;

17 S t r i n g d e s c r i p t i o n ;

18 S t r i n g r e mar k ;

19 S t a t u s s t a t u s = S t a t u s . WAITING_FOR_APPROVAL;

21 / / G e t t e r s an d S e t t e r s o m i t t e d

22 / / t o P r i m a r y D e s c r i p t i o n and t o S e c u n d a r y D e s c r i p t i o n

methods o m i t t e d

24 @Action ( name= " App rov e " , o r d e r =1)

25 p u b l i c v o i d a p p r ov e ( ) {

26 s t a t u s . ap p ro v e ( t h i s ) ;

27 }

29 @Action ( name= " Pay " , o r d e r =2 )

30 p u b l i c v o i d pay ( ) {

31 s t a t u s . pay ( t h i s ) ;

32 }

34 / / Ot h e r methods o m i t t e d

35 }

Listing 1: Source Code of Overtime Class.

Listing 2 shows the simpliﬁed source code of the

Employee class. Like the Overtime class, for simplic-

ity, some details like gets and sets, as well as some

attributes and methods settings have been omitted. To

avoid repetition, only the annotations that have not

been used in the the Overtime class will be explained.

In line 15, the @ManyToMany annotation speciﬁes

that an attribute represents a relationship N:N with

the Role enumeration, mapped through the parameter

targetEntity. In the next line, the @JoinTable annota-

tion informs that the roles attribute will perform a join

operation with the table mapped by the Role enumera-

tion (shown in Listing 4) using the intermediate table

employee_role.

1 @Entity ( l a b e l =" E mp loy ee " , c o l l e c t i o n L a b e l = " E m ploye e s " )

2 @Table ( name= " em p l o y ee " )

3 p u b l i c c l a s s Emplo yee e x t e n d s J B E n t i t y {

4 @Id

5 @Column ( name=" id_ e mp l o y e e " , n u l l a b l e = f a l s e , un i q u e =

t r u e )

6 @ A t t r i b u t e ( name= " I d e n t i f i e r " , o r d e r =1 , vi e w s ={ KindView

. DETAIL } )

7 I n t e g e r i d ;

9 / / A n n o t a t i o n s o m i t t e d

10 S t r i n g name ;

11 S t r i n g u s e rname ;

12 S t r i n g p as s w o rd ;

13 L i s t <Overtime > o v e r t i m e s ;

15 @ManyToMany ( t a r g e t E n t i t y =" b u s i n e s s . Ro l e " )

16 @ J o i n Ta b l e ( name= " e m p l o y e e _ r o l e " ,

17 j o i n C o lu m n s ={ @JoinColumn ( name= " i d _e m p l o y e e " ,

18 re f e r e n c e dC o l u m nN a m e = " id _ e m p l oy e e " ) } ,

19 i n v e r s e J o i n C o l u m n s ={ @JoinColumn ( name= " i d " ,

20 re f e r e n c e dC o l u m nN a m e = " i d _ r o l e " ) } )

A Naked Objects based Framework for Developing Android Business Applications

355

21 @ A t t r i b u t e ( name= " Ro le s " , o r d e r = 5 , v i e w s ={ KindView . ALL

} )

22 L i s t <R ole > r o l e s ;

24 / / G e t t e r s an d S e t t e r s o m i t t e d

25 / / t o P r i m a r y D e s c r i p t i o n and t o S e c u n d a r y D e s c r i p t i o n

methods o m i t t e d

27 @Action ( name= " L o g i n " , o r d e r =1)

28 p u b l i c S t r i n g l o g i n ( ) {

29 r e t u r n n u l l ;

30 }

32 @Action ( name= " L o g o u t " , o r d e r =2)

33 p u b l i c S t r i n g l o g o u t ( ) {

34 r e t u r n n u l l ;

35 }

36 }

Listing 2: Source Code of Employee Class.

As previously mentioned, the enumerations are

identiﬁed and conﬁgured differently of the classes

since they consist of limited entities with a structure

already set. Listings 3 and 4 show the deﬁnition of the

enumerations Status and Role, respectively. In both

source codes, the @Enumeration annotation, in line 1,

is used to identify the enumerations that will be recog-

nized by JustBusiness, while the @Table annotation is

used in line 2 to create a table in the database whose

name will be the value of the name parameter.

1 @Enu mer ati on

2 @Table ( name= " s t a t u s " )

3 p u b l i c enum S t a t u s {

4 WAITING_FOR_APPROVAL{

5 p u b l i c vo i d a p p r ov e ( O ver t i me o v e r t i m e ) {

6 o v e r t i m e . s e t S t a t u s (WAITING_FOR_PAYMENT) ;

7 }

8 p u b l i c vo i d p a y ( Ove r t i me o v e r t i m e ) {

9 / / Do n ot h i n g

10 }

11 p u b l i c vo i d r e j e c t ( Ov e r t im e o v e r t i m e ) {

12 o v e r t i m e . s e t S t a t u s (CANCELED) ;

13 }

14 p u b l i c vo i d r e v e r t ( Ove r t i me o v e r t i m e ) {

15 / / Do n ot h i n g

16 }

17 } ,

18 WAITING_FOR_PAYMENT { } ,

19 PAID { } ,

20 CANCELED{ } ;

22 p u b l i c a b s t r a c t vo i d a p p r ov e ( O ve r t i me o v e r t i m e ) ;

23 p u b l i c a b s t r a c t vo i d pay ( Ove r t i me o v e r t i m e ) ;

24 p u b l i c a b s t r a c t vo i d r e j e c t ( Ov e r t im e o v e r t i m e ) ;

25 p u b l i c a b s t r a c t vo i d r e v e r t ( O ve r t i me o v e r t i m e ) ;

27 @ Over r ide

28 p u b l i c S t r i n g t o S t r i n g ( ) {

29 r e t u r n t h i s . name ( ) ;

30 }

31 }

Listing 3: Source Code of Status Enumeration.

1 @Enu mer ati on

2 @Table ( name= " r o l e " )

3 p u b l i c enum R o l e {

4 ADMIN,

5 EMPLOYEE,

6 SUPERVISOR ,

7 RH

8 }

Listing 4: Source Code of Role Enumeration.

Figure 8 displays the user interfaces for inserting

and detailing the automatically generated information

for the Overtime class from the information mapped in

the class code, as shown in Listing 1. Figure 9 shows

the user interfaces for the search operation and search

result listing by type Overtime objects. Figure 10

displays the screen that contains the list of all objects

of type Overtime. From that screen, the user can access

the individual objects and perform operations on them.

Figure 8: Entry and detail screens of object from type Over-

time.

Figure 9: Search and result list screens of objects from type

Overtime.

5.2 Evaluation

To assess the beneﬁts of using JustBusiness framework,

two comparative experiments have been conducted.

For the ﬁrst analysis, we developed two projects of the

same Android application based on the scenario de-

scribed in the previous detailed case study: the ﬁrst one

using the traditional development model, i.e., without

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

356

Figure 10: Listing screen of objects from type Overtime

JustBusiness framework, while the second one using

the framework. This assessment included a single pro-

grammer, who developed the two projects: initially

the one without the framework and, subsequently, the

other one using JustBusiness.

At the end of the implementation of the two

projects, it was found that the project developed with

JustBusiness achieved a reduction of approximately

96% of development time, 91% of written lines of code

and 94% of ﬁles created by the developer. Compara-

tive data for the two developed projects are detailed in

Table 3.

Table 3: Comparative analysis of JustBusiness and the Tra-

ditional Development.

Type of Development JustBusiness Traditional

Time 27 minutes 720 minutes

Lines written by

Developer 376 4315

Files created by

Developer 4 66

Total ﬁles in

the Project 66 66

To try to get around one of the threats to the validity

of that experiment, in which only one developer was

used, the second experiment consisted of another case

study, this time involving 4 developers, all with one

or two years of experience in Android development.

Their task was to implement, with and without the

framework, a simple project involving three business

classes, shown in the diagram of Figure 11.

In this case study, each developer has implemented

both projects individually, i.e., there was no collabo-

ration among them in any project. As in the ﬁrst ex-

periment, each developer ﬁrst implemented the project

without using JustBusiness and, after, using it.

At the end of the second case study, it was observed

that, on average, the project developed with JustBusi-

ness decreased approximately 93% of development

time, 93% of written lines of code and 96% of ﬁles cre-

ated by the developer, corroborating the results of the

Figure 11: Class Diagram of the Second Case Study.

previous experiment that indicated gains in productiv-

ity when the framework was used. Comparative data

for the two developed projects are detailed in Table 4,

where the values represent the arithmetic averages of

the individual values for each developer.

Table 4: Comparative analysis of JustBusiness and the Tra-

ditional Development of the Second Case Study.

Type of Development JustBusiness Traditional

Time 50 minutes 743 minutes

Lines written by

Developer 256 3935

Files created by

Developer 3 79

Total ﬁles in

the Project 79 79

Finally, we identify as other threats to the validity

of the experiments the developers’ knowledge level

in the Android platform and the difﬁculty level of the

developed projects. Although those factors possibly

would imply changes in the values of the items evalu-

ated for each developer, particularly the development

time and written lines of code, we believe that the

resulting values for the projects that used the frame-

work will be even lower than the ones obtained by the

projects without the framework due to the difference in

the number of ﬁles generated for both cases. We intend

to conduct other case studies to prove that hypothesis.

6 CONCLUSION AND FUTURE

WORK

This work presented JustBusiness, a framework for

developing Android business applications using the

Naked Objects architectural pattern. The main ben-

eﬁt of the framework is the automatic generation of

user interfaces and CRUD code, thus accelerating the

Android application development. Two case studies

have been carried out and demonstrated that the use of

A Naked Objects based Framework for Developing Android Business Applications

357

the framework promotes a gain in productivity, since

it reduces the development time and the number of

lines of code and ﬁles generated by developers, when

compared to solutions that have not used JustBusiness.

Despite its advantages, the framework has some

limitations, such as the support to only local data per-

sistence in SQLite database and the lack of customiza-

tion in the interfaces that were generated automatically.

As future work, we intend to add model-driven

developement techniques to the code generation task

and provide support for other data types, like images

and videos, and other data persistence mechanisms,

such as XML and JSON. Additionally, it is intended

to introduce validation mechanisms for forms compo-

nents. Finally, we plan to conduct a study to improve

the usability of the generated interfaces.

REFERENCES

(2008). Jmatter. http://jmatter.org/. [Online; accessed 9-July-

2015].

(2010a). Apache isis. http://isis.apache.org. [Online; ac-

cessed 9-September-2015].

(2010b). Naked object for android. http://sourceforge.net/

projects/noforandorid/. [Online; accessed 10-October-

2015].

(2010c). Robolectric. http://robolectric.org/. [Online; ac-

cessed 13-October-2015].

(2013a). Entities. http://entitiesframework.blogspot.com.br/.

[Online; accessed 7-October-2015].

(2013b). Isis android viewer. https://github.com/

DImuthuUpe/ISISAndroidViewer/. [Online; accessed

7-August-2015].

(2015a). Naked objects framework. http://

www.nakedobjects.org/. [Online; accessed 9-

September-2015].

(2015b). Naked objects mvc. http://nakedobjects.net/. [On-

line; accessed 9-September-2015].

(2015c). Ormlite. http://ormlite.com. [Online; accessed

14-October-2015].

Brandao, M., Cortes, M., and Goncalves, E. (2012). Entities:

A framework based on naked objects for development

of transient web transientes. In Informatica (CLEI),

2012 XXXVIII Conferencia Latinoamericana En, pages

1–10.

Broinizi, M. E. B., Ferreira, J. a. E., and Goldman, A. (2008).

Using annotations in the naked objects framework to

explore data requirements. In Proceedings of the 2008

ACM Symposium on Applied Computing, SAC ’08,

pages 630–637, New York, NY, USA. ACM.

da Cruz, A. M. R. and Faria, J. P. (2010). A metamodel-based

approach for automatic user interface generation. In

Petriu, D. C., Rouquette, N., and Haugen, O., editors,

Model Driven Engineering Languages and Systems,

volume 6394 of Lecture Notes in Computer Science,

pages 256–270. Springer Berlin Heidelberg.

Keranen, H. and Abrahamsson, P. (2005). Naked objects

versus traditional mobile platform development: a com-

parative case study. In Software Engineering and Ad-

vanced Applications, 2005. 31st EUROMICRO Confer-

ence on, pages 274–281.

Milosavljevi

c, B., Vidakovi

c, M., Komazec, S., and

Milosavljevi

c, G. (2003). User interface code gen-

eration for ejb-based data models using intermediate

form representations. In Proceedings of the 2Nd In-

ternational Conference on Principles and Practice of

Programming in Java, PPPJ ’03, pages 125–132, New

York, NY, USA. Computer Science Press, Inc.

Nilsson, E. G. (2009). Design patterns for user interface for

mobile applications. Adv. Eng. Softw., 40(12):1318–

1328.

Pawson, R. (2004). Naked Objects. PhD thesis, University

of Dublin, Trinity College.

Pawson, R. and Matthews, R. (2001). Naked objects: A

technique for designing more expressive systems. SIG-

PLAN Not., 36(12):61–67.

Pawson, R. and Matthews, R. (2002). Naked objects. In Com-

panion of the 17th Annual ACM SIGPLAN Conference

on Object-oriented Programming, Systems, Languages,

and Applications, OOPSLA ’02, pages 36–37, New

York, NY, USA. ACM.

Pawson, R. and Wade, V. (2003). Agile development using

naked objects. In Proceedings of the 4th International

Conference on Extreme Programming and Agile Pro-

cesses in Software Engineering, XP’03, pages 97–103,

Berlin, Heidelberg. Springer-Verlag.

Raja, A. and Lakshmanan, D. (2010). Article: Naked ob-

jects framework. International Journal of Computer

Applications, 1(20):37–41. Published By Foundation

of Computer Science.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

358