Portability and Design Issues in Developing a Mobile Phone Quiz Application Quiz Pro 2006

Transcription

1 Portability and Design Issues in Developing a Mobile Phone Quiz Application Quiz Pro 2006 Dilip Kumar Nataraja Kumar Problem Report submitted to the College of Engineering and Mineral Resources at West Virginia University in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering Approved by Dr. George E. Trapp, Ph.D. Committee Chairperson Dr. James D. Mooney, Ph.D. Dr. Arun A. Ross, Ph.D. Lane Department of Computer Science and Electrical Engineering Morgantown, West Virginia 2006 Keywords: Mobile Quiz Application, Portability Issues, J2ME, MySQL, JDBC

2 ABSTRACT Portability and Design Issues in Developing a Mobile Quiz Application Quiz Pro 2006 by Dilip Kumar Nataraja Kumar This problem report implements a mobile phone quiz application Quiz Pro This work addresses some of the important portability and design issues. The mobile quiz application package is written in J2ME/Java language. The application allows students to take up a test or a quiz posted by a faculty member over the mobile phone. The J2ME quiz application includes features such as student registration/login, viewing previous test results, multiple choice quiz questions, instant answer verification, error validation and results display. To ensure maximum portability across major mobile manufacturers the following methods were implemented in Quiz Pro Use of Servlets to reduce application size and mobile computational overhead 2. Provision of Graphical and Non Graphical version 3. Use of HTTP protocol to enhance portability 4. Use of High Level API 5. Prevention of Networking Bottleneck Further, Quiz Pro 2006 implements Error Handling, Client Side Validation, Simultaneous Support for Multiple Users and Midlet Security. Some of the future enhancements proposed include providing session handling using cookies and improving MIDP Security by using secure HTTP Connection. The quiz application is packaged into a jar file and can be easily downloaded into the mobile device. The Quiz Pro 2006 Admin web page written in JSP language allows the faculty to conveniently enter the quiz questions, the duration of quiz and the number of questions into a MySQL database file. Apache Tomcat Server 4.0 is used to host the quiz application database file and all other Servlets used in the application.

3 ACKNOWLEDGMENTS I would like to express my sincere gratitude to Dr. Jim Mooney for his valuable guidance, constant encouragement and support throughout my work. I would also like to thank my advisor Dr. George Trapp and committee member Dr. Arun Ross for their valuable suggestions and spending their valuable time to review my project. Special thanks to my friend Hari Menon for his valuable suggestions and help during the various stages of my project development. Heartfelt thanks to my parents, relatives and friends for their constant encouragement, support and love. iii

4 TABLE OF CONTENTS ABSTRACT...ii ACKNOWLEDGMENTS...iii TABLE OF CONTENTS... iv LIST OF FIGURES... vi CHAPTER 1 INTRODUCTION... 1 CHAPTER 2 TECHNOLOGY OVERVIEW Java 2 Micro Edition (J2ME) Configurations Profiles The Foundation Profile The Mobile Information Device Profile (MIDP) Optional Package Profiles The K Virtual Machine Java Servlets Technology HTTP Request for accessing a Servlet Java Servlets Page (JSP) JSP Sessions Apache Tomcat Server MySQL Server CHAPTER 3 QUIZ PRO 2006 SYSTEM ARCHITECTURE Architecture Data Flow between the various functional components Faculty Interface Student Interface CHAPTER 4 PORTABILITY & DESIGN ISSUES IN DEVELOPING QUIZ PRO Use of Servlets to reduce application size Provision of Graphical and Non Graphical version Use of HTTP protocol to enhance portability Use of High Level API Preventing Networking Bottleneck Error Handling Client side validation iv

5 4.8 Support for multiple users simultaneously Midlet Security CHAPTER 5 DEPLOYING THE WIRELESS MOBILE APPLICATION ON A PHYSICAL MOBILE DEVICE Installing QuizApplication.jar using a sample JAM in Sun Java CHAPTER 6 FUTURE ENHANCEMENT Providing Session Handling using Cookies Implementation of Cookie session management Improving MIDP Security CHAPTER 7 QUIZ PRO 2006 SCREENSHOTS CHAPTER 8 CONCLUSION BIBLIOGRAPHY INDEX v

6 LIST OF FIGURES Figure 1 Relationship between J2SE, CDC and CLDC configurations... 4 Figure 2 Client Server Architecture of Quiz Pro Figure 3 Data flow between the various functional components vi

7 CHAPTER 1 INTRODUCTION Quiz Pro 2006 is a mobile quiz application package written in J2ME/Java language. The application allows students to take up a test or a quiz posted by a faculty member over the mobile phone. One of the biggest hurdles in developing a wireless mobile phone application is portability across different mobile environments. In general terms portability may be defined as the ease with which a system or component can be transferred from one hardware or software environment to another. A number of design and portability issues need to be addressed while developing an application in a constraint Java 2 Mobile Environment (J2ME). The J2ME quiz application includes features such as student registration/login, viewing previous test results, multiple choice quiz questions, instant answer verification, error validation and results display. Since the application is intended for use among students it is important that the software is highly portable across mobile phones of different manufacturers. To ensure this, we need to keep the application size as small as possible. This document covers the various technologies used in developing Quiz Pro 2006 package, the general system architecture, its major functional components and the information flow between the various components Some of the solutions implemented to make the software highly portable include: Use of Servlets for user input processing Provision of Graphical and Non Graphical versions of Quiz Pro 2006 Use of HTTP protocol supported by all mobile devices 1

8 Use of High Level API classes as against the Low Level API to enhance portability The document also addresses other issues such as preventing networking bottlenecks, proper error handling, security features, client side validations and support for multiple clients simultaneously. Some of the future enhancements that could improve the application design are also addressed. 2

9 CHAPTER 2 TECHNOLOGY OVERVIEW 2.1 Java 2 Micro Edition (J2ME) Java 2 Micro Edition (J2ME) is Sun's version of Java aimed at machines with limited hardware resources such as PDA s, cell phones, and other consumer electronic and embedded devices. J2ME is aimed at machines with as little as 128KB of RAM and with processors a lot less powerful than those used on typical desktop and server machines. To ensure portability across various mobile environments J2ME is divided into configurations, profiles and optional packages Configurations Configurations are specifications that define the virtual machine features, Java language/api classes and the minimum libraries that need to be available on a J2ME supported mobile device. A J2ME configuration defines a platform for a group of devices, each with similar memory and processing capability. The two configurations available are: 1. CLDC: Connected Limited Device Configuration 2. CDC: Connected device configuration Key features of CLDC Very simple user interface Memory requirements ranging between 128 kb to 512 kb Supports 16 or 32 bit processor Supports Wireless communication (low bandwidth) Limited power capability often restricted to the battery operation. Example of devices using CLDC include mobile phones, pagers and organizers 3

10 Key features of the CDC Provides a large range of user interface capabilities Supports devices with memory ranging between 2 to 16 megabytes. Supports 16 or 32 bit processors Allows connectivity to some type of network Examples of devices using CDC include TV set-top boxes, Internet TVs and high-end communicators and high end personal digital assistants (PDA s). The relationship between CDC, CLDC and J2SE is illustrated in the figure below. Figure 1 Relationship between J2SE, CDC and CLDC configurations As illustrated in the figure the CDC and CLDC inherit all their main functionalities from the J2SE. All the classes which are inherited from the J2SE are precisely the same or subsets of the corresponding classes in the J2SE, and the classes which are outside the J2SE environment may not use the java.* class name space. All features implemented in the CLDC are also implemented in the CDC to achieve compatibility between J2ME configurations. 4

11 2.1.2 Profiles A profile builds on a configuration but provides more specific APIs and a complete environment for building applications. A configuration may be considered as an implementation of a J2ME profile for a particular type of device such as a PDA. While a configuration describes a JVM and a basic set of APIs, Profiles usually include APIs for application life cycle, user interface, and persistent storage and include libraries that are far more device category specific. A device that is designed to support a profile or several profiles should be able to implement all features and Java API classes specified by the profile(s) and the corresponding configuration. Since each profile defines a different set of Java class libraries, you cannot take a Java application written for one profile and run it on a machine that supports another profile. Similarly, you cannot take an application written for Java 2 Standard Edition (J2SE) or Java 2 Enterprise Edition (J2EE) and run it on a machine that supports Java 2 Micro Edition (J2ME). The two types of Profiles available are the Foundation Profile and the Mobile Information Device Profile (MIDP) The Foundation Profile This profile is build on top of the CDC. It provides a profile of the Java Platform suitable for devices that need support for an intense network enabled Java environment, without a graphical user interface The Mobile Information Device Profile (MIDP) This profile is build on top of the CLDC. This profile provides a standard platform for small, resource-limited, wireless-connected mobile devices like cellular phones. Version 1.0 of the MIDP specification addresses: The various devices implementing the J2ME CLDC configuration Persistent data storage using simple record based database model 5

12 HTTP-based networking using CLDC Generic Connection framework Some of the other profiles available are the RMI profile (build on top of Foundation Profile and CDC) and the PDA Profile (build on top of CLDC) Optional Package Profiles An optional package is also a set of APIs, but it does not define a complete application environment. An optional package is always used in conjunction with a configuration or a profile. It extends the runtime environment to support device capabilities that cannot be defined as part of a profile or those that need to be shared by different profiles. Examples of optional package include: The MMAPI (multimedia API) -provides support for streaming video and audio The WMA (wireless messaging API) - provides support for wireless message The FCA (File Access API) profile provides facilities to read and write files on devices that support them The K Virtual Machine The KVM is a Java virtual machine developed for small, resource constrained devices such as mobile phones, PDA s etc. The KVM implements the CLDC. Since the KVM is a C language implementation it can be ported easily to different types of platforms. KVM can not only run Java applications built for mobile devices (J2ME applications) but also support a superior user interface and off-line functionality during instances of intermittent wireless network connections. 2.2 Java Servlets Technology A Servlet may be defined as a Java program that runs typically on an HTTP server and responds to requests from clients. For example, a client may need information from a database; A Servlet can be written that receives the request from the client, retrieve and process the information requested from the database and send the results to the client. 6

13 2.2.1 HTTP Request for accessing a Servlet Hyper Text Transfer Protocol (HTTP) is a request-response oriented protocol. The service method of HttpServlet dispatches a request to different Java methods for different HTTP request methods. The recognized methods are GET, HEAD, PUT, POST, DELETE, OPTIONS and TRACE. Other methods return a Bad Request HTTP error. In particular we are interested in the HTTP GET request. The GET request expects the parameters "(HttpServletRequest req, HttpServletResponse res)". The request data is passed to the methods through the first argument of type HttpServletRequest. The response can be created with methods of the second argument of type HttpServletResponse. In our quiz application the Midlet uses the java Servlet to register students, verify username/password, display quiz questions and store quiz results. 2.3 Java Server Page (JSP) Java Server Pages is an extension of the Java Servlet technology. It allows for java code to be embedded in HTML pages. The java code is executed on the web server before being displayed to the user JSP Sessions A session is an object associated with a jsp page. Data can be put in the session and retrieved from it, much like a Hash table. In our Quiz Application the faculty enters the questions, choices and the correct choice in the text box provided and clicks the submit button. The submit button invokes a jsp page which gets the textbox values using the request.getparameter () and then writes it onto a session using the session.setattribute (). The contents are then retrieved from the session using the session.setattribute () method and then written onto the database file. 7

14 2.4 Apache Tomcat Server Apache Tomcat, a web container developed by the Apache Software Foundation implements the Servlet and the Java Server Pages (JSP) specifications from Sun Microsystems, creating an environment for Java code to run on a web server. It has tools for configuration and management but can also be configured by editing configuration files that are normally XML-formatted. Because Tomcat includes its own HTTP server internally, it is also considered a standalone web server. Tomcat comes with the Jasper compiler that compiles JSP s into Servlets and runs on any operating system that has a JVM. Tomcat can also function as an independent web server. Tomcat serves as an ideal standalone web server in high-traffic, high-availability environments. Our Quiz Application uses Apache Tomcat 4.1 to host the Servlets and the JSP s Key Features of Apache Tomcat 4.1: Implements the Servlet 2.3 and JSP 1.2 specifications Servlet container redesigned as Catalina JSP engine redesigned as Jasper Coyote connector Java Management Extensions (JMX), JSP and Struts-based administration 2.5 MySQL Server 5.0 MySQL, the most popular Open Source SQL database management system, is developed, distributed, and supported by MySQL AB Our quiz application uses MySQL database to store valid usernames/passwords, test questions, final test results of each student and to validate user choice 8

15 CHAPTER 3 QUIZ PRO 2006 SYSTEM ARCHITECTURE In theory, MIDP applications on wireless devices can directly communicate with backend databases using raw TCP/IP network sockets. However, the mobile application must then handle all database-dependent communication, resulting in an application that cannot be ported across different backend database servers. Further if the processing is done on the mobile device it becomes a burden for resource-constrained mobile devices, thus making the application inefficient and non-portable. In an optimal design the mobile application should handle only the interaction with the user and the entire processing must be done by the server. It is clear than we need a server-side layer between the databases and MIDP applications. J2EE (Java 2 Platform, Enterprise Edition) provides an excellent solution for a server-side middleware. Java Servlets can communicate with MIDP applications via the standard HTTP protocol; Java Servlets can also interact directly with databases through database-independent JDBC APIs or integrate with other J2EE components, such as Enterprise JavaBeans (EJB s). 3.1 Architecture Figure 2.0 shows the basic architecture discussed above. The MIDP application (in our case the quiz application) runs on the mobile devices. The Midlet communicates with the Servlets through the HTTP protocol. The Java Servlet then passes the Midlet request to a middle layer of application software and communicates with the database through a JDBC connection. Note: The Servlet needs to be first compiled and deployed on a standard HTTP web server such as Apache Tomcat Server Considering our Quiz Application as an example the QuizApplication Midlet communicates with the Servlets deployed on the Apache Tomcat Server 4.1 and accesses the MySQL 9

16 database tables through a JDBC Connection defined on the Servlet and returns the required result to the Midlet client via the Servlet. Mobile Device Mobile Device Mobile Device Mobile Device HTTP Request Java Servlets Apache Tomcat Server Local or Remote Method Calls EJB Container Or JDBC Methods Native Protocols and SQL Database Database Database Database Figure 2 Client Server Architecture of Quiz Pro

17 3.2 Data Flow between the various functional components Faculty enters questions, time of quiz and the total number of questions into database file SQL Database: The database contains the questions along with other tables for user authentication, user choice validation, result display etc. Java Servlet queries database and gets results Java Servlet running on Apache Tomcat Server Servlet returns result to midlet client Quiz Midlet accesses Java Servlet Quiz Midlet Java 2 Mobile Environment Students download QuizApplication.jar file into the mobile device Student Student Student Student Figure 3 Data flow between the various functional components 11

18 Quiz Pro 2006 software package consist of two interfaces: Faculty interface Student interface Faculty Interface The faculty is provided with a username/password to log onto the Quiz Pro 2006 faculty Admin Web page. The web page allows the faculty to view any of the registered student test results or post a new test. The username registered by the student from the mobile phone is used to view test score of the student. To create a new quiz the faculty enters a name and the last date of submission of the test/quiz. Then the quiz questions along with the correct choice of answer are entered one by one. Apache Tomcat Server 4.1 is used to host the faculty admin page and MySQL database is used to store the test questions and results. JSP technology is used to query the results from the database Student Interface The student needs to download the QuizPro.jar file into a java enabled mobile device (similar to downloading a game into the mobile). Once the application is successfully installed into the mobile phone the student registers with the faculty (enters a valid username/password to take the quiz). The application allows the student to take the quiz twice and the highest score of the two tests will be taken as the final score. The total time for taking the quiz and the number of questions is set by the faculty. Each question consists of 4 choices and the student enters a valid choice (between 1 and 4) in the textbox provided and clicks on the submit button. To move on to the next question the student clicks the continue button. Each correct answer carries 10 points and each wrong answer carries a negative 5 points. If a student clicks the continue button without clicking the submit button he loses the points awarded for that particular question. 12

19 Once the quiz is complete the results are displayed immediately. If the student is not satisfied with the results he could take the test once again. The combination of J2ME and Java Servlets technology ensures portability and allows the application to be run on more than one mobile device. 13

20 CHAPTER 4 PORTABILITY & DESIGN ISSUES IN DEVELOPING QUIZ PRO 2006 Some of the design issues in developing a mobile J2ME Application include: Limited screen size & input capabilities Limited processing power Short battery life Very small memory Limited persistent storage Limited networking capabilities high latency, low bandwidth & intermittent connection Some of the common portability issues in developing a J2ME Application may include The application size Intermittent network connections with lower bandwidth Since our Quiz Application involves database operation and a lot of user data processing the most important portability issue which we need to address is the application size. Making wireless applications smaller results in a number of benefits: Smaller applications download faster and thus more cheaply. They take less time to load and run; acceptable start-up time is crucial. The smaller each application is, the more applications users can store on their devices. 14

21 4.1 Use of Servlets to reduce application size In order to reduce the size of Quiz Pro 2006 to ensure the application is portable to most of the limited memory mobile devices all the computation and processing of user data along with complex calculations are performed using Java Servlets. This greatly reduces the processing overhead on the mobile device and drastically reduces the size of the program code. Now the Midlet simply acts as a graphical user interface and passes on the input to the Servlet running on the Tomcat server. It is the Servlet which does the actual processing of user data. For example the user enters the correct answer choice for each question and clicks the submit button. This invokes a Servlet which receives the user choice, queries the database table to verify if the selected choice matches with the actual correct choice to the question. If the entered choice matches with the actual choice in the database table the Servlet returns a Correct Answer message to the Midlet else it returns a Wrong Answer message. 4.2 Provision of Graphical and Non Graphical version To further enhance portability of the application two versions of the quiz program are available, the graphical version for devices with memory above 128KB and the text only version for devices with memory of 64KB or less. 4.3 Use of HTTP protocol to enhance portability Theoretically you may use either sockets or datagrams for remote database communication in the J2ME application if the MIDP device manufacturer supports them. But this again creates a portability issue since not all manufactures support socket and datagram communication in MIDP device. Since HTTPConnection is mandatory for all MIDP implementations our quiz program uses HTTPConnection class for all database operations Another advantage of using HTTP protocol in mobile device application development is that HTTP does not pose any problems through server firewalls. Because the server and 15

22 mobile client are mostly separated through a firewall, HTTP eliminates the need for any extra configuration effort. However one should be aware of the security risks that come along with any open HTTP connection to the outside world. 4.4 Use of High Level API The high-level API is designed for applications which run on MIDP devices where portability is important. To achieve portability, the API employs a high-level abstraction and provides little control over its look and feel. Interaction with components is encapsulated by the implementation and the application is not aware of such interactions. The main advantage of using High Level APIs is that the underlying implementation does the necessary adaptation to the device's hardware and native user interface style. The high-level API is implemented by classes that inherit from the Screen class. Since our quiz application is intended for students, our main objective is to achieve maximum portability across a number of mobile devices of different manufactures. Hence our application makes use of High Level API and does not use the less portable Low Level APIs 4.5 Preventing Networking Bottleneck To avoid potential deadlock, operations that may block, such as networking, was performed on a separate thread. For example every time a user clicks the submit button the Servlet is invoked using an http connection from the Midlet. This networking operation is performed on a new thread and not on the submit Commandaction () handler 4.6 Error Handling Server side error handling is extremely important to ensure that there the user is never left unaware of a server side exceptions. If a Java Servlet on a J2EE Application server cannot carry out a request from a Midlet client, the server needs to report this to the client. While within the Servlet it may use the Java exception-handling mechanism to deal with 16

23 errors internally, we cannot set up a try-catch block in the client code to directly catch exceptions thrown by the server. Hence an error reporting mechanism is required. In our application we have incorporated an error reporting mechanism which checks the HTTP status code and message on the client side to see if the communication with the server was successful or not. For example a status message of 200OK indicates success and the Servlet received the parameters sent along with the HTTP connection from the Midlet and a status code of 400(Unable to read parameters) or 500(Internal server error) indicates that there was an error processing the parameters sent from the Midlet. 4.7 Client side validation Validating inputs on the client side reduces the costs of calls to the server. Although not all information can be validated on the client, it is possible to minimize the information that must be validated on the server. For example in our application the Midlet throws an alert message if the user tries to click the login/register button with an empty username/password field. Another example of client side validation incorporated in our application is the Midlet throws an error message if the user tries to enter an alphabet as a question choice (this is implemented by using a numeric constraint on the textbox field) or leave the choice field empty and proceed to the next question (implemented by checking if the length of the data entered in the text field is not null) or enter an invalid choice (checking for the choice to be between 1 and 4). If the inputs pass these heuristics, the client passes them on to the server. The server then perform more complex validation such as checking if the username/password is valid or if the entered choice matches the correct choice to the question etc. Note: The reason to perform client-side input checking is to avoid unnecessary round trips to the server. The Java Servlet in our application still checks for invalid inputs, regardless of the client side validation. 17

24 4.8 Support for multiple users simultaneously The quiz application supports multiple users simultaneously which means any number of students can take the test simultaneously any time. 4.9 Midlet Security Security is an important factor to be considered when developing web-based applications. Our Quiz Application was developed strictly for internal use, so the level of security that is employed is low. Since our application is intended for student registered to the particular course client authentication is carried out using an application managed sign on, based on user registration. In other words the MIDP client sends its credentials (such as a login and password combination) to a J2EE Servlet application, and the application verifies these credentials, using a MySQL database 18

25 CHAPTER 5 DEPLOYING THE WIRELESS MOBILE APPLICATION ON A PHYSICAL MOBILE DEVICE The following steps need to be followed to deploy and test the application on a real physical device: 1. Upload your application files (JAD and JAR) to a remote web server. In our case QuizApplication.jad and QuizApplication.jar files are both uploaded onto the Apache Tomcat Server root directory 2. Reconfigure the web server so that it recognizes JAD and JAR files: a. For the JAD file type, set the file extension to.jad and the MIME type to text/vnd.sun.j2me.app-descriptor. b. For the JAR file type, set the file extension to.jar and the MIME type to application/java-archive. c. A typical web.xml file for the Tomcat Server to recognize the.jar and.jad files would be as follows: <mime-mapping> <extension>jad</extension> <mime-type>text/vnd.sun.j2me.app-descriptor</mime-type> </mime-mapping> <mime-mapping> <extension>jar</extension> <mime-type>application/java-archive</mime-type> </mime-mapping> 3. Change your JAD file's MIDlet-Jar-URL property to specify the URL of your JAR file In our case the following code needs to be added to the MIDlet-Jar-URL property MIDlet-Jar-URL: To verify if the application was deployed correctly, open an ordinary web browser and enter the JAD file's URL. The J2ME Wireless Toolkit's default emulator should appear and the remotely deployed application should run in it. J2ME-enabled mobile phones include a Java Application Manager (JAM) responsible for downloading, installing, and configuring J2ME applications. The Sun J2ME Wireless Toolkit includes a sample JAM which emulates the exact installation process executed on a real physical mobile device. 19

26 5.1 Installing QuizApplication.jar using a sample JAM in Sun Java Wireless Toolkit Type Emulator Xjam from C:\WTK23\bin directory 2. Type the file URL in the mobile web browser 20

27 3. Select QuizApplication.jar from the web page and click install 4. Once the application has been installed successfully, QuizApplication is displayed along with the other installed applications. 5. To run the application click the launch from the Menu 21

28 CHAPTER 6 FUTURE ENHANCEMENT 6.1 Providing Session Handling using Cookies In our implementation if a user exits from the quiz program without completing the quiz he/she does not get the full credit. By implanting session management using cookies we could actually save the current session when the user terminates and when the user logs in again he/she can resume from the place where he/she left before Implementation of Cookie session management When the Midlet first makes a HTTP request to the Servlet, the Servlet generates a unique client ID (simply a random number). This ID will be sent back to the Midlet as a cookie. The Midlet will store this value in a record store. All future requests from the Midlet to the Servlet will be accompanied by the client ID. When the Servlet recognizes that the client (Midlet) sent a cookie, it will simply return the value of the cookie. Once the Midlet has stored the ID in the record store, you can shutdown and restart the Midlet and reconnect with the Servlet, which will (uniquely) identify the Midlet by the value of the cookie. This could be extended to have the Servlet store the client ID in a database, along with additional information about the client. 6.2 Improving MIDP Security J2EE application servers and many MIDP devices support HTTP over Secure Sockets Layer (SSL). The use of HTTPS for communication with the server adds more security to the application 22

29 CHAPTER 7 QUIZ PRO 2006 SCREENSHOTS Faculty Login Main Menu Screen 23

30 Quiz Question Screen 24

31 Student Result view Student Test Results 25

32 Apache Tomcat Running MySQL Database 26

33 Student login Invalid Login Error Message 27

34 New User Registration Successful User Registration 28

35 Previous Test Results Quiz Rules 29

36 Quiz Timed Out Results Quiz Screen 30

37 CHAPTER 8 CONCLUSION A J2ME based quiz application package consisting of faculty and student interface was developed, implemented and successfully tested. Various portability and design issues were addressed. Some of the solutions implemented in Quiz Pro 2006, to enhance portability include the use of Servlets for user input processing, provision of graphical and non graphical versions of Quiz Pro 2006, use of HTTP protocol supported by all mobile devices, and the use of High Level API classes as against the Low Level API to enhance portability. Also various other design issues such as preventing networking bottleneck, proper error handling, security features, client side validations and support for multiple clients simultaneously were addressed. Future enhancements may involve providing session handling using cookies and URL rewriting and improving MIDP security 31

38 BIBLIOGRAPHY 1. Software Portability, Jim Mooney 2. J2ME Complete Reference, James Keogh 3. Beginning J2ME: From Novice to Professional, Jonathan Knudsen Sing Li 4. J2ME: Introduction, Configurations and Profiles, Urs Steiner 5. Surviving Java for Mobiles, Dmitry S. Kochnev and Andrey A. Terekhov 6. Take the High Road when Creating MIDP User Interfaces, David Hemphill 7. Slimming Wireless Java Applications, Qusay H. Mahmoud 8. Designing Wireless Clients for Enterprise Applications with Java Technology 9. What's J2ME?, Daniel A. Tauber Using a Java Servlet and cookies with a Midlet Extending J2EE for Mobile Application Development, Jeffrey M. Capone Network Programming with J2ME Wireless Devices, Yu Feng java/features/j2me_http.phtml 13. MIDP APIs for Wireless Applications java.sun.com/products/midp/midp-wirelessapps-wp.pdf 14. J2ME Connected Applications, Santanu Dutt ftpna2.bea.com/pub/downloads/usergrouppresentations/ 2004PartnerPresos/Others/ _j2me.pdf 15. Build database-powered mobile applications on the Java platform, Michael J Yuan Ju Long 32

39 INDEX A Apache Tomcat Server C Connected Device Configuration (CDC) Connected Limited Device Configuration (CLDC) Client side validation Configurations Cookie session management E Error Handling F Faculty Interface FCA (File Access API) Foundation Profiles H High Level API HTTP protocol HTTP Request HttpServletRequest HttpServletResponse N Networking Bottleneck O Optional Package Profiles P PDA Profile Portability Profiles R request.getparameter() RMI Profile S Servlets session.getattribute() session.setattribute(). Student Interface W WMA (wireless messaging API) J J2EE (Java 2 Platform, Enterprise Edition) Java 2 Micro Edition (J2ME) Java Servlets Page (JSP) Java Servlets Technology JDBC Connection JSP Sessions K K Virtual Machine M Mobile Information Device Profile (MIDP) Midlet Security MMAPI (multimedia API) 33