Keywords

1 Introduction

Migration means transferring an application to a new target environment holding the same features as the original application [5]. Migration is relevant to consolidate past knowledge and to preserve past investments [7]. In addition, the use of the migrated application should not negatively affect how the end-user perceives it as compared with its original version. Therefore, the migration is successful from the end-user perspective if she does not note any difference.

The development of apps based on cross-platform solutions (e.g., Titanium, PhoneGap, and Ionic) are free from the operating system. That is, the developer writes the code of an app once and deploys it to the different (supported) hardware/software platforms (e.g., iOS and Android). Among the cross-platform solutions, Ionic is receiving great interest because it provides tools and services to easily build Mobile UIs (User Interfaces) with a native look and feel. Ionic also provides full access to native functionality of the device (behaving in this case as a hybrid platform). On the other hand, native development means developing the mobile app specifically for each hardware/software platform. For example, Android apps have to follow a Model View Controller pattern closely tied to the Android operating system architecture.

The results from an industrial survey [8] indicated that cross-platform development is largely adopted because it is less risky than the native development. Respondents in this survey also thought that a cross-platform (or hybrid) app should be preferred when no much money can be invested in the native development. The use of cross-platform frameworks is also a valuable means to the rapid prototyping of apps to be run in different hardware/software platforms. Once the value of these apps has been assessed with real users (e.g., through beta-testing), these apps could be re-implemented or migrated towards native platforms (e.g., Android or iOS). As an example, a Stack Overflow user asks some suggestions on how to substitute an Ionic app with a native Android one in the Google Play store, because he is “planning to start a startup and currently he is not in a position to afford individual development for various platforms.”Footnote 1

In this paper, we present an approach to migrate Apps developed with Ionic towards Android platform. To assess the validity of this approach and its underlying process, we applied both of them on a real open-source app, i.e., Movies-app.Footnote 2 Finally, to assess if the migration from Ionic to Android is valuable from the end-user perspective, we conducted a qualitative investigation with 18 users with different experience and background. The main goal of this investigation was to study affective reactionsFootnote 3 and user experienceFootnote 4 of the involved participants on both the versions of Movies-app. In particular, we first assessed the difference (if any) in the affective reactions of users when using Ionic and Android versions. Affective reactions were measured using a lightweight yet powerful tool, Self-Assessment Manikin (SAM) [4]. Later, we asked the participants in our study to fill a questionnaire to assess user experience [17]. The general goal of the study was to investigate whether affective reactions and user experience are affected by the used version of the app. This is to say that in case the end-user does not perceive any difference in terms of affective reactions and user experience between the original version of the app and its migrated version the migration is successful and then migration matters. It is even better if affective reactions and user experience are more positive in the case of the migrated version of the app.

This paper provides the following main contributions:

  • An approach to migrate Ionic apps towards the Android platform and its validation on open-source app developed with Ionic;

  • A user study to assess if the migration from Ionic towards the Android platform matters.

In Sect. 2, we present related work and background information. We present the migration approach and the results of its application on a real case in Sect. 3. The design of the study to assess affective reactions and user experience is shown in Sect. 4. In this section, we discuss the obtained results. We conclude the paper in Sect. 5.

2 Background and Related Work

In the following of this section, we highlight some differences (at a high granularity level) between the architectures of Ionic and Android apps (depicted in Figs. 1 and 2, respectively). We conclude presenting the migration of the apps.

Fig. 1.
figure 1

Architecture of an Ionic app.

Full size image

2.1 Ionic App Architecture

An Ionic app is based on web technologies, such as HTML5 and CSS, and developed on the top of Angular, a component-based platform for building mobile and desktop web applications [3]. An Ionic app is structured in pages (screens of the mobile app). Each page of the application is represented by an Angular component. The content of a component is described in an HTML file named template, the style in CSS and the behavior in Typescript, the development language adopted by Angular, that is derived by Javascript and enhanced with classes and a stronger type definition. The template of a component together with HTML tags contains instructions for modifying the app HTML, the app status and the DOM data, and tags related to other components or data binding. The modular architecture of an Angular application is based on NgModules: each application contains a root module called AppModule, and is constituted by components and service providers. It may export functionality which may be used by other NgModules and imports functionality offered by other NgModules, as shown in the right-hand part of Fig. 1. In Angular, service providers are used to share logic or data between components and for calls to server-side web services. Ionic accesses to the native device features through the Cordova plugins, written in the native language on the native platform.

2.2 Android App Architecture

Android apps architecture follows a Model-View-Controller pattern closely tied to the Android operating system architecture. It is good practice in Android app development to put in UI-based classes (Activity or Fragment) only the logic for handling the User Interface, by maintaining the separation of concerns [1]. As shown in Fig. 2, the architecture is composed of the following elements [9]:

Fig. 2.
figure 2

Architecture of an Android app.

Full size image

  • The View layer is responsible for interacting with the user and is performed by Activity and Fragment which only configure the view. It shows LiveData taken from the ViewModel.

  • The ViewModel observes the Lifecycle state of Activities and Fragments (the view), by maintaining consistency during configuration changes and other Android life-cycle events. It gets LiveData from the Repository and makes them available to be observed by the view.

  • The Repository is a class responsible for getting data from different sources, such as databases and web services. It handles all this data, in terms of observable LiveData, and let them be available to the ViewModel, which can monitor changes through the design pattern observer.

  • Room is a persistence library on the top of SQLite providing more robust database access and returning queries with observable LiveData.

2.3 Migration

One of the most followed migration approaches is the one proposed by Brodie and Stonebraker, named “chicken little” [5]. It consists of an iterative migration of separable functionality. We also follow this approach, by identifying which aspects of the migration process may be automatized.

Klima and Selingerer [15] consider that many Android apps exist and that the use of cross-platform development tools is suitable for app development from scratch. To reuse existing Android apps, they propose an automated approach to convert them into Web applications by using the Google Web Toolkit (GWT), a Java to Javascript converter. For the functionality not supported by HTML5, Android wrappers are created. No evaluation is provided and only the description of the converter is discussed. Also, Stehle and Riebisch [20] approach the problem of porting a system from a single to multi-platform development platform by proposing a transformation method. Both the apps on the two different architectures evolve, by establishing traceability across the two versions. They present three case studies of porting applications with different operating systems to evaluate the extent of code conversion and structural equivalence achieved by the application. Unlike previous papers, we perform a user study aiming at evaluating the presence of possible differences in the affective reactions and user experience when using the original and the migrated app.

3 The Migration Approach

The proposed approach is conceived to migrate an app from the Ionic-Angular-Cordova to the Android native technology. The migration follows an incremental process, conducted by performing small steps, as shown in Fig. 3 by the UML activity diagram with object-flow depicting the process. To assess and describe the migration approach, we used an open-source application developed by using Ionic4-Angular-Cordova technologies. Among the ones available on GitHub we selected Movies-app, an application aiming at providing information on the most popular movies. We opted for this app because its source files were available for the download and because it is not very complex (although not obvious) and its problem domain can be considered familiar.

Fig. 3.
figure 3

The migration process.

Full size image

Some screens of Movies-app are shown in Fig. 4. The app starts from the screen in Fig. 4(a). It is possible to select three types of filters on the movies (i.e. Populares, Top and Proximamente) by tapping on the tab buttons in the lower part of the screen. Once selected a movie, it is possible to examine its detailed description (Fig. 4(b)) and get details on one of its actors. In the following we examine in detail the various migration steps.

Fig. 4.
figure 4

Two screens of the Ionic application Movies-app (Fig. 4(a) and 4(b)) and a migrated interface in Android (Fig. 4(c)).

Full size image

Reverse Engineering. In this phase, we analyze the functionality of the application by executing it and by examining the project structure. We identify the Ionic pages involved in the accomplishment of a given functionality and group together in modules that functionality logically related. Each Ionic page is composed of content formatting (html), style (SCSS) and behavior (TypeScript). It also imports other components, directives, and providers (or services) which are listed in the pagName.module.ts file available in the pageName folder. The output of this phase is the Source Code Inventory document, which lists the app modules and, for each of them, the related pages and services.

Migration Planning. Starting from the Source Code Inventory document, we individuate a migration order of the various functionality and services. The following three steps are performed for each page.

Pre-processing. This phase provides details on the types and attributes of each component included in the page. Information on the Ionic component is collected, such as tags (e. g., \(ion-list\) and \(ion-alert\)), its position on the screen, and the number of sub-components composing it. As a result of this phase, a list of components and the related sub-components of the considered page is provided (Component Description in Fig. 3).

GUI-Rengineering. The Ionic page whose layout and style are described by its .html and .scss files, respectively, has to be mapped into an Android activity, whose GUI is strictly dependent on the platform. Android layout is described in XML, the style by Android styles and themes [2]. A page can be composed of Ionic predefined sub-components (e.g., a list - ionlist - may represent its elements by a ioncard), and contain information, such as \( <ioncardheader>\) and \(<ioncardcontent>\). In Android, ionlist has to be mapped into a RecyclerView widget of the Activity XML file. This shows the generic element of the list by viewholderobjects, which are managed by an adapter that creates view holders when neededFootnote 5. The mapping has to be performed for each Ionic GUI component. HTML and SCSS files may be automatically mapped in XML by a translator. We test the GUI appearance on various devices or on the emulator (UI testing) each time a new widget is added.

Single page and component Code Reengineering. The application logic of an Ionic app is written in TypeScript. Many TypeScript constructs are very similar to the corresponding in Java. The main translation rules are the following [18]:

  • Variable declaration. In TypeScript, developers only need to manage numbers, booleans, and strings. These variables have to be associated in Java to more specific types, such as double, float, char, boolean and long. Concerning arrays, their declaration in TypeScript differs from Java only in the order in which the array and its datatype have to be written.

  • Conditional Statements. No difference.

  • Loops. Typescript loops have the same syntax as Java ones. Except for the let Typescript syntax.

  • Classes. Both Typescript and Java support classes. The syntax has some little differences.

  • Data binding. One of the advantages of Angular is that it provides an easy way to bind data to the views. As an example, in Ionic we declare the variable \(name\_person\) in the Typescript page and use it freely in its HTML with the following syntax: \(\{\{name\_person\}\}\). This binding approach is called interpolation in Angular. In Android, we bind the XML view with Java using its id:    \(name\_person = findViewById(R.id.name\_person\_detail);\)

  • Methods/functions. Java methods and TypeScript functions have the same meaning, but the syntax is different. As an example, in Typescrypt the word function should be inserted in the name of the method.

  • Ionic native plugin calls replacement by Android API. The Android Manifest of the migrated version has to include the appropriate permissions to allow use of the native functionality. The plugin call in the TypeScript class has to be replaced by a Java call to the same code in Android.

There exist several approaches to automatically convert Java in TypeScript, but at the moment no one is available to do the vice-versa. A quick approach may consist in using a transpiler to translate TypeScript in Javascript and then transpile it to Java. The resulting code may be difficult to read. Otherwise, a code converter from TypeScript to Java has to be implemented. Since TypeScript is continuously evolving, this solution requires continuous updating of the translator. We conduct Unit testing by using JUnit for validating the behavior of each class of the app. Test cases available in Ionic may be reused as a guide.

Data-Reengineering. The Data Reengineering step is made independently from page migration. In both systems, the app may store key/value pairs in the local storage, on the device file system and SQLite is adopted as local DBMS.

Provider-Reengineering. Ionic providers (i.e., services) are mapped into Java classes in Android.

Incremental Integration and Testing. Each page is progressively integrated with the pages and providers of the same module. Test cases can be derived from the Ionic app and used to exercise the target system in order to identify eventual behavior differences. Once the Ionic application has been migrated, it has to be customized for the various type of Android devices, with different screen sizes and resolutions.

Table 1. Descriptive statistics for the Ionic Movies-app and its Android version.
Full size table

3.1 Resulting Metrics

Some descriptive metrics on the source code of the original Ionic app and the migrated one are reported in Table 1. LOC data revealed that Ionic code is lighter than Android one, this is due to the fact that many tasks are performed by Angular libraries.

4 User Study

To conduct our user study, we followed the guideline by Wohlin et al. [24] and Juristo and Moreno [22]. We report the planning of the user study following the template suggested by Jedlitschka et al. [11].

4.1 Goals

We investigated the following main Research Question (RQ):

  • Does the migration of cross-platform Apps developed by means of Ionic towards the Android platform matter?

To answer this RQ, we had to compare from the end-user point of view the original version of an app (i.e., Movies-app) with that migrated to Android. To this end, we considered two main perspectives: affective reactions of users (i.e., pleasure, arousal, dominance, and liking) and user experience. In particular, we speculate that the migration from Ionic to Android matters if we observe a difference in favor of the Android version of a given app (Movies-app) with respect to the affective reactions and the user experience. Therefore, we detailed our main RQ as follows:

  • RQ1. Is there an effect (either positive or negative) on pleasure, arousal, dominance, and liking when using the (Android) migrated version of an app developed by means of Ionic?

  • RQ2. Is there an effect (positive or negative) on the user experience when using the (Android) migrated version of an app developed by means of Ionic?

If the effect is positive for both the RQs, we can conclude that the migration of a cross-platform app towards Android matters.

4.2 Experimental Units

Initially, 19 people accepted to take part in the experimental study; however, 18 actually participated. The participants in the study had a different background: 12 people had a Bachelor Degree (10 in Computer Science and two in Mathematics); four people had a Master’s Degree (three in Computer Engineering and one in Mathematics); one had a Ph.D. in Computer Science and one had a Scientific High School Diploma. The average age of participants is 27. Except for one of them that owned a smartphone with iOS, the others owned an Android smartphone. On average, participants install two apps a month. Most participants complain of sudden crashes and lags of apps, and irreversible blocks of the smartphone, as main annoyances during the use. This information was collected through a pre-questionnaire (i.e., a Google form) we asked the participants to fill in a few days before the actual study.

4.3 Experimental Study Material and Tasks

The experimental objects consisted of the two versions of Movies-app: the original one and the migrated one. Movies-app is a real-world App small enough to allow a good control over the participants while completing the study.

To gather affective reactions, we relied on SAM [4]. It is a questionnaire that consists of a nine-point rating scale for each of the following dimensions: pleasure, arousal, and dominance. The pleasure scale ranges from affective states associated with unhappiness/sadness to happiness/joyfulness. The arousal scale varies from calm/bored to stimulated/excited. Finally, the dominance scale ranges from submissive to dominant, i.e., from “without control” to “with control”. As Koelstra et al. [16] did, we included the liking dimension on top of the SAM dimensions ones. Also, liking consists of a nine-point rating scale and varies from dislike to like.

As for user experience, we relied on the 26 statements by Laugwitz et al. [17]. These authors defined these statements to evaluate the quality of interactive products (e.g., software). Each statement is made of two adjectives that describe some opposite qualities of products. According to their objectives, these statements are grouped into the following six categories: Attractiveness, Perspicuity, Efficiency, Dependability, Stimulation, and Novelty. The scale for each adjective ranges from 1 to 7. The original set of statements from the User Experience QuestionnaireFootnote 6 was in German, and then it was translated in 20 other languages, Italian included. In our experimental study, we administered the questions in the Italian version provided by the authors.

As for the experimental tasks, we asked the participants to freely use both the versions of the app according to the design described in Sect. 4.5. Right after the use of each version of the app, we asked the participants to fill in the SAM questionnaire and to respond to the 26 UEQ statements.

4.4 Hypotheses and Variables

We considered two independent variables: Technology and Order. The first indicates the technology used to implement the app. Therefore, Technology is a categorical variable with two values: Android and Ionic. The Order variable indicates the order in which a participant used the version of the app (also known as sequence in the literature). Similarly to Technology, Order is categorical and can assume the following two values: First and Second. For example, First indicates that the Android version has been used first and then the Ionic one. We analyzed Order to study learning effect on affective reactions and user experience.

To measure affective reactions, we used four dependent variables (one for each dimension of SAM). To measure user experience, we used six dependent variables, one for each of the six categories of UEQ (e.g., Attractiveness). To obtain a single value for each category we summed the scores of each statement in that category. For example, the Attractiveness category, which is composed of six statements, can assume values in between 6 (if all the statements are scored 1) and 42 (if all the statements are scored 7). This practice to aggregate scores from single statements is widespread (e.g.,  [23]). To answer the defined RQs, we formulated and tested the following parameterized null hypothesis.

  • H0 \(_{X}\) : There is no statistically significant difference between the Android and Ionic Apps with respect to X.

Where X is one of the considered dependent variables. Because we could not postulate an effect of Technology in a specific direction, either positive or negative, our alternative hypotheses are two-tailed.

4.5 Experimental Study Design

The design of our experimental study (see Table 2) was a factorial crossover [21]. In this design, the number of periods (i.e., Order) and treatments (i.e., Technology) is the same, and the treatment applies to participants once and only once [21]. The participants were divided into two groups, G\(_1\) and G\(_2\), both made of nine members. The assignment to the groups was randomly performed. Each participant used both the versions of the app, but participants in G\(_1\) firstly used the Android version and then the Ionic one, while vice-versa was applied to G\(_2\). The use of this design mitigated the effect of the app on the results.

Table 2. Experiment design
Full size table

4.6 Procedure

The study procedure included the following sequential steps.

  1. 1.

    We invited Ph.D. and Master’s students in Computer Science and Mathematics at the University of Basilicata and students enrolled in the course of Advanced Software Engineering of the Master Degree in Computer Engineering from the same University. We also invited people working in the Software Engineering Laboratory at the University of Basilicata. They had to fill in a pre-questionnaire to gather demographic information. This design choice allowed us to have participants with heterogeneous backgrounds.

  2. 2.

    We randomly split the participants into two groups: G\(_1\) and G\(_2\).

  3. 3.

    The study session took place under controlled conditions in a research laboratory. We avoided interactions among participants by exploiting one-to-one sessions, namely each participant accomplished the study tasks under the supervision of one of the authors (the first one). This author did not interact with the participants to accomplish the tasks and applied the same procedure/steps for each participant.

  4. 4.

    Each participant performed the first task and then filled in the SAM questionnaire (first) and UEQ (later).

  5. 5.

    Each participant performed the second task and then filled in the SAM questionnaire (first) and UEQ (later).

  6. 6.

    Finally, we collected for each participant some free comments about the overall experience, through voice recordings.

All the participants used the same smartphoneFootnote 7 in both the tasks. No other apps were open in the background at the beginning of each experimental session.

4.7 Analysis Procedure

To test null hypothesis, we used the ANOVA Type Statistic (ATS) [6]. It is used (e.g., in medicine) to analyze data from rating scales in factorial designs [12]. We built ATS models as: \( X \sim Technology + Order + Technology:Order\). Where the dependent variable is X and Technology and Order are the manipulated ones. Technology:Order indicates the interaction between Technology and Order. This model allows determining if Technology, Order, and Technology:Order had statistically significant effects on the given dependent variable X. To verify if an effect is statistically significant, we fixed \(\alpha \) to 0.05. That is, we admit 5% chance of a Type-I-error occurring [24]. If a p-value is less than 0.05, we deemed the effect is statistically significant.

4.8 Results

RQ1. Android Vs Ionic with Respect to Affective Reactions.

In Table 3, we summarize the results of the statistical inference with respect to RQ1. We can observe a statistically significant difference with respect to Liking with a medium effect size (0.383). We quantified effect size by means of the Cliff’s delta.Footnote 8

The median values for G\(_{1}\) are 8 for Android and 7 for Ionic, while the median values for G\(_{2}\) are 5 for Ionic and 6 for Android. Therefore, we can assert that the participants liked more the migrated version of Movies-app than its original version for Ionic. As for Liking, we also observed a significant interaction between the two independent variables. This interaction is significant also for Pleasure. This means that there is a combined positive effect of Technology and Order.

Table 3. Summary of the results for affective reactions.
Full size table
Table 4. Summary of the results for user experience.
Full size table

RQ2. Android Vs Ionic with Respect to User Experience. In Table 4, we summarize the results of the statistical inference with respect to RQ2. We can observe a statistical difference with respect to Efficiency with a large effect size (0.67). The median values for G\(_{1}\) are 23 for Android and 17 for Ionic, while the median values for G\(_{2}\) are 18 for Ionic and 23 for Android. Therefore, we can assert that the participant found the Android version of the app more efficient than its original version for Ionic. We also observed a significant interaction between the two independent variables for Novelty.

4.9 Further Analysis

To analyze data from the interviews, we used TAT (Thematic Analysis Template) [14]. For space constraint, we do not provide details on how we applied TAT. We report identified themes and excerpts of the interviews carried out at the end of the experimental study with the participants.

Reactivity. The apps implemented with Android is more reactive than the other and this makes it more enjoyable.

We can justify this pattern in the data because in Ionic the use of the browser may cause prolonged app loading and a deteriorated responsiveness and there may be performance issues when several callbacks are sent to the native code.

Fluidity. The scroll is not fluid when sliding the results of a query. This happens for the app implemented in Ionic.

This theme can be considered related to the previous one. The highlighted issue should depend on the resources to execute the Ionic version of the app.

User Interface, Contents, and Functionality. The two versions of the app look quite the same, have the same functionality, and show the same contents.

This result might be in relation to the absence of a statistically significant difference in three out of four dependent variables for affective reactions, and in five out of six dependent variables for user experience.

4.10 Discussion

On the basis of the obtained results, it seems that the main research question can be positively answered: the migration of cross-platform Apps developed by means of Ionic towards the Android platform matters. According to our study, end-users’ opinions are in favor of the Android version of the app in terms of Liking and Efficiency, with respect to Technology. This is evidenced by a medium effect size for Liking and a large effect size for Efficiency. Variables related to how the two apps appear (e.g. Attractiveness includes couples of adjectives such as: Annoying/Enjoyable, Good/Bad, Unlikable/Pleasing, Unpleasant/Pleasant, Attractive/Unattractive, Friendly/Unfriendly) seem to measure no preferences for any of the versions. We conjecture that Liking might be influenced by the performance of the apps perceived by end-users (measured by Efficiency) and this is supported by free comments collected. This might also imply that the migration approach was carried out successfully, because such an approach did not negatively affect the perceived performance, indeed, the Android version has been reputed more efficient over the same experimental conditions. The Order seems not to affect the users’ opinions in any of the two cases (SAM and UEQ), while Technology and Order seem to interact each other in cases of Pleasure (SAM), Liking (SAM) and Novelty (UEQ), in favor of the Android version.

4.11 Threats to Validity

We discuss the threats that could have affected the validity of the results in the user study. We ranked these threats from the most to the least sensible for the goal of our study (i.e., Internal Validity).

Internal Validity. A possible threat is voluntary participation in the study (selection threat). To deal with threat of diffusion or treatments imitations, the first author of this paper monitored participants and asked back material to prevent them from exchanging information.

Construct Validity. Each of the investigated constructs was quantified by means of one assessment at the end of the task, which can affect the results (i.e., participants tend to assess the affective state closer to when we provided them the SAM). Although the participants were not informed about our RQs, they might guess them and change their behavior accordingly (threat of hypotheses guessing). To mitigate evaluation apprehension threat, we reassured participants that their data were treated anonymously and in aggregate form. It is worth mentioning that we asked the participants to sign a consent form to use their data. We also acknowledge the presence of a restricted generalizability across constructs. That is while having an impact on the affective states, the approach can affect other relevant constructs which we did not observe (cognitive load).

Conclusion Validity. Threat of random heterogeneity of participants could be present since we involved participants with a different background. Reliability of measures is another threat to conclusion validity. To deal with it, we used well known and widely used measures.

External Validity. The experimental objects might affect the external validity of the results (i.e., threat of the interaction of setting and treatment). They could be not representative of real-world tasks. The selected mobile device on which the user study is performed was a mid-range device, because not all the real-world users own the most performing devices.

5 Conclusion and Final Remarks

We presented an approach to migrate Ionic apps towards Android. The validity of this approach has been assessed on an open-source app (i.e., Movies-app). We also studied if the application of our approach matters from the end-user perspective. To this end, we conducted an empirical investigation to study both user experience and affective reactions of possible users. The main goal was to identify differences when using both the versions of Movies-app: the Ionic and the Android ones. The results suggest that a better user experience was achieved when dealing with the Movies-app version implemented in Android. Similar results were achieved with respect to the affective reactions of users. Summarizing, it seems that the migration from Ionic towards Android matters.