Noname manuscript No.

(will be inserted by the editor)

The impact of the code smells of the presentation

layer on The diffuseness of aesthetic defects of
Android apps

Mabrouka Chouchane · Makram Soui ·

Khaled Ghedira

Received: 20/11/2019 / Accepted: 14/09/2021

Abstract Recently, the number of Android apps has witnessed an ever-increase

that is becoming a ubiquitous presence in our daily lives. These apps are
evolving fast by offering new characteristics and functionalities. These ongo-
ing improvements often affect app quality due to bad design practices and
poor coding, known as Android code smells. In this context, the recent works
highlighted the importance of the design quality of mobile application. To this
end, many methods and tools are proposed to assess the quality of Graphi-
cal User Interface (GUI) and source code of Android apps, such as heuristic
evaluation and field-testing, etc. In addition, the features and design of these
Android apps may introduce bad design practices, that can highly decrease the
quality and the performance of these Android applications. In this paper, we
empirically study the diffuseness of GUI aesthetic defects and the code smells
of the presentation layer of Android apps. Then, we investigate the impact of
the appearance of code smells on the aesthetic of Android apps. To this end,
we use two evaluation tools. The first one is called PLAIN which consists of
detecting aesthetic defects by measuring a set of structural metrics of GUI.
The second one is Android UI Detector which aims to identify the presentation
layer code smells of Android apps. This analysis study is based on 8480 GUIs
of 120 Android apps. The obtained results confirm that code smells of the
presentation layer of Android apps have an impact on GUI aesthetic defects.

Mabrouka Chouchane
School of computer science of Manouba, Tunisia
E-mail: chouchane.mabrouka@gmail.com
Makram Soui
College of Computing and Informatics Saudi Electronic University, Saudi Arabia
E-mail: m.soui@seu.edu.sa
Khaled Ghedira
Private Higher School of Engineering and Technology, Tunisia
E-mail: khaledghedira3@gmail.com
2 Mabrouka Chouchane et al.

Keywords Graphical Android User Interface · aesthetic metrics · Presenta-

tion layer · Android apps.

1 Introduction

With the speed of technological evolution, the availability of apps to download

started to evolve day after day. As a result, the average of downloaded apps
has increased to reach 8.8% per month, while the rate of app installation in-
creases to attain 5% year over year. [1]. According to [2], the average cost per
app installation is 2.33 Dollar for Android. In fact, Android leads the market
share of device operating systems with 69.18% compared to iOS which has
25.02% of market share. In addition, the number of apps available on Google
Play Store increases more than 2 million apps in 2017 [3]. As mobile technolo-
gies became widespread, users will be more motivated to use more portable
devices and interacting with Android applications that satisfy their needs and
expectations. In this context, users became more demanding in terms of us-
ability and performance of these Android applications.

The evaluation of Android application is a complicated process than other

software applications [4–6]. In fact, the development of the Android appli-
cations consists on the reuse of many smaller libraries compared to different
software applications [7]. In addition, the shortest release deadlines of Android
applications let the developers revolve on the implementation of the required
functionalities rather than focusing on the various quality criteria [8]. As a re-
sult, many bad design practices could be arise during the development phase of
Android apps and introduce several bad qualities which known as code smells.

The detection of Android code smells process drawn the attention of several
authors [8–10] who define manually the related symptoms of each code smell
type in Android apps, then translating them into a combination of quality
metrics with their thresholds to design detection rules. In this context, defin-
ing manually these rules that can be used to detect the symptoms of code
smells is not easy, because there are several possible combinations of different
metrics with various thresholds values. In addition, several code smells can be
associated to same symptoms. As a result, there is no consensus about the
best definition of the symptoms of each code smell.

One of the practically used methods to evaluate GAUIs is through empirical

evaluations, which aim to assess the quality by observations based on ques-
tionnaires and experts or end-users’ feedback. This process is productive but
at the same time it is manual, time-consuming and very subjective [11–13]. In
the field of Human Computer Interaction (HCI), several studies analyzed the
aesthetic quality of GAUIs using the manual definition of what is considered a
bad design decision and the detection of such patterns that used the declara-
tive rules definitions [11, 14, 15]. In fact, rules are manually defined to identify
Title Suppressed Due to Excessive Length 3

problems using combinations of aesthetic metrics and theirs thresholds. These

aesthetic metrics are based on a set of user interfaces attributes (number of
interface components, the number of the alignment points, the number of col-
ors, etc.). In fact, in an exhaustive scenario, the number of possible defects
and the number of aesthetic metrics used to construct rules manually can be
large. Thus, these manual techniques have several limitations such as more
time-consuming and requires great human expertise. Also, there are diverging
expert’s opinions. It is still also a subjective inspection and error-prone strat-
egy. To overcome these limitations, we used two automatic tools. The first one
is called PLAIN which consists of detecting aesthetic defects by measuring a
set of structural metrics of GUI. The second one is Android UI Detector which
aims to identify the presentation layer code smells of Android apps.

In the same context, some of the previous work examined how code smells
are introduced [16, 17], how it is developed over time [18–20], and how smells
affect the quality of applications, such as fault and change-proneness [21, 22],
code comprehensibility [23] and program maintainability [24–26]. Similarly,
other existing works [21, 27] studied the correlation between code change/fault-
proneness and the occurrence of code smells in projects. However, these works
focused only on code smells and its evolution. There are a lack of studies in the
fields of human computer interaction that take in consideration (i) the evolu-
tion of aesthetic defects of GAUI (Graphical Android user interface) and (ii)
the impact of the presentation layer quality of Android apps on the presences
of aesthetic defects.

Several existing methods and tools have been proposed to evaluate the
quality of Android apps. These studies can be classified into two categories:
(1) aesthetic defects detection which aims to discover the design issues of GAUI
of Android apps, and (2) code smells detection which consists to identify the
code problems of presentation layer of Android apps. However, in the best
of our knowledge, until now, there is no existing studies that analyzes the
relationship between the diffuseness of aesthetic user interface and the pre-
sentation layer code smells of Android apps. In this way, our work represents
the first attempt to study the impact of code smells on the aesthetic defects
of GMUI. In fact, our findings provide an idea for developers to improve the
quality of Android apps by considering the relationship between the aesthetic
and code smells. In the maintenance task, they should correct the Android
code smells without the introduction of aesthetic defects.

To study the impact of the diffuseness of Android code smells on the ap-
pearance of GAUI aesthetic defects, we will exploit the widely known metrics
related to the aesthetic quality. To this end, we use an existing plugin called
PLAIN (PLugin for predicting the usAbility of mobile user INterface) [28]
to identify the most interesting aesthetic defects. Regarding the quality code
smells, we use Android UI Detector tool which aims to detect the well-known
15 code smells in order to assess the presentation layer quality of Android apps.
4 Mabrouka Chouchane et al.

After the identification of the two types of smells, we calculate the occurrence
of the GAUI design defects and Android code smells. Then, we determine the
correlation between aesthetic and code smells based on Spearman test corre-
lation to discover its relationship.

In analytical point of view, our analysis aims at verifying and/or rebutting

the relationship between the GUI defects and code smells of Android apps. In
realistic point of view, the results of this study will enable developers to dis-
cover the best way to correct code smells without creating the design defects of
GUI that can affect Android apps. Understanding the impact of presentation
layer quality of Android apps on aesthetic defects can facilitate the mainte-
nance of these applications. It also lets developers improve as much as possible
the usability and UX of Android apps. Furthermore, analyzing the diffuseness
of aesthetics defects in such Android app can help developers to assess the
quality of their application and avoid those defects from the implementation
phase.

This paper is structured as follows: Section 2 presents the related work.

Section 3 describes the major concepts related to the evaluation of Android
application. Section 4 introduces the empirical study to evaluate the quality
of Android apps. Section 5 describes the experiments and obtained results. In
section 6, we give the conclusion and future work.

2 Related work

2.1 Android code smells evaluation

The definition of Android code smells is a strenuous task for many developers
who try to overcome the bad quality and trying to improve the maintainability
of their applications. In this context, there are several studies that focus on
the definition of code smells of Android application [8–10, 29, 30].

Reimann [9] introduces a quality smells catalog which contains 30 Android

quality smells and symptoms. This catalog explains the influence of these code
smells on the quality of the application functionality. To this end, Refactoring
tool is used to detect the quality smells then it proposes the possible refactor-
ing operations that fix these quality smells.

Mercaldo et al. [31] conducts an exploratory study on the evolution of An-

droid malware quality. The idea is to measure a set of software quality metrics
that are divided into four groups ( i.e. dimensional metrics, complexity met-
rics, object-oriented metrics, and Android-oriented metrics) in order to define
the evolution of such metrics in Android malware and good ware applications.
However, a large-scale empirical study of the complexity evolution of Android
apps was conducted by [32]. This study focused on six metrics to measure the
Title Suppressed Due to Excessive Length 5

complexity of Android apps. The obtained results confirm that after the main-
tainability of Android apps, the complexity of these applications is reduced.

In another point of view, [30] proposed an empirical catalog of code smells

in order to assess the presentation layer of Android apps. The aim is to dis-
cover the code smells that developers perceive for this part of Android apps.
In more detail, they proposed 20 specific code smells. Then, they collected
the developers’ perceptions of the frequency and importance of these smells.
Next, they implemented a tool to detect these code smells and examined their
frequency in 619 open-source Android apps.

2.2 Code smells diffuseness

Several studies[33–37] focused on the relationship between code smells types.

These studies aim to verify the impact of the correction of these smells in the
change-size of such application and the cost of maintenance.

In this context, Olbrich and Cruzes [33] have examined the relationship
between two types of code smells: God and Brain classes by considering their
change frequency and change-size during different releases. The results reveal
that the class size makes God and Brain classes more vulnerable to defects.
Therefore, the frequency of code smells can be minimized by separating fea-
tures into different classes.

To better demonstrate the relationship between infected code classes and

class change-size, Khomh et al. [35] conducted an analytical study on thirteen
different variants of Azureus and Eclipse projects by considering nine code
smells. The observations indicate that, across all versions of these projects,
the smelly classes are more vulnerable to change than the non infected ones.
They also note that there is a difference in term of ability to change based
on the type of smell. In the same way, Li and Shatnawi [34], investigated the
relationship between code smells and a class error probability in three releases
of Eclipse (3.0, 2.1, 2.0). The findings confirm that the infected classes by code
smells like Shotgun Surgery, God Class, and God Methods are likely to have
the highest error probability than the non-infected ones.

Tufano et al. [38] aim to evaluate the developer’s perception of test smells.
These experiments conclude that the detection of test smells is considered as
a complicated task that requires an automation process. The findings also re-
vealed that the commitment of test code gives rise to the introduction of test
smells.

Bavota et al. [39] studied the impact of smells on test code understand-
ability and maintainability. In another study, they empirically investigate the
diffusion of test smells in both open-source and industrial software systems
6 Mabrouka Chouchane et al.

[40]. The results confirm that the JUnit tests are diffused by 86% able to ex-
hibit at least one test smell. However, these findings also reveal that these test
smells have a strong negative impact on program comprehension and mainte-
nance.

However, to the best of our knowledge, until now, there is no existing study
that analyzes the relationship between the diffuseness of aesthetic user inter-
face and the presentation layer code smells of Android apps. In this way, our
work represents the first attempt to study the impact of code smells of the
presentation layer of Android apps on the aesthetic defects of GMUI. To cope
with this limitation, we use an automated tool called Android UI Detector
proposed by [30] which aims to detect 15 Android code smells extracted from
the source code of Android apps in order to evaluate the presentation layer of
Android apps.

3 Background and Motivation

In this section, we present some concepts that are prerequisites for our pro-
posed approach and an illustrative example to more understand the objective
of this study.

3.1 Background

3.1.1 Aesthetic evaluation of Android user interface

Aesthetic defects are symptoms of bad user interface design programming

decisions. These defects lead to deteriorate the perceived usability of Android
user interfaces and negatively impact the User’s eXperience (UX) with the
Android app. Aesthetic defects are a violation of quality attributes which
makes graphical user interface hard to understand by user. In literature review,
we find a large list of aesthetic defects of Android user interface. In our work,
we focus on the following eight defects presented in Table 1 and proposed by
[41].
To detect these aesthetic defects, several metrics have been used in HCI.
In this work, we use a set of evaluation metrics, presented in Table 2, that
are previously validated using several ergonomic criteria proposed by [28]. In
fact, these structural metrics are adapted to evaluate the aesthetic aspect of
Android user interface.

3.1.2 Android code smells Detection

Code smell is defined as bad design practices that may affect the quality of an
application such as maintainability, understandability, and so on [42]. In the
Title Suppressed Due to Excessive Length 7

Table 1 Aesthetic defects.

Aesthetic Defects Descriptions

Incorrect layout of widgets (ILW) It is related to the incorrect arrangement of
MUI components
Overloaded MUI (OM) It is a bad density of MUI. In other words,
users find the mobile interface too dense and
so difficult to read.
Complicated MUI (CM) It is related to the MUI that includes too many
widgets and features which cannot meet the
users’ needs.
Incorrect data presentation (IDP) It is the incorrect extraction of information
and their display on the mobile screen.
InCohesion of MUI (ICM) It is the lack of the interrelatedness of MUI
components.
Difficult navigation (DN) It is the of lack descriptive labels that can be
used to define the additional information.
Ineffective appearance of widgets It occurs when MUI widgets follow an unex-
(IAW) pected layout.
Imbalance of MUI (IM) It is an unequal distribution of the quantity of
interactive objects of a MUI.

Table 2 Aesthetic metrics.

Aesthetic Metrics Descriptions

Regularity It measures the consistency spacing between
all the MUI components.
Composition It counts the number of MUI components that
are semantically linked in the same boundary.
Sorting It aims to rank MUI components in a logical
and sequential ordering according to the eye
movement.
Complexity It measures the complexity of interface by
counting the number of rows and columns on
the interface.
Integrality It count the number of different sizes of MUI
components and the number of spacing be-
tween it.
Density It measures the total number of components
in the MUI.
Symmetry It aims to have an equal distribution of MUI
components on the right and the left side of
MUI.
Repartition It refers to the distribution of the components
on the mobile user interface.

literature, code-smells, also called bad smells [43], design flaws [19], anomalies
or anti-patterns [44]. There are considered as a metaphor to describe prob-
lems resulting from programming practices and bad design. However, to the
best of our knowledge, until now, there is no existing study that analyzes the
relationship between the diffuseness of aesthetic user interface and the presen-
tation layer code smells of Android apps. In this way, our work represents the
first attempt to study the impact of code smells of the presentation layer of
8 Mabrouka Chouchane et al.

Android apps on the aesthetic defects of GMUI. In this context, we use an

automated tool called Android UI Detector proposed by [30] which aims to
detect 15 Android code smells extracted from the source code of Android apps
in order to evaluate the presentation layer of Android apps. In fact, the presen-
tation layer integrates a set of components (Activities, Fragments, Adapters,
and Listeners) as well as a set of resources (Layout, Strings, Style, and Draw-
able) (see table 3). In our work, we consider 15 Android code smells related to
the presentation layer and proposed by [30]. Table 4 summarized the Android
code smells descriptions.

Table 3 Presentation layer components and resources.

Elements Descriptions
Component Ele-
ments
Activity Designed the UI screen of the Android app, and it is respon-
sible on the configuration and interaction of the UI
Fragment It is the responsible part of an activity which divides the
activities into encapsulated and reusable components that
have their own life cycle and their own GUI.
Adapter It acts as a link between an adapter view and a set of col-
lected data for this view. It supplies the access to the data
items.
Listener It represents a set of interfaces that provide one or more
methods which can therefore be implemented differently de-
pending on the case and the needs, to respond to events.
Resources elements
Layout It is a visual representation of the Android application. The
layouts can be built from an XML file or directly in the Java
code, at the time of execution of the application.
String It is used to define text strings for the Android application
with optional text styling and formatting.
Style It defines the appearance and shape of Android components
in XML resource files.
Drawable It is a general concept for a graphic which is drawn on the
screen and retrieved with APIs or applied to another XML
resource.
Title Suppressed Due to Excessive Length 9

Table 4 Android code smells descriptions.

Android code smells Descriptions

Component smells
Brain UI Component (BUC)
Coupled UI Component
(CUC)
Suspicious Behavior(SB)
FLex Adapter (FLA)
Fool Adapter (FA)
Excessive Use of Fragments
(EUF)
No Use of Fragments (NUF)
Resource smells
Magic Resource (MR)
Deep Nested Layout (DNL)
Long or Repeated (LR)
Missing Image (MI)
God Style Resource (GSR)
God STring Resource
(GSTR)
Duplicate Style Attributes
(DSA)
Hidden Listener (HL)
It tested the existence of code related to business logic,
I/O operations, conversion of data, or static fields in
presentation layer.
It tested the existence of direct reference to Activities
or Fragments in the elements of presentation layer.
It occurs when developers use of anonymous classes or
internal classes in listeners implementation in order to
reply to user events.
It emerges when Adapters contain business or view
logic.
It arises when Adapters don’t reuse instances of views
that correspond to the fields to be filled using the View
Holder pattern for each item.
This smell emerges when Fragments are used without
an explicit need.
The non-use of fragments can be a smell in visually
rich apps. Such apps have a high number of different
behaviors, animations, and events to handle.
It occurs when resources (e.g., layout, string, and
style) have a complicated code instead of referring to
an existing resource file.
This smell emerges when developers uses multiple
nested layouts when constructing layout resources.
It appears when long or duplicated layout resources
occur in the source code.
It occurs when the system has only a single version of
.png, .jpg, or .gif images.
It occurs when all styles are defined in the same
styles.xml file.
This smell is defined by Long string resources.
It is indicated by the existence of duplicated style def-
initions in different components.
it appears when the layout resources also configure the
listener that will respond to events, such as the onClick
event.

3.2 Motivation example

To better demonstrate the motivation of this study, we evaluate the source

code of an application called Newpipe. As shown in figure 1, this application
is infected by the God Style Resource (GSR) code smell because all the re-
quired styles are defined in the same XML file (styles.xml).
In the same time, we observe that this application has two user interfaces
that suffer from the overloaded MUI defect. The first one is ”About” and the
second one is ”settings” (see figure 2).
10 Mabrouka Chouchane et al.

Fig. 1 An extract from styles.xml file

Fig. 2 An extract of About GAUI (left) and Settings GAUI (right)

To fix the GSR code smell, we distribute the resources declared in style.xml
file into three different XML files to reduce the number of LOC in the resource
file. Figure 3 shows the new structure of the resources files. As depicted in
figure 4, after this improvement in the source code, we note also that the
overloaded MUI defect is fixed. In this way, we decide to conduct an empirical
study to discover the impact of the code smells of the presentation layer on
the diffuseness of aesthetic defects of Android apps.
Title Suppressed Due to Excessive Length 11

Fig. 3 The new structure of the resource files.

Fig. 4 The new structure of the studied GAUI.

4 Empirical Study Definition and Design

The purpose of this work is to study the diffuseness of 8 aesthetic defects in 120
Android apps (8480 GAUIs) and the impact of code smells on the generation of
the GUI defects. The study is conducted by addressing the following research
questions:
– RQ1:Up to what level are the considered aesthetic defects and code smells
diffused in the studied Android apps?
– RQ2: To what extent the code smells affect the aesthetic defects for a
given Android apps ?
12 Mabrouka Chouchane et al.

– RQ3: How accurately the aesthetic metrics predict the code smells for a
given Android app?

The aim of the first research question (RQ1) is to study the diffuseness of
aesthetic defects and code smells with the goal of investigating the relevance
of the considered smells based on its occurrences.

The second research question (RQ2) investigated the relationship between

the design smells and the presentation layer code smells of Android apps. The
goal is to check whether the presence of code smells has an impact on the
aesthetic defects diffuseness.

However, research question 3 (RQ3) aims at proposing an accurate model

to detect code smells based on aesthetic metrics.

4.1 Data Collection

To answer our research questions, we selected 8480 user interfaces of 120 open-
source Android apps that will be evaluated in order to identify the code smells
and aesthetic defects. These applications have different sizes (from 3 to 540
UIs), related to different application fields (education apps, entertainment,
health, gaming, etc.). The used Android apps have different user rating (30
apps with a high user rating, 36 apps with lower user rating and 34 apps have
medium user rating). Our experiments are based on the source code of these
apps hosted in open-source repositories and found on GitHub [45].

The manual evaluation of these applications is a hard task and very ex-
pensive. To this end, we used an automatic tools to identify two categories of
smells. The first one is PLAIN which parses the dump file of Android emulator
to measure the aesthetic metrics based on the properties values of the GAUI
components. The second one is Android UI Detector tool which determines
a set of heuristics in order to identify the presentation layer code smells of
Android apps.

4.2 Smells Detection and Empirical Analysis

In this subsection, we give an overview of the aesthetic defects and code smells
detection by analyzing the source code of Android apps with the goal of inves-
tigating whether the presence of code smells affects the aesthetic defects. As
depicted in figure 5, our approach has five phases: 1) Source code parser, 2)
Aesthetic metrics computation , 3)Code smells detection Strategies, 4) Aes-
thetic defects detection, 5) Empirical investigation phase.
Title Suppressed Due to Excessive Length 13

Fig. 5 Aesthetic defects and code smells detection and data analysis
14 Mabrouka Chouchane et al.

4.2.1 Source code parser

The goal of this phase is to parse the source code of the studied Android apps
in order to extract code properties (number of classes, number of activities,
number of fragment, etc.). The extracted code properties are used to identify
the code smells. The extraction process is based on two parsers. The first one
is JavaParser which parses Java files in a lightweight and straightforward way,
while the second one is JDOM which analyses the XML files [30].

4.2.2 Aesthetic metrics computation

In this phase, we used the plugin developed by Soui [28] in order to evaluate
the quality of Android applications. This plugin parses the source code of
GAUI to extract properties values of GAUI components. This plugin exploits
extracting (width, height, alignment, axis of coordinates for the left top point
of an object, etc) that are used to measure the quality metrics.

4.2.3 Android code smells detection

This phase aims to identify the code smells related to the presentation layer
of Android apps. To this end, the Android UI detector tool proposed by [30]
is used to detect 15 Android code smells. This tool is based on three type of
detection strategies: decidable rules, threshold based rules and heuristic rules.

4.2.4 Aesthetic defects detection

This phase aims to detect the aesthetic defects based on a java plug-in called
PLAIN suggested by [28]. In fact, the detection defects of GAUI process is
based on the evaluation rules proposed by [46]. These rules are a combination
of a set of context criteria, 8 aesthetic metrics described in table 2 and the
8 aesthetic defects proposed by [41] (table 1). For example, we can consider
the following evaluation rules used to detect aesthetic defects where the IAW
defect is detected using the rule R1 while OM defect is identified using the
rule R2 based on a combination of a set of metrics values.

R1: IF (Interest= Low) and (Sorting <=0.32) THEN IAW.

R2: IF (Motivation= Low) and (Density >=0.82) THEN OM.

4.2.5 Empirical investigation phase

To perform our empirical study, we proceeded in the following way:

– We study the diffuseness of aesthetic defects and code smells in 120 Android
apps that include 8480 GAUI. The aim is to identify the most frequently
aesthetic defects and code smells present in the tested Android apps based
on the co-occurrence of these two types of defects.
Title Suppressed Due to Excessive Length 15

– We study the impact of code smells on the aesthetic defects of GMUI.

The idea is to verify whether the presence of Android code smells affects
the design defects of GAUI. To this end, we used the Spearman’s Rank
Correlation Coefficient (Rs) [47] to discover the relationship between the
two types of smells. This coefficient (Rs) is calculated as following:
6 d2
P
Rs = 1 − ( 3 ) (1)
n −n
Where d is the differences between each pair of ranks and n is the volume
of the sample. The work of Cohen [48] presented a set of instructions for
evaluating the coefficient of correlation. It is supposed that:
• There is no correlation if p-value = < 0.
• A moderate correlation if 0.1< p-value < 0.3.
• A medium correlation if 0.3< p-value < 0.5
• A strong correlation if 0.5< p-value <1
– We propose a prediction model to detect the code smells related to the
presentation layer of Android apps. To this end, six machine learning algo-
rithms are applied to build a model for detecting the code smells of Android
apps based on the aesthetic metrics.In this context, several studies are pro-
posed to detect code smells based on code metrics using machine learning
algorithms [49–51]. However, we note a lack of studies that focus on the de-
tection of Android code smells based on structural aesthetic metrics related
to GAUI. In our work, we studied the efficiency of six machine learning
algorithms to build an accurate model in order to predict the Android code
smells related to the presentation layer of Android apps:
• Support Vector Machine (SVM) [52]:It is a discriminative classifier that
is formally designed by separative hyperplane. It is a representation of
examples as points in space that are mapped so that the points of
different categories are separated by a gap as wide as possible. Support
vectors are the points which are very close to a dividing line. the support
vectors can be used to select the best line to divide the data. In addition,
it performs non-linear classification. Non-linear SVM is used when the
data can’t be separated using a straight line. It is effective in high
dimensional spaces.
• Random Forest (RF) [53]: It is an ensemble machine learning algorithm,
which is operated by building multiple decision trees. Decision tree
builds classification models in the form of a tree structure. It breaks
down a dataset into smaller subsets. Random forest develops lots of
decision tree based on random selection of data and random selection
of variables. The decision of the majority of the trees is chosen by the
random forest as the final decision.
• Artificial Neural Network algorithm (ANN [54]: It is a component of a
computer machine built to replicate the way the human brain analyzes
and processes information. It generates decisions based on what it has
learned from the data. ANN assembles algorithms in a way that it
can produce accurate decisions by itself. It imitates the behavior of a
16 Mabrouka Chouchane et al.

biological neuron by integrating the values of the inputs it receives. If

this value is more than a certain threshold, it transfers its own signal
to its output, which is then collected by other neurons. A neuron, on
the other hand, would not have to consider each of its inputs equally.
• Multilayer Perceptron (MLP) [50]: This is a representation of an artifi-
cial neural network. It was used to fix a different set of problems. It is an
improvement of the neural model of perception of the network. Through
one or two hidden layers, almost any problem can be solved. They are
forward neural networks trained with a back propagation algorithm.
• Decision Tree [55]: is a supervised machine learning approach to solve
classification and regression problems by continuously splitting data
based on a certain parameter. The decisions are in the leaves and the
data is split in the nodes. In Classification Tree the decision variable
should be categorical, and for this reason, it is often referred to as a
statistical classifier.
• Naive Bayes [56] : It’s a simple algorithm for predictive efficient models.
The model is made up of two kinds of probabilities, both of which can
be measured using the training data: 1) the probability of each class,
and 2) the conditional probability of each class given each value. Once
the probability model has been calculated, the Bayes Theorem can be
used to predict new results.
To build the accurate model, we used a dataset which contains 8480 in-
stances. This dataset includes eight attributes that represent the aesthetic
metrics. In fact, each value of aesthetic metric ranges between [0,1]. The
class label is the code smell which is detected in the studied classes of An-
droid apps. In our work, we use the 10 cross-validation method to evaluate
the efficiency of the studied machine learning algorithms. In addition, the
classification accuracy of the proposed model depends on the parameter
setting of the used machine learning algorithms. Due to the huge number
of possible combinations of parameter values, adjusting them manually be-
comes impractical, unproductive, time-consuming, and frequently requires
a deep understanding of the models. However, the automatic optimization
of hyperparameter is needed in order to solve these issues. According to
[57], the most extensively used algorithms are genetic algorithms (GA) and
particle swarm optimization (PSO). In this work, GA is used to determine
the best set of hyperparameters, and the results were presented in Table 5.
The main parameters of SVM are: the kernel function, the cost of classifi-
cation C and the kernel parameter (gamma). In our work, the RBF kernel
function provides the best results compared to other functions (sigmoid,
poly, and linear). The classification cost values is 10. The kernel parame-
ter Gamma values is 0.5. In another hand, RF needs the definition of two
parameters for generating this prediction model which are the number of
regression trees and the number of evidential features (m) which make, in
each node, regression trees grow. The range of the number of trees was set
between 0 and 1400, and the number of evidential features is between 0
and 50. For the ANN algorithm, it provides the best results when it has
Title Suppressed Due to Excessive Length 17

only 20 hidden layer, the number of epochs is initialized to 50, the number
of neurons in each layer is 150 and the learning rate and the momentum
rate are 0.8 and 0.5 respectively. In the other hand, MLP gives the best
results when the size of hidden layer is 150 and the values of learning rate
and random state are 0 and 0.8 respectively. Regarding the decision tree
algorithm, the highest accuracy rate is obtained when the number of es-
timators is equal to 150 and random state is 1. On the bright side, the
Naive Bayes algorithm provides the best results when the value of alpha
parameter is 0.0001.

Table 5 Parameters setting for used algorithms.

Algorithms Parameters
Kernel function= RBF Kernel
SVM C(cost)= 10
Gamma=0.5
Number of regression trees= [0,1400]
RF
Number of evidential features= [0,50]
Number of epochs= 50
Number of hidden layers=20
ANN Number of hidden units= 150
Momentum rate= 0.5
Learning rate= 0.8
Hidden layer sizes= 150
MLP Learning rate= 0.8
Random rate =0
Number estimators= 150
Decision Tree
Random rate= 1
Naive Bayes alpha= 0.0001

4.3 Data Analysis

To answer RQ1, we determine the diffuseness of code smells and aesthetic

defects in each application. The idea is to observe the co-occurrence between
the two type of smells.
To answer RQ2, we perform a spearman correlation to discover the relation-
ship between code smells and aesthetic defects of Android apps by testing the
following hypotheses:
– H0: There is no relationship between GAUI aesthetic defects and code
smells.
– H1: The code smells have a significant impact on the aesthetic defects.
To answer RQ3, we study the efficiency of six studied machine learning algo-
rithms (SVM, MLP, RF, J48, Simple logistic and decision table) to accurately
predict the code smells of Android apps by building a correct model.
18 Mabrouka Chouchane et al.

5 Results Analysis

To assess our work for Android apps evaluation, we conducted a set of exper-
iments based on 120 Android applications with source code hosted in open
source repositories and found on [45]. The goal of the study is: (i) assessing
the diffuseness of aesthetic defects and code smells in the tested Android apps,
(ii)investigating how the existence of such a code smell has a positive impact
on the occurrence of aesthetic defects of the same apps, and (iii) building an
accurate model to predict the code smells based on the aesthetic metrics.

5.1 Up to what level are the considered aesthetic defects and code smells
diffused in the studied Android apps?

In this subsection, we study the diffuseness of aesthetic defects and code smells
in each Android app based on the co-occurrence of these two types of defects.
At this level, we used PLAIN to determine the number of aesthetic defects
and Android UI Detector tool to detect the code smells. Figure 6 highlights
the diffuseness of aesthetic defects.
The first thing that leaps to the eyes is that aesthetic defects such as
Incorrect Data Presentation (IDP), Incorrect Layout of Widgets (ILW) and
Imbalance of MUI (IM) are poorly diffused. The percentage of ILW diffuse-
ness is 0.42% in all the studied apps. The highest number of its appearance
is 9 times in Nectrod app. While, IM defect affects 1% (222 instances) of the
evaluated GMUIs. For example, in the most affected application (aCal app)
which has 500 GAUIs, the IM defect is present only 14 times. For IDP defect,
the percentage of its diffuseness is 1.34% out of 8480 evaluated GAUIs (302
instances in 120 Android apps). In fact, the highest peak of its appearance
is 30 in BatteryDrog app. In another hand, other aesthetic defects are very
diffused. The most frequent aesthetic defect identified in all the tested apps
is Overloaded MUI (OM), with a percentage of 28% of the total number of
aesthetic defects detected in 8480 GAUIs. We mention that Overloaded MUI
defect is present in all the studied applications, with a probability of 73.75%
to be present in a given GAUI. In weather app, OM defect is the most fre-
quent defect which affects 265 GAUI among 370 GAUIs with the percentage
of 71.63%. Another proliferated aesthetic defect is Complicated MUI, that af-
fects the totality of the releases, with a probability of 22.84% in all the GAUIs.
Quicksettings app is the most infected app by this defect. It is present in 230
GAUIs among the total number of UI of this app. Finally, Difficult naviga-
tion defect affects 4100 GAUIs of the total number of studied GAUIs (8480
GAUIs), with a percentage of 18.29% of the total number of aesthetic defects
detected in all GAUIs. The highest number of occurrences of this defect is 150
in OpenLauncher app.
Title Suppressed Due to Excessive Length 19

Fig. 6 Aesthetic defects diffuseness.

In another hand, figure 7 shows the diffuseness of the Android code smells
in all the studied apps. For instance, the most frequent Android code smell
detected in all the tested classes is Suspicious Behavior (SB) with a percentage
of 5.7% of the total number of the studied classes and with a probability of
56.16% that a given class is infected by this smell. Among the 10,130 ana-
lyzed classes, this smell affects 5,690 classes of the studied Android apps. The
highest number of occurrences of SB smell is 570 in the Quicksettings app.
Another frequently diffused code smell is God String Resources (GSR) with a
high number of occurrences equal to 5,490 in all the classes of studied apps.
This smell is present with a probability of 5.5% in a given class followed by
God STyle Resource (GSTR), Deep Nested Layout (DNL) and Brain UI Com-
ponent (BUC) smells that are present with a likelihood ratio of 5.3%. While,
we find that FLex Adapter (FLA), Missing Image (MI) and Excessive Use of
Fragments (EUF) are not frequent smells as they have a maximum number of
occurrences per class that do not exceed 1.17%. The findings of our empirical
study confirm the same conclusion found by [30] which affirm that SB, GSR,
GSTR and DNL are highly diffused smells and FLA, MI and EUF are not
frequent smells.

Fig. 7 Code smells diffuseness.

Furthermore, Table 6 reveals the co-occurrence between the most diffused

code smells and aesthetic defects in the studied applications. The ”% affected
20 Mabrouka Chouchane et al.

apps” column reports the percentage of analyzed GAUIs in which we found

at least one instance of a specific defect type. The ”Name of app” column
represents the name of application in which the specific defect type has the
maximum number of instances. The ”Number of code smells” column reveals
the number of distinct code smells that affects the application which has the
maximum number of instances. According to the results shown in table 6, we
can deduce that the application how has the highest number of the most dif-
fused defects, has also the highest number of different smells.

Table 6 The co-occurrence of the most diffused aesthetic defects and code smells.

Aesthetic % affected apps Max. number Name of app Number of

Defects of instances code smells
OM 73,75% 265 weather 13
CM 60,37% 230 Quicksettings 9
DN 48,34% 150 OpenLauncher 7
IAW 39,15% 86 Zooborns 6

As a matter of fact, the results of this research question (RQ1) confirm that
the most diffused code smells and aesthetic defects of Android apps are the
most relevant ones. In addition, we conclude that the most diffused aesthetic
defects appear in the largest classes of Android apps. Moreover, we deduce that
the application which has the highest number of the most frequent defects, has
also the highest number of smells. These findings help developer to prioritize
the correction of these critical smells by fixing the most important, riskiest
and severest ones.

5.2 To what extent the code smells affect the aesthetic defects for a given
Android apps?

To answer the second research question, we used the Spearman rank corre-
lation analysis [47]. To this end, we determine the correlation between the
number of occurrences of aesthetic defects and Android code smells of the
same application. The following tables summarize the obtained results. The
findings are intended as statistically significant at alpha= 0.01.
Table 7 The correlation Rs between code smells (BUC, CUC, SB, FA, EUF, NUF, FLA) and aesthetic defects

Aesthetic defects
DN IAW ICM IDP ILW IM OM CM
Code smells

T-test 1.067 0.577 9.66 0.78 4.115 1.654 4.115 6.83

BUC RS 0.197 0.108 0.877 0.145 0.613 0.29 0.88 0.790

p-value 0.147 0.284 1.025e-10 0.220 3.72e-14 0.123 1.025e-10 1.001e-07

T-test 1.12 0.524 0.226 1.12 5.25 2.208 6.693 9.66

CUC RS 0.207 0.098 0.042 -0.024 0.746 0.385 0.784 0.877

p-value 0.135 0.301 0.411 0.55 1.025e-10 0.017 1.44e-7 1.02e-10

Title Suppressed Due to Excessive Length

T-test 13.594 0.425 0.919 2.51 0.823 2.51 9.66 13.594

SB RS 0.84 0.08 0.171 0.428 0.153 0.428 0.877 0.931

p-value 3.72e-14 0.337 0.182 0.009 0.208 0.009 1.02e-10 0.0001

T-test 1.341 1.22 1.62 1.019 0.778 0.226 -0.518 0.47

FA RS 0.47 0.55 0.292 0.189 0.145 -0.042 -0.0970 -0.045

p-value 0.11 0.33 0.058 0.158 0.221 .588 0.696 1.758

T-test 0.942 6.786 0.942 0.942 1.178 1.178 9.66 9.66

EUF RS 0.175 0.841 0.175 0.175 0.216 0.196 0.876 0.877

p-value 0.176 1.22e-10 0.176 0.176 0.125 0.46 1.02e-10 1.02e-10

T-test 5.36 0.42 0.52 0.823 0.887 2.35 9.66 1.256

21

NUF RS 0.33 0.45 0.34 0.153 0.053 0.04 0.877 0.33

p-value 1.52 0.175 0.895 0.208 1.101 1.224 1.44e-7 0.176

T-test 0.83 1.59 3.59 0.577 0.34 1.65 1.914 1.44

FLA RS 0.179 0.31 0.31 0.108 0.11 0.298 0.34 0.41

p-value 1.001 3.72 3.72 0.284 2.11 0.054 0.032 2.33

 22
Table 8 The correlation Rs between code smells (MR, DNL, LR, MI, GSR, GSTR, DSA, HL) and aesthetic defects

Aesthetic defects
DN IAW ICM IDP ILW IM OM CM
Code smells

T-test 13.594 6.116 1.122 1.914 -1.807 7.416 0.504 0.544

MR RS 0.931 0.780 0.135 -0.048 -0.323 0.811 0.094 0.004

p-value 0.0001 3.03e-7 0.207 0.601 0.959 4.22e-7 0.308 0.542

T-test -0.226 0.524 0.192 1.62 8.933 0.52 6.416 -1.11

DNL RS -0.042 0.098 0.036 0.292 0.860 0.221 0.784 -0.206

p-value 0.058 0.301 0.424 0.058 5.4e-10 0.71 1.4e-7 0.863

T-test -0.078 0.259 0.697 5.358 0.32 -0.914 0.718 -0.919

LR RS -0.014 0.049 0.130 0.711 0.322 -0.170 0.134 -0.171

p-value 0.530 0.398 0.245 5.2e-6 0.521 0.815 0.239 0.817

T-test 1.788 1.628 1.477 1.058 0.388 1.654 0.358 0.226

MI RS 0.320 0.294 0.412 0.196 0.339 -0.298 0.211 0.042

p-value 0.042 0.057 0.658 0.149 0.201 0.945 0.2 0.411

T-test 9.660 2.33 -0.778 0.788 -0.518 -0.518 6.693 -1.115

GSR RS 0.877 0.23 -0.145 0.145 -0.097 -0.097 0.784 -0.206

p-value 1.02e-10 0.85 0.778 0.221 0.696 0.696 1.4e-7 0.863

T-test 2.214 1.788 1.628 1.058 1.982 0.577 2.470 0.226

Mabrouka Chouchane et al.

GSTR RS 0.386 0.320 0.294 0.196 0.350 0.108 0.423 0.042

p-value 0.017 0.042 0.057 0.149 0.028 0.284 0.009 0.411

T-test 1.544 1.55 1.058 0.942 0.85 1.288 0.823 -1.405

DSA RS 0.280 0.23 0.196 0.175 0.41 0.236 0.153 -0.256

p-value 0.066 0.014 0.149 0.176 0.52 0.104 0.208 0.914

T-test 13.594 1.122 0.239 1.914 1.914 -1.807 0.504 0.239

HL RS 0.931 0.207 0.094 0.340 0.340 -0.323 0.094 -0.045

p-value 0.0001 0.135 0.308 0.032 0.032 0.959 0.308 0.593

Title Suppressed Due to Excessive Length 23

The results presented in tables 7 and 8 show that the code smell Brain UI
Component (BUC) positively affects four aesthetic defects (OM, ICM, ILW
and CM) with correlation coefficient Rs values: 0.88, 0.87, 0.63 and 0.79 respec-
tively as shown with pink color. From the obtained results shown in section
5.1, we observe that among the 5120 GMUIs infected by CM aesthetic defect,
there are 4045 GMUIs related to 3710 classes also having BUC Android code
smell at the same time. For example, figure 8 presents an activity XML file
extracted from Lock pattern app with BUC Android code smell. This code
smell appears because the XML file includes elements of code related to busi-
ness logic, I/O processes, data transfer. Moreover, we mention that the MUI
related to this XML file suffers from CM aesthetic defect. The existence of the
BUC smell in the XML file may affect the aesthetic complexity of MUI.
In addition, the Android code smell God Style Resource (GSR) has an impact

Fig. 8 an illustrative example of BUC smell.

on two aesthetic defects DN and OM with correlation values 0.877 and 0.784
respectively. In fact, among 6254 GMUIs infected by OM defect, there are
5000 GMUIs related to 4282 classes having GS code smell at the same time.
The motivation example explained in section 3.2 demonstrates the relationship
between GSR Android code smell and OM aesthetic defect.

Moreover, the Android code smell Magic Resource (MR) has an impact on
three aesthetic defects: DN, IAW and IM. Its correlation values with MR code
smell are 0.931, 0.78 and 0.811 respectively. In this context, we mention that
among the 4100 GMUIs infected by DN aesthetic defect, there are 3817 GMUIs
related to 2945 classes having MR Android code smell at the same time. For
example, sometimes developer uses different colors to improve the navigability
of the MUI. Let’s take the aCal app which suffers from MR Android code
24 Mabrouka Chouchane et al.

smell. This smell appears due the definition of the color in ” Colourpicker-
widgets” file rather than its definition in a resource file. The GMUI shown in
figure 9 is without color despite the color definition in ” Colourpicker-widgets”
file which is not a resource file. This wrong definition of the color in the XML
file may lead to a difficult navigation through the MUI related to this file.
Besides, we observe that the diffuseness of Android code smell Excessive Use

Fig. 9 an illustrative example of MR smell.

of Fragments (EUF) has an impact on the appearance of IAW, OM and CM

aesthetic defects. Its correlation values with EUF code smell are 0.841, are
0.876 and 0.877 respectively. In fact, we note that among the 3320 GMUIs in-
fected by IAW aesthetic defect, there are 2788 GMUIs related to 1770 classes
having also EUF Android code smell. The figure 10 shows an example of
EUF Android code smell due to the use of only one fragment which leads to
IAW aesthetic defect in the ”A2DP volume” MUI widgets (unsuitable size and
position, incorrect orientation, etc.). However, the developer must use differ-
ent adaptive fragments to all the mobile devices. Moreover, the diffuseness of
Coupled UI Component(CUC) Android code smell has an impact on the ap-
pearance of three aesthetic defects: ILW, OM and CM with correlation values
Rs 0.746, 0.784 and 0.877 respectively. In fact, among 2450 GMUIs infected
by ILW aesthetic defect, there are 1770 GMUIs related to 952 classes having
also CUC code smell at the same time. The left part of figure 11shows the
”LogEntryAdapter” class of K-9 app which suffers from CUC Android code
smell because the developer tries to point into different activities using one
UI component. Using different activities may lead to ILW aesthetic defect due
to the wrong distribution of GMUI components in different rows and columns
as depicted in the right part of figure 11. The diffuseness of Suspicious Be-
havior (SB) Android code smell has a significant impact on the appearance of
three aesthetic defects: OM, DN and CM. Its correlation values with SB code
Title Suppressed Due to Excessive Length 25

Fig. 10 an illustrative example of EUF smell.

Fig. 11 an illustrative example of CUC smell.

smell are 0.87, 0.83, and 0.931 respectively. Among 5120 GMUIs infected by
CM aesthetic defect, there are 4766 GMUIs related to 4620 classes having SB
Android code smell. As shown in figure 12, this code smell appears because
an internal class is used called ”diceClick” in ”GameController” activity file
of the Yahtzee application to define event code of selected dices. In fact, the
developer defines all the buttons related to all the dice selection options in the
same activity file. This definition of event code makes the source code com-
plicated and less readable. As a consequence, this complexity of source code
26 Mabrouka Chouchane et al.

leads to overloaded aesthetic defect (OM) in the ”DiceSelection” MUI related

to the ”GameController” activity file.
However, the code smells like FA, FLA, GSTR, MI and DSA have no corre-

Fig. 12 an illustrative example of SB smell.

lation values with the studied aesthetic defects.

To this end, we can accept the hypothesis H1 for the 10 smells (BUC,
CUC, DNL, MR, HL, SB, GSR, EUF, NUF and LR) but we fail to accept it
for (DSA, GSTR, MI, FLA and FA) smells.
The results of research question 2 (RQ2) show that the diffuseness of code
smells has a significant impact on the occurrence of aesthetic defects in the
tested Android apps. This finding may help developer to identify a possible
reason for the appearance of code smells.

5.3 How accurately the aesthetic metrics predict the code smells for a given
Android apps?

In this subsection, we used a set of machine learning algorithms to detect

the code smells of a give Android app based on aesthetic metrics. The aim
is to build a model in a training phase using a machine learning algorithm.
Then, the trained model is tested based on 10 cross-validation technique. Table
9 summarizes the obtained experimental results in terms of recall, precision,
AUC, and the accuracy measures. To this end, six machine learning algorithms
(SVM, MLP, RF, ANN, Naive Bayes and Decision tree) are applied. Our
finding proves that the built model using SVM algorithm provides the highest
Title Suppressed Due to Excessive Length 27

accuracy rate (98%), and achieves the highest AUC with an average of 98%,
followed by the Naive Bayes model with an average of 94% of accuracy and
90% of AUC.

Table 9 The performance indicators of the studied machine learning algorithms.

Performance indicators

Algorithm names Precision Recalll Accuracy AUC

MLP 89% 88.6% 84% 87%

SVM 98.75% 98.8% 98% 98%

RF 87% 88% 84% 84%

ANN 81% 82% 84% 83%

Naive Bayes 95% 93% 94% 90%

Decision tree 75% 79.3% 75% 74%

The results of research question 3 (RQ3) describe the efficiency of the

proposed models built based on SVM and Naive Bayes machine learning al-
gorithms. These predictive models succeeded in detecting the Android code
smells based on the aesthetic metrics with an average of more than 80% of
accuracy. In addition, these models are able in detecting the Android code
smells by taking into consideration all the number of possible combinations
of aesthetic metrics that can be correlated with possible code smells. Due to
the huge number of possible combinations, the exhaustive approaches were
unpractical and time-consuming. To ensure the scalability of our models, we
compare the time cost of our algorithm with the exhaustive search. In this
context, Table 10 shows the runtime by second of Brute force against the used
machine learning algorithms.

Table 10 Runtime in micro-seconds of Brute Force and used machine learning algorithms.

Algorithm SVM RF ANN MLP Decision Naive Brute

Table Bayes Force

runtime 0,05 0,14 0,74 0,94 0,85 0,03 500

According to the results presented in table 10, we can conclude that SVM
and Naive Bayes algorithms are able to help developer to predict the smelly
classes in early phases of Android apps development with the less time cost.
28 Mabrouka Chouchane et al.

5.4 Implication for research

The main implication derived from this study is related to the maintainability
of the Android apps. In fact, the discovered correlation between code smells
and aesthetic defects, helps the developers to fix bugs. In fact, the diffuseness
of code smells in android apps gives the developer an idea about the required
source code change-proneness. Moreover, our results show that classes with
such violations are more prone to change than other classes that may need
additional maintenance efforts. Further, the priority is given for code smells
having an impact on several aesthetic defects for example BUC smell that has
an impact on four aesthetic defects (OM, CM, ILW and ICM).

5.5 Threats to validity

In this section, we report threats to validity to our study.

– Internal validity
The fact that when we observe a code smell in a class of presentation layer
of Android app, lead or not to the presence of aesthetic defect in the GMUI
controlled by this class. Thus, other factors may induce this relationship. In
fact, we understand that there are not an evident correlation between the
presence of code smells in the source code of an app and GMUI aesthetic
defects of the same app, which can be affected by different other factors.
Our findings may be related to the change history of these classes during
the different development phases of these applications, as well as by the
experience of the developers who contributed to this development phase.
– Construct validity
We introduced descriptive statistics, and we used adequate non-parametric
correlation tests to discuss our observations. However, the values taken by
p-value weren’t properly adjusted when multiple comparisons were per-
formed.
– External validity
We have used only 120 Android apps and this may not be enough to
generalize our findings, and that’s why we are planning on extending the
number of projects analyzed to challenge the scalability of our results.

6 Conclusion

This paper presented an empirical investigation conducted on 8480 GAUIS of

120 Android apps, aimed at studying the diffuseness of aesthetic defects and
the presentation layer code smells of these applications and understanding the
relationship between these two type of defects. To this end, we use two tools to
evaluate the quality of Android apps. The first tool is PLAIN, which aims to
detect the aesthetic defects of GAUIs by measuring a set of aesthetic metrics.
The second tool is Android UI Detector, which aims to identify 15 Android
Title Suppressed Due to Excessive Length 29

code smells that affected the presentation layer of Android apps. The findings
of this study prove that the results of the Spearmen correlation reveal the
significant impact of the diffuseness of Android code smells on the occurrence
of the aesthetic defects. In this work, we used only 120 Android apps and this
may not be enough to generalize our findings, and that’s why we are planning
on extending the number of analyzed projects to challenge the scalability of
our results. Moreover, we plan to develop a new plugin able to suggest appro-
priate refactoring operations to fix the GUI defects of Android apps.

Compliance with ethical standards

Conflict of interest The authors declare that they have no conflict of

interest.

Ethical approval All procedures performed in studies involving human

participants were in accordance with the ethical standards of the institutional
and/or national research committee and with the 1964 Helsinki declaration
and its later amendments or comparable ethical standards.

References

1. IEC. Iec. URL https://basecamp.iec.ch/download/iec-white-papers-internet-of-things-

wireless-sensor-networks/
2. fiksu. fiksu. URL https://fiksu.com/abouthttps:/fiksu.com/press-releases/fiksu-
indexes-mobile-marketing-costs-download-dip-in-may.
3. K.M. Flegal, D. Kruszon-Moran, M.D. Carroll, C.D. Fryar, C.L. Ogden, Jama 315(21),
2284 (2016)
4. R. Minelli, M. Lanza, in 2013 17th European Conference on Software Maintenance and
Reengineering (IEEE, 2013), pp. 144–153
5. L. Cruz, R. Abreu, D. Lo, Empirical Software Engineering 24(4), 2438 (2019)
6. C. Wohlin, P. Runeson, M. Höst, M.C. Ohlsson, B. Regnell, A. Wesslén, Experimentation
in software engineering (Springer Science & Business Media, 2012)
7. I.J.M. Ruiz, M. Nagappan, B. Adams, A.E. Hassan, in 2012 20th IEEE International
Conference on Program Comprehension (ICPC) (IEEE, 2012), pp. 113–122
8. G. Hecht, O. Benomar, R. Rouvoy, N. Moha, L. Duchien, in 2015 30th IEEE/ACM
International Conference on Automated Software Engineering (ASE) (IEEE, 2015),
pp. 236–247
9. J. Reimann, M. Brylski, U. Aßmann, in Proc. of the conference Modellierung 2014 in
the Workshop Modellbasierte und modellgetriebene Softwaremodernisierung–MMSM,
vol. 2014 (2014), vol. 2014
10. F. Palomba, D. Di Nucci, A. Panichella, A. Zaidman, A. De Lucia, in 2017 IEEE 24th
International Conference on Software Analysis, Evolution and Reengineering (SANER)
(IEEE, 2017), pp. 487–491
11. C. Stephanidis, A. Paramythis, M. Sfyrakis, in 5th ERCIM Workshop on” User Inter-
faces for All”(pp. 22.1-22.6) (1999)
12. D. Park, J.H. Lee, S. Kim, International Journal of Human-Computer Studies 69(12),
839 (2011)
13. L. Ruzic, S.T. Lee, Y.E. Liu, J.A. Sanford, in International Conference on Universal
Access in Human-Computer Interaction (Springer, 2016), pp. 98–108
14. G.D. Magoulas, S.Y. Chen, K.A. Papanikolaou, in Proceedings of the Second Workshop
on Empirical Evaluation of Adaptive Systems, held at the 9th International Conference
on User Modeling UM2003, Pittsburgh (2003), pp. 5–14
30 Mabrouka Chouchane et al.

15. J. Cámara, R. de Lemos, N. Laranjeiro, R. Ventura, M. Vieira, Journal of the Brazilian

Computer Society 20(1), 1 (2014)
16. A. Yamashita, L. Moonen, in 2013 20th Working Conference on Reverse Engineering
(WCRE) (IEEE, 2013), pp. 242–251
17. F. Palomba, G. Bavota, M. Di Penta, R. Oliveto, D. Poshyvanyk, A. De Lucia, IEEE
Transactions on Software Engineering 41(5), 462 (2014)
18. R. Arcoverde, A. Garcia, E. Figueiredo, in Proceedings of the 4th Workshop on Refac-
toring Tools (2011), pp. 33–36
19. R. Marinescu, in 20th IEEE International Conference on Software Maintenance, 2004.
Proceedings. (IEEE, 2004), pp. 350–359
20. M. Tufano, F. Palomba, G. Bavota, R. Oliveto, M. Di Penta, A. De Lucia, D. Poshy-
vanyk, IEEE Transactions on Software Engineering 43(11), 1063 (2017)
21. F. Khomh, M. Di Penta, Y.G. Guéhéneuc, G. Antoniol, Empirical Software Engineering
17(3), 243 (2012)
22. M. D’Ambros, A. Bacchelli, M. Lanza, in 2010 10th International Conference on Quality
Software (IEEE, 2010), pp. 23–31
23. M. Abbes, F. Khomh, Y.G. Gueheneuc, G. Antoniol, in 2011 15th European Conference
on Software Maintenance and Reengineering (IEEE, 2011), pp. 181–190
24. A. Yamashita, L. Moonen, in 2013 35th International Conference on Software Engi-
neering (ICSE) (IEEE, 2013), pp. 682–691
25. D.I. Sjøberg, A. Yamashita, B.C. Anda, A. Mockus, T. Dybå, IEEE Transactions on
Software Engineering 39(8), 1144 (2012)
26. L. Cruz, R. Abreu, in 2017 IEEE/ACM 4th International Conference on Mobile Soft-
ware Engineering and Systems (MOBILESoft) (IEEE, 2017), pp. 46–57
27. M. Gatrell, S. Counsell, Science of Computer Programming 102, 44 (2015)
28. M. Soui, M. Chouchane, I. Gasmi, M.W. Mkaouer, in VISIGRAPP (1: GRAPP) (2017),
pp. 127–136
29. M. Kessentini, A. Ouni, in Proceedings of the 4th International Conference on Mobile
Software Engineering and Systems (IEEE Press, 2017), pp. 122–132
30. S.G. Carvalho, M. Aniche, J. Verı́ssimo, R.S. Durelli, M.A. Gerosa, Empirical Software
Engineering 24(6), 3546 (2019)
31. F. Mercaldo, A. Di Sorbo, C.A. Visaggio, A. Cimitile, F. Martinelli, Journal of Software:
Evolution and Process 30(11), e1978 (2018)
32. J. Gao, L. Li, T.F. Bissyandé, J. Klein, in 2019 24th International Conference on
Engineering of Complex Computer Systems (ICECCS) (IEEE, 2019), pp. 200–209
33. S.M. Olbrich, D.S. Cruzes, D.I. Sjoøberg, IEEE International Conference on Software
Maintenance, ICSM (2010). DOI 10.1109/ICSM.2010.5609564
34. W. Li, R. Shatnawi, Journal of Systems and Software 80(7), 1120 (2007). DOI
10.1016/j.jss.2006.10.018
35. F. Khomh, M. Di Penta, Y. Guéhéneuc, École Polytechnique de Montréal, Tech. Rep.
EPM-RT-2009-02 (2009)
36. M.W. Mkaouer, M. Kessentini, M.Ó. Cinnéide, S. Hayashi, K. Deb, Empirical Software
Engineering 22(2), 894 (2017)
37. E.A. AlOmar, M.W. Mkaouer, A. Ouni, M. Kessentini, in 2019 ACM/IEEE Inter-
national Symposium on Empirical Software Engineering and Measurement (ESEM)
(IEEE, 2019)
38. M. Tufano, F. Palomba, G. Bavota, R. Olivetox, M. Di Penta, A. De Lucia, D. Poshy-
vanyk, Proceedings - International Conference on Software Engineering 1, 403 (2015).
DOI 10.1109/ICSE.2015.59
39. G. Bavota, A. Qusef, R. Oliveto, A. De Lucia, D. Binkley, in Software Maintenance
(ICSM), 2012 28th IEEE International Conference on (IEEE, 2012), pp. 56–65
40. G. Bavota, A. De Lucia, M. Di Penta, R. Oliveto, F. Palomba, Journal of Systems and
Software 107, 1 (2015)
41. G. Ines, S. Makram, C. Mabrouka, A. Mourad, Procedia Computer Science 112, 235
(2017)
42. M. Fowler, in 11th European Conference. Jyväskylä, Finland (1997)
43. N.E. Fenton, S.L. Pfleeger. Software metrics: a rigorous and practical approach. 2nd
(1997)
Title Suppressed Due to Excessive Length 31

44. W.H. Brown, R.C. Malveau, H.W. McCormick, T.J. Mowbray, AntiPatterns: refactoring
software, architectures, and projects in crisis (John Wiley & Sons, Inc., 1998)
45. C. Mabrouka. Expriment. URL https://github.com/mabroukachouchane/master-
Jmetal
46. M. Soui, M. Chouchane, M.W. Mkaouer, M. Kessentini, K. Ghedira, Soft Computing
pp. 1–30 (2019)
47. Student, Biometrika pp. 263–282 (1921)
48. J. Cohen, Current directions in psychological science 1(3), 98 (1992)
49. I. Gondra, Journal of Systems and Software 81(2), 186 (2008)
50. R. Malhotra, A. Jain, Journal of Information Processing Systems 8(2), 241 (2012)
51. R. Jindal, R. Malhotra, A. Jain, in Proceedings of 3rd International Conference on
Reliability, Infocom Technologies and Optimization (IEEE, 2014), pp. 1–6
52. Y. Freund, R. Schapire, N. Abe, Journal-Japanese Society For Artificial Intelligence
14(771-780), 1612 (1999)
53. L. Breiman, Machine learning 45(1), 5 (2001)
54. B. Yegnanarayana, Artificial neural networks (PHI Learning Pvt. Ltd., 2009)
55. J.R. Quinlan, C4. 5: programs for machine learning (Elsevier, 2014)
56. S. Ting, W. Ip, A.H. Tsang, et al., International Journal of Software Engineering and
Its Applications 5(3), 37 (2011)
57. L. Yang, A. Shami, Neurocomputing 415, 295 (2020)