Quantitative Evaluation of App Inventor in Cloud-Based Chess Programming

Transcription

1 Quantitative Evaluation of App Inventor in Cloud-Based Chess Programming Sura Peter, Kun Wang, Elizabeth Halash, Cheng-Zhong Xu Department of Electrical and Computer Engineering Wayne State University, Detroit, MI {speter, kwang, ehalash, Abstract App Inventor for Android is a web-based visual programming language that allows non-technical users to program applications for mobile devices with an Android operating system. We used App Inventor to create a chess application to show the capabilities of cloud computing. App Inventor was used to create the user interface (UI) of the chess application, while a chess engine was placed on Google s App Engine. Though App Inventor is a powerful tool, it still has some limitations. Our comprehensive analysis of App inventor includes a user experience as well as a quantitative analysis. From a user experience perspective, we found that the main limitations occurred in the Block Editor, which included programming lag time and the inability to generalize certain function blocks that can simplify the program. Quantitatively, we found that UI cost remained relatively constant with changing moves and difficulty. We also compared the App Inventor chess game with a native version of the game, in which we found that the App Inventor application was much larger than the native code application in terms of file size. We also found that the calculation time was constant between the two games versions, while the communication time varied based off network latencies. Keywords: App Inventor, cloud computing, mobile computing, chess programming. 1. Introduction App Inventor for Android (AIA) is a web-based graphical user interface (GUI) programming language which allows users to program applications for devices running the Android operating system. It was made available to the public by Google in App Inventor is now available to the general public. Anyone with a Gmail account can make an application using App Inventor by going to website in reference [2] and clicking on the My Projects link in the upper right hand corner. App Inventor uses a drag-and-drop interface to piece together an application, just like putting together a puzzle. The two main goals of App Inventor are to allow all Android device users to be able to develop applications, even those without programming experience; and to be a learning tool used to teach students how to program applications for mobile devices [1]. A comparable software is Alice [3], a GUI built to teach students logical thinking and develop early programming skills that will enable students to transition easily into programming with a native language. Unlike Alice, which helps students understand object oriented languages such as Java C++, and C#, App Inventor helps non-technical users understand how to program applications for mobile devices. We decided to use App Inventor to create an application to show the power of cloud computing. We wanted to choose an application that could partially in the cloud, while other aspects of the application that did not need the power of the cloud could run locally on hardware. For this reason, we decided to use chess, a computationally intensive game in which its user interface (UI) could run locally. Chess engines need to evaluate millions of nodes to calculate the next best move in the game. For this reason, running a chess application on a physically limited devices such as mobile phones can strain its resources. It makes chess an ideal application for cloud computing. We used App Inventor to program a UI for a cloud computing chess application. Our chess application needed to connect with a Google App Engine server, which was done with the help of a web database component. Other design specifications, such as drag-and-drop versus text box input UI s, were considered and evaluated. The text box input design was chosen due to its relative simplicity, especially when using App Inventor. The final application file was 2.70 MB compressed, with over two thousand code blocks used to program the game. This is compared with the 65 KB file of a native version of the game that we created. Only some of the rules of chess were implemented, due to time constraints and App Inventor limitations, though the rules that were implemented can easily be extended to fully develop the chess application. The major App Inventor constraints encountered were with the Block Editor, one of the three components that make up App Inventor. Some examples of these constraints include programming lag time (a noticeable time difference between the start of a code block

2 being dragged and when it actually moves), inability to generalize some function blocks (such as the MoveTo block), and a fixed Block Editor height in which code length could easily exceed and cause arrangement issues. We evaluated App Inventor quantitatively by gathering time measurements from the chess application for three different levels of difficulty. We also compared the App Inventor chess game to a native code version that we developed. We found that calculation time remains constant between the two versions, communication time varied due to network conditions, and UI time was much better on the App Inventor version, mainly due to the different implementation methods chosen for the different versions. Not many related works exist currently toward evaluating App Inventor for Android. This is because App Inventor is a new application, still in its beta phase. An introduction to App Inventor has been written in media outlets such as TechCrunch [4] and the New York Times [5], but they do not exhaustively use App Inventor to create a large application such as chess. The applications they developed were very basic, merely done to give a general idea of what App Inventor can do. Our analysis of App Inventor is more in depth; we exhaustively put App Inventor to the test by using it to develop a chess application, which required a large number of components and code blocks to create. The rest of the paper will be organized in the following manner: Section 2 will discuss the motivation for the evaluation of App Inventor; Section 3 will explain how we used App Inventor to program chess, including some examples and explanations; Section 4 will discuss App Inventor s comprehensive evaluation, including a user experience as well as a quantitative evaluation; and Section 5 will conclude our findings. 2. Motivation Cloud computing is a popular concept that is being incorporated into our everyday computing world. Cloud computing offers on-demand resource allocation and a much larger amount of computational capability and storage space compared to local machines. Data in cloud computing systems is stored on a central server, whose services are provided by companies such as Amazon or Google. Some advantages of using a cloud system to run applications include saving energy lessening the burden on local resources, and being able to run applications that many not have been a feasible due to resource constraints. Cloud computing is also being realized as a viable option for mobile devices. Mobile devices have significantly less physical resources than other computing devices due to their size. Consumers demand a smaller mobile device for ease of transportation, yet demand for more computing power is growing. Today s mobile devices have become a central tool that compact other electronic tools into one. Taking pictures, gaming, paying online bills, and finding directions are all examples of tools that are incorporated in today s mobile devices. However, mobile device resources are physically limited and may not be able to handle the computational demand required without draining a large amount of the battery s power. Mobile devices are then a good case for using cloud computing to alleviate the energy and resource problem. We know that graphical or computational games are now being used as killer apps [8], or desirable software that proves the core value of larger technology. This is because games that require complex graphic capability or large computational capacity cannot be executed on hardware lacking the physical resources. Cloud computing can make the execution of such applications possible and less straining on local physical resources. We only outsource the computational part of chess to the cloud, while the rest of the application, mainly the UI, would run locally on the mobile device. A chess engine, computer software that can play a game of chess, was placed on Google App Engine servers, which computationally decides the next best move to make for the computer player, while the UI needed to be created that could handle user input and communication with the server. Our application of choice is chess because of the complexity of the game. Chess is a heuristic game; in other words, the moves made in chess are based on experience. There is no one good way to play a game of chess; this is because a player s best move depends on their opponents moves. Chess engines use a computer s computational power to implement decision algorithms, such as the Minimax or Alpha-Beta Pruning algorithms [10]. In such algorithms, the chess engine can look multiple moves ahead, creating millions of nodes that must be searched to identify the next best move. The amount of computation needed to search such a large number of nodes make chess a desirable application for showing the power of cloud. Chess proved to be the ideal application for a few reasons. One reason for using chess as our cloud computing application is because of the ease in modifying the search depth of the chess engine; the larger the search depth, the more difficult the chess game will be and the more search nodes the chess engine needs to evaluate. Being able to modify the difficulty of the game can give us comparable data without changing many variables. Another reason for using chess is because of its asynchronous capability. A chess move can be sent to the chess engine from the user interface (UI) and the engine can respond with its next best move without needing to synchronize with the UI. This simplified the communication process between the UI and the chess engine. The Android operating system was chosen for this project because of the open source nature of its

3 applications. We could create our own application and test it with an Android mobile device with ease. App Inventor was the language of choice because of its promise of simplicity. Coding chess with native Java code proved some difficulty. Some open source applications were found, such as Honza s Chess [9] and DroidFish [7], but the UI and chess engine were programmed together, and could not be separated easily without rewriting the whole application. We used a simple chess engine that we found called Pyotr [6], that we modified to communicate with the UI and so that it could be placed on Google s App Engine. It has three levels of difficulty, hard, medium, and easy, that change the amount of computation was done to calculate the next best move. Alpha Beta Pruning was used as the algorithm for computing the next best move. We chose this engine because of its simplicity and because of the fact that it did not incorporate a UI in its native code. Any other chess engine can be used with our App Inventor application with some modification. The next section will describe some of the steps taken to program chess using App Inventor. 3. Programming Chess with App Inventor To explain how App Inventor was used to develop a chess application, we will first look at the main parts that make up App Inventor. Then, details of how we developed the chess application will be given, including design considerations and programming examples. This paper will not be a comprehensive guide to using App Inventor; the examples here will only be applicable to our chess application. For more detailed information about how to use App Inventor can be found in reference [2]. 3.1 App Inventor App Inventor is made up of three components: the Designer window, where application components, such as buttons, text boxes, and pictures can be added to create the application view; a Block Editor, where each component is assigned a behavior; and a phone or emulator used to download an application for testing purposes. App Inventor is designed to be used by anyone, even those with no programming background. App Inventor achieves this by using a using a GUI interface language to avoid restricting app developers to one syntax language. It prevents programming errors by allowing only certain blocks to connect together, to avoid programming something that does not make sense. For example, ImageSprites, an animation component in the Designer window that can be dragged, moved incrementally, or interact with other ImageSprites, can only be placed within a canvas, a two dimensional, touch sensitive panel. App Inventor will not allow you to use ImageSprites outside of a canvas, since the application cannot detect a dragged or touched event occurring with the ImageSprite otherwise. An example of App Inventor s error detection in the Block Editor is not allowing a number block to connect with a text variable block. In summary, App Inventor provides highleveled components to simplify the programming. 3.2 Developing the Chess Application Design Considerations. Two main interface design options were considered. A drag-and-drop interface was one of the design options, in which a user can move a piece simply by dragging it to the user s desired location. The other option was providing an input box, in which the user could enter a valid chess move to make. The second design option, providing a text box and a button, was chosen to simplify the error-checking process. Checking a text box to make sure the user has entered a valid move is easier to implement on the App Inventor versus allowing the user to drag-and-drop a chess piece anywhere on the board. Once the game design was chosen, the components of the game where placed in the Designer window to create the visual image of the chess application How it Works: Programming Examples. The chess application starts with a new game once the screen is initialized. All the ImageSprites (chess pieces) are made visible, enabled, and are placed in the correct starting positions. The user always plays with the white chess pieces and always starts the game. The user must make an input in the way of coordinate (letter and number) of piece that I want to move combined with coordinate (letter and number) of box I want to move the piece to. An example of this would be e2e3, which means the user wants to move the fourth pawn from the right (located in e2) one space forward to e3. If a user inputs an incorrect move, such as selecting an empty box to move or selecting a letter or number that is outside the range specified on the board, the user will be notified that an error has occurred. Each letter and number correspond to specific x and y values that are used to move each piece to its correct position on the board. This correspondence is stored in the TinyDB, which is used as a reference table to match the user s text input with proper x and y values that can be used to move the chess pieces. Once the user has entered the move that will be made and presses the Send button, the application scans the pieces for the correct piece that correspond with the user s selection. This is done by checking whether the current x and y values of each piece on the board match to the first x and y values provided by the user (the first two characters in the string). Once the piece is identified, it is moved to the x and y values that correspond to the user s specification

4 Figure 1: Sample code from App Inventor used to move the correct piece to its destination. (the second two characters in the string) using the MoveTo function block. Sample code of this search and move of a piece can be seen in figure 1. This search had to be made for all thirty-two pieces because the App Inventor cannot generalize function blocks for all pieces. For example, the app inventor cannot do the following: for (int i = 0; i < white_pieces; i++){ if (( i.x = xvalue_entered) & (i.y =yvalue_entered)){ MoveTo(xvalue_entered, yvalue_entered)} }; The native code iterates through all the pieces until it finds the one that matches with the coordinates specified by the user, and then moves that piece to the user s desired location. It has been generically designed to work for any white piece. In the App Inventor, each MoveTo function (as well as all the other functions) is associated with a specific ImageSprite. Thus to move a block, it has to be checked as the block that needs to be moved first, only then can it be moved by calling the appropriate MoveTo function. The user s move is sent to the server using the TinyWebDB component, which uses JSON requests, a protocol that allows the application to send a string to a URL (in our case, the server s URL) and waits until a response is sent back. Once the string is received by the chess engine, it is processed by the server and next best move to make is calculated. Once the move is chosen, the server sends another string back to the application with the same four-character string format described above. The application then moves the black piece for the computer just as it would a white piece for the user. Moving a white piece, however, is more complicated than moving a black piece because human error needs to be considered. Measures were taken to check for an invalid chess move made by the user. Since the computer s move is computed Figure 2: Example code for handling a collision event. A white queen collision event is being handled above. arithmetically, it is assumed that the computer will not make an invalid chess move. In the case of one piece taking another, the CollidesWith function block is used. This function block checks to see if the ImageSprite has collided with another ImageSprite. Like the MoveTo function block, the CollideWith function block is associated with a specific ImageSprite and cannot be generalized. For this reason, each chess piece must handle colliding with another piece separately. If a white piece collides with a black piece and a black piece made the move that caused the collision, then the white piece has been taken. To take a piece, the ImageSprite is made invisible and disabled. If a white piece collides with another white piece, then the user has made an error in moving the piece. The white piece is moved back to its original position and the user is asked to make another move that is valid. This error checking is not performed for the black pieces because it is assumed that the chess engine will always make a valid move. Example code of handling a white piece s collision can be seen in Figure 2. A new game can be started at any time by pressing the New Game button, which resets all the pieces to their original position, makes them all visible and enabled (in case there was a piece taken), and notifies the chess engine that a new game has been initiated so that the server can reset the game as well. To test the effectiveness of our cloud-based chess application, a clock component was added to measure the time difference between sections of code. For example, the time was measured right after the send button was pressed by a user as well as right after the application receives a response from the server. The difference of this time in milliseconds is the total time spent by the server, which includes time spent calculating the next best move as well as communication time spent sending strings to and from the server. To find the communication time, we had the

5 chess engine send its own calculation time that it computed. The calculation time was sent along with the move in the same string, which was then parsed in the application. The total server time calculated by the application level minus the calculation time received from the server equals the total communication time it took to send the information to and from the server from the mobile device. Other time measurements were computed in the same manner. A Notifier component as well as text boxes were used to display the time measurements so that we may collect and analyze them. Section 4 will go into detail about the analysis of the results collected from the App Inventor Application. 4. Quantitative Evaluation of App Inventor 4.1 App Inventor User Experience App Inventor was a helpful tool to use, but it did have its limitations. One limitation was the inability for function blocks to be generalized for different components. This made programming a chess application much more challenging since the same procedures had to be repeated for thirty-two chess pieces. The repetitiveness of the code created a very large program, which included over two thousand blocks of code (table 1 breaks down the code block count), a total of 2.70 MB file, 1.04 MB of which was code and 61.3 KB of which were pictures used for the interface. The application unpackaged on the phone was measured at 4.74 MB. The large App Inventor code was compared to a chess application (with the same functionalities as the App Inventor version) that we developed using native java code, which had a file size of only 65 KB. The large size of the code makes the Block Editor respond very slowly to the changes the programmer wants to make to the code. Quite a few seconds worth of lag time was noted when trying to move a block of code from one area in the Block Editor to another. It should be noted that not all chess moves were implemented. The rules of chess were only applied to some pieces because of their simplistic movements. For example, the knight was relatively easy to program since it only moves in an L shape (e.g. two vertically up and one space over horizontally, or vice versa). The pawn, however, is much more difficult to program since it can move in different directions depending on its position on the board. To fully implement the rules of chess, the application would have been much larger, creating a larger lag while programming. The Block Editor is limited in other ways as well. For example, multiple blocks could not be selected and moved at the same without connecting them together first. In the case of a large program where the programmer starts to experience longer App Inventor lag time, moving chunks of large code could take quite a while. Moving each Table 1: A breakdown of the number of code blocks used to program chess. A code block refers to a single puzzle piece, not a full block of code. block separately or connecting them first before moving them can mean hours of tedious work. This can seems very inefficient, especially when comparing it to a select, cut, and paste of chunks of native code, which can take seconds to accomplish. Another example is that the Block Editor had a fixed window height. Thus, if a block of code was longer than the Block Editor s window size, it would run off the window and could not be seen by the programmer. If any changes needed to be made in the lower part of the code, it had to be proved time consuming, especially when the code had to be written in a certain order. One minor drawback in the Block Editor is the inability for some code blocks to expand to allow multiple inputs. For example, two texts can be joined together to create a single text by using the join code block. The problem dislocated from its function block, sometimes in multiple fragments, and reinserted after the changes were made. This occurs if you have more than two texts that need to be joined together. Multiple join blocks then need to be used, one join within a larger join block, to achieve the task of combining multiple chunks of text. Similarly, in native code, a developer can write if/else statements comprised of multiple else if conditions. In App Inventor, an if/else code block only has one if condition and one else condition. Thus, to chain together multiple else if conditions, multiple if/else or if statements need to be used within a larger if/else code block. Intuitively, a developer might expect one join block or if/else block to expand, allowing multiple conditions or statements to be incorporated within one block rather than using multiple blocks to achieve the same task. Even though a touch screen interface would have been more user friendly, it is much more difficult to implement because of the limitations previously discussed. A touchscreen interface would have needed a larger amount of error checking, especially to center the piece that was dragged to the middle of the square the user intended, would have made the code much larger, and in turn, much slower and harder to work with. Persistent storage at the server side was also considered to reload the chess application with a game that was abandoned. This would not have been feasible on the client side when using the App Inventor since each piece needed

6 Figure 3: The time cost results for the hard difficulty level. It can be noted that the UI time remains relatively low throughout each move compared to the other time measurements taken. Communication time remains relatively low as well. Figure 4: The breakdown of time cost for a single move based on the difficulty of the chess engine. Again, it can be noted that the UI and communication times were relatively low, especially with the higher difficulty. to be checked for its last position on the board, as well as if it was previously taken off the board (when the piece was really made invisible and disabled to achieve the same visual idea). This again would have made the code much larger and more difficult to work with since it had to be implemented thirty-two times, once for each piece. 4.2 App Inventor s Quantitative Evaluation The App Inventor chess application was tested using Google s Nexus One mobile device, which has the Android 2.2 operating system, a 512 MB memory, and a 1 GHz Qualcomm QSD 8250 Snapdragon processor. The results of the App Inventor chess application are recorded in terms of time cost. Total time includes the time the user interface (UI) took to make one white move and one black move, as well as the total time the server took to respond back to the application. The Server cost includes communication cost to and from the server and time the server took to calculate a move. Time cost was calculated for three difficulties hard, medium, and easy. A total of seven moves were made. The moves 1 to 7 are respectively as follows: e2e3, g2g3, b2b3, g1f3, f3e5, f1e2, b1c3. These moves were chosen because of their simplicity so that the order of moves can remain constant as the game difficulty changes. If more strategic moves were chosen, it could not be guaranteed that the same moves made in one difficulty could be made in a different difficulty. Figure 3 and 4 summarize our findings. In figure 3, we can see that the UI time and communication time were relatively the same throughout each move. From figure 4, we can see that the higher the engine difficulty, the longer the server took to calculate the next move. This also effected the total time and total server time, which were also longer. Changing the difficulty did not have an effect on the communication cost and UI cost. Communication time ranged anywhere from 233 milliseconds (ms) to 829 ms, which is pretty quick considering the chess engine is located on a Google App Engine server in California. UI time ranged anywhere from 637ms to 1310 ms, depending on which chess piece was being moved since it executes in a different part of the code. It should be noted that the calculation time does not relate to the move that is played. For example, the chess engine took 5 seconds to calculate move 3, yet it wasted no time in calculating move 4, replying back to the mobile device almost immediately. This is a characteristic of the chess engine itself and not the cloud nor the application itself. We have also considered the location of deployment for our chess engine. We re-tested the App Inventor application with the chess engine running on a local machine to compare with the Google App Engine deployment. As shown in Figure 5, the total time cost per move is very close between the two locations of deployment, with the largest difference being around 200ms. The major difference comes down to the calculation time (which can vary slightly due to server resource availability) and communication cost (due to network latency). This difference can be neglected compared to the total time cost. We can conclude that it does not matter where the chess engine is located, whether it is in California (the location of Google App Engine servers), or right next to the mobile device; the total time cost will remain relatively same. The App Inventor chess application was also compared to a chess application created using native java code. We first should mention that the native code was implemented differently than the App Inventor code. In the native code, the text box and send button because the native code can be generalized much easier than the App Inventor code. We were able to create a touch screen interface versus using determine where the user intended on placing the chess piece. For this reason, the UI time took the majority of the native code s time to execute as shown in Table 2. The App

7 Table 2: A low level difficulty game s time average comparison for three time measurements collected from the App Inventor chess application and the native code chess application. The native code s UI time takes up a large portion of the total time spent per game. Communication time remains the same and communication time also remains relatively the same. Figure 5: The total time cost for a hard level difficulty game using the chess engine on the Google App Engine servers as well as a local machine. Inventor code did not have this problem, since it used the text box and a send button to receive the input from the user. The App Inventor code s UI time measurement is thus much less than that of the native code s UI time. We also compared the actual values of the calculation time and communication time between App Inventor and the native code. From Table 2, we can see that calculation time is the same between the two applications as long as the same level of intelligence was used. We can also see that communication time between the two applications is relatively close. 5. Conclusion App Inventor is a powerful tool when it comes to developing relatively small applications. It can simplify programming an application from a few hours of work to a few minutes. However, some drawbacks are experienced when developing a large application. The Block Editor s limitations make up the majority of the flaws with App Inventor, such as the inability to generalize some function blocks, a fixed Block Editor s window height, and lag time between dragging of code blocks. We found that even with such a large application, App Inventor s UI time is relatively low compared to the total time of move executions within the chess application. We also found that communication time depends solely on network conditions, and calculation time does not change between App Inventor and native versions. App Inventor file size is also much larger than its native code counterpart. 6. Acknowledgement This work was supported in part by NSF under grants CNS , CRI , CNS , CCF and under a Research Experience for Undergraduates (REU) grant CNS References [1] Abelson, H.; Chang, M.; Friedman, M.; Lomas, C.; Wolber, D., "Workshop Google App Inventor for Android: Creating mobile applications as a first computing experience," IEEE Frontiers in Education Conference (FIE), Oct [2] App Inventor Beta, 13 Jan, [3] Dann, W., Cooper, S., and Pausch, R. Feb, Learning to Program with Alice. 3 rd edition. Prentice Hall. [4] Kincaid, J. "It s Alive! Taking Android s App Inventor For a Spin." TechCrunch. 12 Jul [5] Lohr, S. "Google s Do-It-Yourself App Creation Software" The New York Times. 12 Jul ml?_r=3&th=&adxnnl=1&emc=th&adxnnlx= r+le7vgfqmmfbnbdz8kba [6] Marountas, J. Pyotr Chess Engine. =0&choice_ID=3&q=0 [7] Österlund, Peter. DroidFish - Strong chess program for the Android platform. [8] Ross,P.E. "Cloud Computing's Killer App: Gaming," IEEE Spectrum, vol.46, no.3, pp.14, March [9] Šachy, Honzovy. Honzovy šachy for Android. 18 Mar [10] Zhang, C., Cui, J. "Improved Alpha-Beta Pruning of Heuristic Search in Game-Playing Tree," Computer Science and Information Engineering, 2009 WRI World Congress on, vol.2, pp , 2009.