Code Reuse Between Java and Android Applications
Total Page:16
File Type:pdf, Size:1020Kb
Code Reuse between Java and Android Applications Yoonsik Cheon, Carlos V. Chavez and Ubaldo Castro Department of Computer Science, The University of Texas at El Paso, El Paso, Texas, U.S.A. Keywords: Code Reuse, Multiplatform Application, Platform Difference, Android, Java. Abstract: Java and Android applications can be written in the same programming language. Thus, it is natural to ask how much code can be shared between them. In this paper we perform a case study to measure quantita- tively the amount of code that can be shared and reused for a multiplatform application running on the Java platform and the Android platform. We first configure a multiplatform development environment consisting of platform-specific tools. We then propose a general architecture for a multiplatform application under a guiding design principle of having clearly defined interfaces and employing loose coupling to accommodate platform differences and variations. Specifically, we separate our application into two parts, a platform-independent part (PIP) and a platform-dependent part (PDP), and share the PIP between platform-specific versions. Our finding is that 37%–40% of code can be shared and reused between the Java and the Android versions of our application. Interestingly, the Android version requires 8% more code than Java due to platform-specific con- straints and concerns. We also learned that the quality of an application can be improved dramatically through multiplatform development. 1 INTRODUCTION ing an experiment to measure quantitatively the de- gree of code reuse possible between Java and An- droid versions of an application. Our experiment is Java is one of the most popular programming lan- a case study developing natively a Java application guages in use today for developing a wide spectrum and its Android version running on mobile devices of applications running on a range of platforms from like smartphones and tablets. The application is small mobile and desktop to server. The Android operat- in Java but is a typical Android application of the ing system is the dominating mobile platform of to- average size (Minelli and Lanza, 2013), requiring a day, and Android applications can be written in Java graphical user interface (GUI), data persistence, net- albeit some differences between the Java application working, and multithreading. We develop the ap- programming interface (API) and the Android API. plication incrementally and iteratively with continu- Source code reuse is considered as a fundamental part ous integration and testing by switching instantly be- of software development (Abdalkareem et al., 2017). tween platform-specific integrated development envi- Thus, it is naturalto ask howmuch codecan be shared ronments (IDEs). For this, we configure a custom and reused between Java and Android applications. In multiplatform application development environment this paper we study and answer this question. by sort of gluing individual platform-specific tools A multiplatform application is an application that and IDEs. Our development environment propagates is developed for and runs on multiple platforms. We immediately changes made on the shared code using use the term platform loosely to mean operating sys- one IDE to other IDEs and platforms. Our design tems, runtimes including virtual machines, and soft- approach for code reuse is to decompose an applica- ware development kits (SDKs). We include SDK in tion into two different parts: a platform-independent the platform, as our research is focused on code reuse part (PIP)anda platform-dependent part (PDP). The and we are also interested in studying the impact and PIP is the part of an application that does not depend complications caused by API differences of SDKs. on platform specifics and thus can be reused on dif- The two specific platforms that we consider in this ferent platforms. The guiding design principle is to paper are Java SDK for desktop applications and An- have clearly defined interfaces and employ loose cou- droid Java SDK. pling between the two parts to accommodate platform We answer our research question by perform- 246 Cheon, Y., Chavez, C. and Castro, U. Code Reuse between Java and Android Applications. DOI: 10.5220/0007843702460253 In Proceedings of the 14th International Conference on Software Technologies (ICSOFT 2019), pages 246-253 ISBN: 978-989-758-379-7 Copyright c 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved Code Reuse between Java and Android Applications These libraries and frameworks may introduce ad- ditional complications to the development of multi- platform applications. To study their implications in the code reuse, we use several different libraries and frameworks in our development. The APIs of Java and Android Java are very similar for common li- braries such as collections, file I/O, and networking. However, graphical user interface (GUI) frameworks of Java and Android are completely different, as An- droid offers its own framework for GUI program- ming. Interestingly, there are also differences in the ways third-party libraries and framework are provided or supported by platforms. • Plain Old Java Objects (POJOs): A library or Figure 1: Screenshots of Price Watcher (Java and Android). framework is written in the ordinary Java, not bound by any special restriction other than those differences and variations. To determine code reuse, of the Java language specification. It is often bun- we measure the size of our code with a simple metric dled in the SDK. Android SDK, for example, in- counting the number of lines of code (LOC). We also cludes one particular open source JSON library share other findings and lessons that we learned from while Java SDK does not. An open-source li- our case study. brary or framework can be tightly integrated into The rest of this paper is structured as follows. In the platform and be part of the platform’s APIs. Section 2 we describe our case study application. In It is in a sense provided as a built-in feature of Section 3 we explain our development of the applica- the platform, often modified significantly through tion, including the configuration of tools and design the integration. An example is Android’s support challenges along with our solutions. In Section 4 we for SQLite, a lightweight, server-less relational assess code reuse by measuring it quantitatively and database system. There are noticeable differences interpreting the measurements. In Section 5 we men- between the Android-specific SQLite API and the tion few related work, and we provide a concluding JDBC-based Java SQLite API. remark in Section 6. • Platform-specific SDK: A third party frame- work is often provided as a platform specific SDK. An example relevant to our case study 2 CASESTUDY is Google’s Firebase Database, a cloud-hosted database. Google provides different Firebase The primary objective of our case study is to mea- SDKs for different platforms, and the APIs of An- sure quantitatively the amount of code reuse possi- droid and Java (Firebase Admin Java SDK) are ble between a Java application and its Android ver- similar but with some subtle syntactic and seman- sion. The secondary objective is to learn complica- tic differences. tions or issues associated with multiplatform applica- tion development—those related with not only design and coding but also configuration of tools for incre- 3 DEVELOPMENT mental development with continuous integration. We develop a Java desktop application and its An- We develop our application incrementally—one fea- droid mobile version, named Price Watcher. The ap- ture at a time—and iteratively by continuously inte- plication tracks the prices of products, or items, ex- grating and testing code written on different platforms tracted from their webpages (see Figure 1 for sample (Cheon, 2019). It is crucial to have adequate tool screenshots). The application helps a user to figure support for multiplatform application development. out the best time to buy items by watching over fluc- Since we develop two versions of an application, one tuating prices. As the prices are scraped from web- for each platform, our development environment log- pages, the watch list may consist of items from differ- ically consists of three IDEs: two platform-specific ent online stores or websites. IDEs and one for developing the common code. For Most applications of today are built with libraries Android, we of course use Android Studio, the of- or frameworks that are either provided by the plat- ficial IDE from Google for Android application de- forms themselves or acquired from third parties. velopment built on JetBrain’s Java IDE called IntelliJ 247 ICSOFT 2019 - 14th International Conference on Software Technologies IDEA. For the development of both the Java applica- User interface (UI) tion and the common code, any reasonable Java IDE including IntelliJ IDEA will work. However, since we are also interested in learning issues caused by diver- Plugins, Shared model: extensions business logic, storage sity of tools, we opt for Eclipse. and utilities and network One key requirement for incremental development of a multiplatform application is to propagate changes Figure 2: Application architecture. immediately from one IDE to the other. We use Apache Maven, a software project management and tion, the PIP and the PDP code are often interwo- build tool, to share code and propagate changes in ven and tangled. For a multiplatform application, we the form of a library, a Java archive (jar) file. Both need to separate them and make the dependencies be- the Java project and the Library project in Eclipse tween them clean and explicit. In particular, we need are Maven projects, and the Library project produces to eliminate any dependency of the PIP on the PDP. a library jar file, called an artifact in Maven, of the There are several different techniques and approaches common code. The library jar file is installed in the possible, such as required interface, inheritance and Maven local repository and becomes available instan- hook, parameterization, interface cloning, and inter- taneously to the Android project.