Reloading for Android
This paper is accompanied by a video demonstrating the tool in action. In this section we will briefly describe the demo applications shown in the video, which will also serve as the foundation for the performance evaluation in the next section. The first demo application is one of the sample applications made by Google to showcase some of the capabilities of the Android platform called DivideAndConquer, [4]. It is chosen for this paper primarily because the visual nature of a game allows the viewer to clearly see the immediate effects of runtime class reloading. The application consists of only 13 classes. Clearly, an app which is this small does not have a huge redeployment time, thus the direct savings gained by utilizing class reloading with JRebel.Android will be relatively small. However, from the enormous amount of user experience with JRebel for standard Java, we know that developers change their coding habits when using class reloading. Typically, developers will test out even small changes much earlier simply because they are automatically reflected in the running application automatically. The key is that class reloading will keep developers in “the zone”, which heavily improves productivity. In addition, the fact that all of the application state is preserved adds to the benefits of not being constantly interrupted by having to recreate some specific runtime scenario before testing the changed code.Given the small size of the Divide and Conquer app, a second more realistic application has been picked for showcasing in this paper, namely the open-source Google-developed application named My Tracks, [5]. My Tracks is much larger and contains just over 500 classes, and lots of resource files and declarative resources in XML files. Fig. 4 shows a couple of screenshots of the appIn this section we report on the redeploy times of Android application development on the chosen sample applications with and without JRebel.Android. The redeploy time without JRebel.Android is measured from the time where the developer presses the run button in the IDE, which triggers reinstallation on the device. For these experiments a Google Nexus 5 phone was used. The redeploy time with JRebel.Android is the time taken from when the tool detects a class file change (using OS file system notifications) until the change is reflected on the device. The tool automatically writes this time to system output during normal operation. Table 1. shows the measured redeploy times. All numbers are simple averages based on at least 10 samples. Numbers were very similar for each sample, so improving the statistic validity of the measurements had a low priority for this paper. Code Shoppy
https://codeshoppy.com/android-app-ideas-for-students-college-project.html
Comments
Post a Comment