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. CodeShoppy
As can be seen from Table 1 the size of the app is somewhat proportional to the standard redeployment time. The installation size reported by the Nexus 5 phone was 672KB and 11.95MB respectively for the two sample apps. Having a turnaround time of 3 seconds, does not sound like much, but recall that the app is completely restarted, so all state is lost. For larger apps like My Tracks (medium size), where the clean redeploy is 15 seconds, the redeploy time is much more felt as a pain for developers. With a reload time of not much more than half a second (for reloading 13 changed classes) as offered by JRebel.Android it saves more than 95% of the dreadful redeploy timentrospection results, and new members cannot be found through reflection at all. InstaReloader has some support for reloading resources, but from simple tests notable issues were observed. Also, in contrast to JRebel.Android, InstaReloader leaves generated artifacts inside the Android manifest file, which will pollute production code.
https://codeshoppy.com/android-app-ideas-for-students-college-project.html