1. CSE 4939 Alex Riordan Brian Pruitt-Goddard Remote Unit Testing

2. Objective Development and implementation of an interactive mobile source control application, based on the Google Android development platform. Submit request Receive results This is where the magic happens! Send results back Get request Internet

3. Personal Motivations A chance to further familiarize ourselves with the Eclipse platform. A chance to analyze, understand, and implement a new program based on a framework we have never worked with before (Android SDK). Phone applications are becoming increasing popular as cell phones computing powers have drastically increased over the past few years. Interested in developing a client-server based program on our own.

4. Overview Features o Edit, upload, and execute small programs and files remotely from your phone. o Produce and send program's results back to your phone. o Allow more complex results to be saved to a log on the remote central server. Why? o Sometimes it is more convenient to write a small program from what you are carrying with you, rather than having to find a computer to run and execute it. o There already is an iPhone-exclusive SVN application. Android deserves something as useful.

5. Benefits The application will be appealing to unit testers – small programs with simple results (did test A pass/fail?) Have you ever been traveling in a car or train, or perhaps even in class, and suddenly the solution to a problem comes to your head? Simply take out your phone, write your program, and execute it. Or simply upload that file to your project's central repository if you do not want to execute it quite yet.

6. Development Platform Development environment: Eclipse 3.5 Platform/framework: Android 2.2 SDK Coded in: Java (We're sorry, C++) Android Emulator

7. Preliminary Design Client-side o Should be able to create, edit, open, and save small source files, as well as issue other common source- control commands such as commits and diffs acting on those files. o Should be able to configure server's address and other options such as preferred version control system, as well as logging options.

8. Preliminary Design (cont.) Server-side o Should be able to process requests from the client and send the desired results back: did the unit test pass or fail? Was there a difference in the last 2 versions of a file? o Should be able to run the programs stored on your computer, given a directory and file structure input from the client. o More complex results not suitable for a phone screen can optionally be saved to a log file for later viewing. You should also be able to view these on your phone if you don't mind scrolling through pages of output.

9. User Interface Client-side o Should be clean, simple, and responsive. o Will try to implement certain features such as syntax highlighting when editing programs, if time allows. Server-side o Simple window-based interface that allows you to set options and get the server running. o Creates a folder storing the test and its output to reference back to during future development

10. Timeline September-October o Define types of messages that will need to be sent; essentially mapping out a basic application-level protocol. o Develop the client and server back-ends. o Essentially get the client and server communicating with each other, with simple generic messages to be sent between each other. o Develop a preliminary testing strategy.

11. Timeline (cont.) October-November o Start implementing more complex parts of the protocol, the more complicated messages that will need to be sent. o Integrate other external requirements – hooking up software like your SVN system to the server-side program. o Begin working on the client and server front-ends. o Continue work on the testing strategy.

12. Timeline (cont.) November-December o Finish the back-ends and front-ends. o Finish the testing platform. o Tweak the program for efficiency and bugs. o Write the documentation for the program.

13. Questions/Comments? Well?