Comparative Study:Native Versus Web Approaches
Some studies comparing mobile native applications to web-based ones can be found in literature as in [10] and [11].In [10], a comparison among different paradigms for mo-bile application development is presented, which includesa discussion about development facilities, performance anduser-experience. A complementary study also compares nativeto web-based applications using criteria as user interface,testability, and development facility can be found in [11]. Morerecently, in [7] implementations of location-dependent appli-cations using native approach and HTML5 based approach arecompared, varying the adopted mobile OSs and browsers, butwithout evaluating efficiency.The performance of Android applications is evaluated in[12], including native implementations as well as web-basedones. However, the evaluated applications make use of the owndevice’s resources as GPS and accelerometer. This study haspointed out already expected results once native implementa-tions are known to provide better performance than web-basedones when this kind of sensors are used.However, another relevant criterion in this domain is theenergy consumption, motivating researchers to investigate howdesign and implementation decisions impact on the devicebattery discharging. In [13], experiments evaluate the energyconsumption of native mobile applications. More recently,in [5], authors compare the energy efficiency achieved byAndroid native applications to JavaScript implementations,employing the Rosetta Code Benchmark. Yet, this comparisononly evaluates JavaScript and native implementations and thus,other web-based approaches are not explored, as for instancePHP implementations or yet the combined usage of JavaScriptand Node.js in a client/server architecture.Differently from [10], [11] and [12], we evaluate energyconsumption as well execution time, to compare differentAndroid applications implementations. Similar to [5], we alsocompare native to web-based approaches in terms of efficiency,but we explore three different web-based implementations:PHP, JavaScript, and JavaScript combined to Node.js.
A. MethodologyTo compare the efficiency achieved by the different develop-ment approaches, different implementations of a single mobilesort application were developed. In all implementations, thesame sort algorithm has employed, which has the complexityO(n2). In all experiments, the array is initialized in descendingorder, which means the worst case for the sort algorithm. Thesort application has been chosen once it presents a knowntime complexity and it is hard enough to stress the devicecomputational resources. Besides, in applications that searchand show simple data or submit a form to a server, nativeimplementations are known to be more efficient.Our experiments also explore the variation of the processingload, which is facilitated by the sort algorithm, aiming to an-alyze how it impacts on the temporal and energetic efficiencyachieved by the different implementations. Considering thatthese implementations also differ from each other accordingthe local/remote processing, the array size also impacts inthe communication in cases where the implementations adoptsremote processing. Thus, we also evaluate the impact of thecommunication in performance and energy consumption.In all performed experiments, we employed as mobiledevice, a smartphone MotoX (second generation) with 2GBof RAM, running Android OS version 6.0. The array size hasvaried using 100, 1,000, 10,000, and 100,000 elements.The experiments were organized in three comparative casestudies, all using the same application in the four evaluatedscenarios but considering different approaches. The first onecompares the efficiency of the PHP implementation to nativeone, employing one web server to remotely execute the PHPcode that is accessed from the device through the wifi network.The second case study compares two JavaScript implementa-tions to the native implementation.https://codeshoppy.com/android-projects-titles-ieee.html The first one basically usesJavaScript syntax without any framework facilities, while thesecond one explores facilities from the Node.js technologyto make possible to execute the JavaScript code on the webserver. In the third case study, an overall comparison ispresented and results achieved by the four approaches areanalyzed in order to observe tendencies.To compare the efficiency of the different implementations,we analyze execution time and energy consumption. Thesemetrics are estimated through experiments. Since these mea-surements vary in each execution, we have repeated eachexperiment thirty times for statistical validity of results. Theaverage of the thirty measured is computed as well as thestandard deviation, and t-test is applied to verify if the averagespresent statistical significant difference.Before each experimental execution, all other mobile appli-cations are closed to avoid that these impact on achieved re-sults. In addition, the application under analysis was preventedfrom running in the background since it could interfere in theestimated performance and consumption.For performance evaluation, the current time is collected atbeginning and in the end of execution, and both values are sub-tracted to determine the application execution time. To do thisfrom an Android code, the methodSystem.currentTimeMillis is used. In case of remote execution, a strategy is used toconsider also time of execution in the server.To evaluate the energy consumption is employed the Pow-ertutor [14], which is an Android application for energy con-sumption estimation. Although PowerTutor is an estimationtool and includes an error rate, according to highlighted in[15], this tool can be employed to analyze tendencies. In theconducted experiments, we start the PowerTutor and then, theapplication under analysis is started.
B. ImplementationThe Native implementation was developed in Java. Fig.1 depicts the methodonCreate, which is invoked when theAndroid application is started. Firstly, an array of integernumbers is created and initialized with the numbers in de-scending order. After that, this array is sorted using the methodbubbleSort(line 21) and printed (lines 22-25). The methodSystem.currentTimeMillisis invoked in lines 8 and 27 to collecttimes and the execution time is then computed (line 27).
In the PHP code (from Fig. 2), firstly, the array is createdand initialized in lines from 5 to 8, and then this array is sorted(lines 9-19) using the Bubblesort algorithm, and finally, printed(lines 20-22). In the client-side, in the Android Java code (fromFig. 3), the methodonCreateuses an embedded browser calledWebViewto load the URL responsible for invoking the PHPcode in lines from 11 to 13. For performance estimation, themethodSystem.currentTimeMillisis invoked in lines 8 and 19,at beginning and end of execution, respectively. Yet, in line 19,both times are subtracted and the execution time is computed.However, it is important to highlight that to determine theend of the PHP code execution (remote execution), this nativecode verifies if the load page is closed and when it is true,finishing time is collected (lines 18-19) and the applicationunder evaluation is closed (line 21). This control of the remoteexecution finishing can be observed in the code from line 16to 23 and it is considered for analysis of execution time aswell as energy consumption.Besides of PHP, two JavaScript implementations are eval-uated in this work. The first one encapsulates the JavaScriptinto an HTML code, and is mentioned in this work as theJavaScript implementation. On the other hand, the second oneadopts Node.js and is named here as the Node.js implemen-tation.The JavaScript implementation runs locally in the mobiledevice. The application’s main operations are implementedin JavaScript, but to allow the efficiency estimation, thisJavaScript code is encapsulated into an Android native code(in Java), similar to the employed in the PHP implementation.This native code is illustrated in Fig. 4 and also uses aWebview to invoke the JavaScript code (summarized in line 15). Someconfigurations are performed in lines from 16 to 22 in orderto enable the JavaScript execution from the browser. Thecurrent time is collected two times in lines 10 and 26 forexecution time estimation. Moreover, in lines 23 to 29, a codechecks when the execution is finished, analogous to the PHPimplementation.
The code executed in the server is written in JavaScript andhas several lines identical to the code used in the JavaScriptimplementation (from Fig. 5). Although, it includes lines tocreate the server and define the part of code executed there(lines 16-27). In this code the array is created, initialized (lines19-21), sorted (line 22) and printed (lines 23-25). All theseoperations are executed in the server. The server adopted inthis implementation is in the same network, differently to thePHP implementation that use a online server.In the native code, represented in Fig. 7, the URL and portto access the Web server are defined in line 4, as well as anembedded browser (theWebview) is defined to access this URLin line 5. At beginning of the methodonCreate, the currenttime is collected (line 11), some configurations are done toenable the JavaScript execution through theWebview, and thenthe defined URL is loaded in line 19. Similar to the codeused to invoke the other both web based-approaches, the pageexecution finishing is controlled in order to correctly computethe estimated execution time (in lines 25-30), considering alsothe remote execution on the server.
