The Error Handler Project. Clyde Carryl. Android Components [Summer 2012] Florida Atlantic University

Transcription

1 The Error Handler Project Clyde Carryl Android Components [Summer 2012] Florida Atlantic University ABSTRACT Android programmers often encounter a unique phenomenon when compiling and running their applications. The program may try to run but may stop short of completion with the following message on the screen: Force Close, see Figure 1. While this conveys to the programmer that something went wrong while attempting to run the application, the information is simply not enough to be of much help to the programmer. For example, the programmer may not know what caused the error and what to do next. For this reason, the Error Handler Project was an exciting idea. How could one help the programmer find out not only what went wrong, but maybe even what to do next. What is surprising is that the information as to what went wrong is actually very much available, even though it is hidden behind many layers of android complexity. Therefore the goal of the project was to get the required information from android, and then to provide it to the programmer in a manner that would make it very useful and convenient for him or her. 1. INTRODUCTION This paper discusses the project in detail, outlining the steps used to create the component for the programmer to use, while discussing any difficulties or issues that may be faced by future developers of such components. The project was built entirely using EMF, the Eclipse Management Framework, even though it calls several android API, most notably the ones required to import and use Logcat. First, a discussion of the requirements is presented, followed by some requirements analysis, key design criteria, the actual model design, proof of the validity of the model, and finally testing. At each stage, the EMF steps used to perform the related tasks will be discussed. 2. Requirements, Analysis and Key Criteria The make-up of the potential user community for this component drove its conception and design. While it is true that most android application developers are seasoned veterans that know their way around the operating system, it is also true that a growing number of developers are

2 less trained, younger, and less programmer savvy than programmers of old. Therefore they need help, and lots of it. The user interface must require little programmer skill. Also the userr interface must contain, in an easy to visualize fashion, simple options for selecting the application to debug, and for submission of such applications. In addition, the component must not slow down processing or in other ways be inefficient. The user must be able to develop their application in the usual way and only use the component when they cannot get past the Force Close problem. However, it must be possible to extend the component to be a useful debug tool for regular use, evenn when the Force Close message is not an issue. Figure 1 Design This component guides the developer by providing an easy-to-use workaround Force Close and other similar problems, literally running their application instruction by instruction to determine the offending instruction that brought on the dreaded Force Close. When the instruction is discovered, they are alerted by a Toast message that the culprit has been found, then when android releases processing back to the programmer, they are presented with a view of the Logcat messages that are related to that particular error. In addition, Logcat type messages

3 generated by the Error Handler component itself will be added for even greater assistance to the developer. Figure 2 The first step in the design is the creation of the system class diagram, as shown in Figure 2. Next, the generated ecore file was used to create a genmodel file. The library file android.jarr was necessary and was imported into the project. Then the genmodel file was used to create the project s model source code. The source code as then constituted contained several placeholders where the behavioral code of the classes would be. The placeholderss were in the form of exceptions that would be thrown if nothing was done about them. These placeholders were replaced by limited behavioral code inserted in part to show that the code worked. Most notable among the behavioral code inserted was code that successfully implemented all of the methods of the imported class android.util.log. Since this is the classs that provides access to Logcat, it was recognized as the most important class and all of its methods were implemented to verify complete functionality. Figure 3 shows a section of the LogcatImpl.j ava file withh some of the new behavioral code.

4 Figure 3 After all of the new code was inserted and the project compiled cleanly, the.editor plugin was launched to allow creation and manipulation of instancess of the model. By creating an instance of the model and using the model to create various associations between the classes, the proof of the model is accomplished. This means that for instancess of containment classes it should be possible to create child instances, and from those child instances it should be possible to create sibling instances. This was done successfully as shown inn Figure 5. For non-containment classes, the validity of the model for creating instances of those classes was demonstratedd by doing a validity check as shown in Figure 4.

5 Figure 4 Figure 5

6 TESTING junit testing was done to verify the integrity of the model. Three tests were run. The first test created a Logcat object and showed that it is the same whether you use the factory or the Logcat class to create the object. The second test checked whether the multiplicities of ErrorMaster s 2 references were as expected. And the third test created an object using the factory, copied it, and verified that the copy was not the original, and also that the copy and the original functioned in the same way. A screen shot of thee test code iss shown in Figure 6, and the successful junit test screen is shown in Figure 7. Figure 6

7 Figure 7 LOOKING AHEAD Possible extensions to this component could involve providing additional features that make it useful to application developers for more extensive use for debug activities that go well beyond addressing just the Force Close issue.