Eateries @ AIT An Android Application for AIT Community.

Akilan Thangarajah and Nimit Tuksavitayapong

Microelectronics and Embedded Systems School of Engineering and Technology Asian Institute of Technology, Bangkok. Email: st113125@ait.ac.th, st112582@ait.ac.th

AbstractE@A2- an Android application has been implemented for nding the best desired meal at AIT. It is a beta version, expected to under go further development in the future. Index TermsJSON - JavaScript Object Notation. IDB Internet Based Database, LDB - Local Based Database, UI User Interface, JDBC - Java Database Connectivity.

I. I NTRODUCTION This paper presents the design and features of an Android application named E@A2. The E@A2 stands for Eateries At AIT an Android Application. E@A2 contains three sets of major software components namely Eateries side application, Customer side application, Server management applications among them the rst two are necessarily android based client applications. This application allows the AIT community to browse around the database and to nd availability of their desired meal and its details such as restaurant name, ingredients, price, and location. A. Problem Statement There are more than ve restaurants/ food courts such as Sodexo Food Court, Snack Bar Food Service, Vietnamese Restaurant, and Thai Food Stall available in Asian Institute of Technology (AIT). However, there is no convenience way of nding out the available food items for a particular meal time (i.e. breakfast, lunch, tea time, or dinner). In such situation, the students, faculty staffs, and others have to physically reach those eateries to check what food/meal is available at their meal time. This is not efcient and never quarantined them to reach an eatery to nd his/her desired meal.

Fig. 1.

The overall system architecture.

II. T HE D ESIGN This section describes software design with the help of block diagrams (BD), owcharts, and screen shots when it is relevant. The system design of the E@A2 is fundamentally a Client-Sever based architecture as described by gure 1. The client side in general has two interfaces one for eateries and another for customers while server is a remote database as shown in 2. General features of the components are described below. Database (DB): It is an Internet based database (IDB) which contains all the relevant records such as meal list, price, and respective eatery information. It functions as the back-born of the application to interface the eatery and customer side user interfaces (UI). Eatery Interface (EI): It is a user interface for adding, editing, deleting the meal lists from the IDB. Customer Interface (CI): It is a user interface for searching and viewing. It searches data from the IDB, lters it and displays it on the android mobile phone. A. Software Design The software design of the system mainly involves with HttpURLConnection, Android intents, activities, dialogs and

B. Proposed Solution As a solution to the above problem statement an an Internet based android application is proposed so that it can ease burden process of nding foods at AIT. The rest of this paper has been organized into The Design, Discussion, Conclusion, and Reference.

Fig. 2.

The clients in E@A2.

views, sqlite, PHP application, and a third party FTP client including the website- http://sql10.000webhost.com which offers free web hosting facilities. The HttpURLConnection is one of most important methods employed in this application. It provides the bridging channel between the clients and the INTERNET based database (IDB). The Android intents, activities, dialogs, views, etc. are used to ensure a friendly interface for users to deal with the received data from the IDB where a local database (LDB) is created based on sqlite for off-line processing. The PHP application and FTP clients play a vital role in this application. The PHP application provides an essential interface which allows the users to access the IDB while the FTP client is used to post the PHP application at the sever hosting website. Figures 3 - 5 describe the Software design of E@A2 by means of a owcharts. Figure 3 shows the main functional ow of the bothEatery side and Customer side applications. At the time of booting the application an httpConnection method is invoked to get the connectivity with the sever. When the network connection is established the JSON is extracted from the httpConection response as it is not pure JSON format. The response from the httpConnection response always a mixed data of XML and JSON format. JSON stands for JavaScript Object Notation, is a lightweight datainterchange format.Once the JSON data correctly extracted the relevant database contents is gathered and grouped by using <jsonarrayname>.getJSONObject(<index>).<getmethod>. Then the gathered and grouped data is used to update a locally maintained data base for further actions. From this stage onwards Eatery side and Customer side application differs in terms of the operations performed at their applications.
Fig. 4.

Fig. 3.

Software design owchart of E@A2.

Flowchart of the eatery side application in E@A2.

Figure 5 shows the operational ow as a continuation from the ow which is common to Eatery and Customer sides shown in gure 3. As the user presses menu of the android mobile the action starts. Whereby, there are ve actions can

be taken place depends on the chosen menu option (get a list view, get a map of the eateries, perform search operation,

Fig. 6.

The main UI of eatery side application.

Fig. 5.

Flowchart of the customer side application in E@A2.

refreshing for synchronizing LDB and IDB, or Exit from the application) by the user. Figure 4 describes the functional ow starting at the menu actions similar to the customer side ow described earlier. However, here the menu options and the relevant operations differ from the customer side application. Whereby, there ve actions- Add, Edit, Search, Delete, or Exit can be performed. The Add, Edit, Search and Delete operations involve with the IDB and their operations are self explanatory as their names.

The user interfaces (UI) of eatery side are given in sequence of gures 6 - 9. Figure 6 is rst screen of the application. It provides minimal information of available records in the IDB via a list view and menu bar options if user presses menu of android mobile device. Figure 8 describes the UI for adding/inserting a new record to the IDB whereby the user can provide a name of the meal, type of the meal by choosing a country name from the drop-down spinner, short description of meal, price, and/or picture of the meal by invoking take picture action by clicking the camera action. Once he/she has done the earlier processes then the data can be uploaded to the IDB by clicking the Submit button or the window can be exited by clicking the Back to Menu button anytime. However, the image capturing feature will be implemented in the future version of E@A2. The edit operation is a sequential involving a search operation followed by updating the desired records. UI of the search operation is shown in gure 13 and the edit operation widow is shown in gure 9. Note that edit operation and add new record operation widows are essentially similar kind. The UI of the customer side are given in sequence of gures 10 - 16. Figure 10 shows the rst screen of the customer side UI where the menu of the phone has been invoked to bring up the bottom menus such as Full list, Search, Map, Refresh, and Exit for the users further operations. Figure 12 shows the data viewing features where the application only displays the brief detail. However, click on a desired item will bring up full detail about the item such as picture of the meal, restaurant name, brief description of the meal, and price of

B. Screen of the Clients and Description The client side of the system consists of tow parties - The Eateries and Customers as shown in the gure. Each parties have different android application which provide necessary functionalities relevant to their purpose. The application at Eateries provides the owners to access the INTERNET based database (IDB), upload new entires, modify/delete existing entries, and view them. On the other hand, the application at Customers provides the users to access the IDB, view the information about the eatery records as that is the only they necessarily need. However, the both side viewing functionality provides very handy operations like search, nd paths, refresh data whereby, the search operation provide customers to search by type of cuisines, meal name, and price.

Fig. 7.

The add new record UI of eatery side application.

Fig. 9.

The edit record UI of eatery side application.

is clicked. It provides a spinner list where user can opt for a desired option on which he/she wants to lter out the data. When an option is selected a list view will be generated for user to go for searching a desired item. For example gure 14 shows when user has chosen Type as the base category of his/her searching argument. Thus, only the type of cuisines available at various eateries at AIT. Then, by clicking(long) on a desired cuisine it will bring up a list of the particular cuisine only (refer gure 15). Figure 16 show the alert dialog which informs the user that it is refreshing the data and requests for patience. C. Server The server hosted from the website http://sql10.000webhost.com consists of two components - MySQL database and a PHP application. The database at the host has a table called Food table which contains the following elds - id, name, type, detail, price. The elds in the database table is shown in 17. The PHP application has the algorithm to mange the database (refer appendix for the full php script). Figures 20 and ?? show the important features available at the free web hosting site and the le manager which contains necessary les and folders of this project respectively. Figure 18 shows the sample data recoded in the IDB. III. D ISCUSSION Although the concept of this E@A2 is very clear and simple implementation has complexity as it has to deal

Fig. 8.

The search record UI of eatery side application.

it with the dialog window titled by the name of the meal (refer gure 11). This dialog box provides an option for the user to nd the place of the restaurant my google mapping feature. However, it will be available in the next version of this application. Figure 13 shows the UI when search option at the menu

Fig. 10.

Welcome Screen of the customer side android application.

Fig. 12.

Full list view.

Fig. 11. Full detail dialog window when the item-Sushi Vocabulary was clicked from list view.

Fig. 13.

List of main searchable categories.

with IDB from an android application. Creating a proper communication channel to the IDB created lot of hindrances during this project. Initially, a JDBC (an additional package had to be download and congured) connectivity was created

and tested to access a LDB. However, it only functioned with the LDB not with the IDB. Then, the android stand httpconnection was employed for the task. Fundamentally, it gave stable connectivity to the IDB. However, there was an issue arose in reading necessary data from the IDB as the

Fig. 14.

Search result for the chosen category-Type.

Fig. 16.

The alert dialog during refreshing data.

Fig. 17.

The database elds.

Fig. 18.

The sample data at the IDB.

Fig. 15.

Search result for the chosen cuisine.

response from the server via this connection was mixed with XML and JSON. Though the solution was simple, reaching to it took some valuable human hours. The fundamental required functions of the application

has been implemented successfully. However, there are still few more implementations to be done such as direct data modication at the IDB from android, uploading the image of a meal by taking the picture from the android devices built in camera. These features will be available in the next version of E@A2 including nding path, location of the eateries with the help of Google mapping and GPS functions.

Fig. 19.

The le manager window at the server.

Fig. 20.

The important features at the free hosting website.

IV. C ONCLUSION E@A2 is a must needed android application for nding a desired meal at AIT in a easy-pecy way. However, there are few corners identied to be implemented or improved in the future versions of this application. The learning process during this project was immense and it gave a good chance for self evaluation and to see the real demand of learning the course Android Systems: AT81.9015. R EFERENCES
[1] Mongkol E.Android Systems Lecture Notes, http://esl.ait.ac.th/. (accessed 15.02-20.05.2012). available at

[2] Android Developers, available at http://developer.android.com. (accessed 15.05-21.05.2012). [3] W. F. Ableson, R. Sen, C. King, C. E. Ortiz, Android in Action, Manning Publications Co., 3rd edition, 2011