eateries @ ait an android application for ait community

7/31/2019 Eateries @ AIT an Android Application for AIT Community

1/7

Eateries @ AIT An Android Application for AIT

Community.

Akilan Thangarajah and Nimit TuksavitayapongMicroelectronics and Embedded Systems

School of Engineering and Technology

Asian Institute of Technology, Bangkok.

Email: [email protected], [email protected]

AbstractE@A2- an Android application has been imple-mented for finding the best desired meal at AIT. It is a betaversion, 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. INTRODUCTION

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 first two are necessarily android based client

applications. This application allows the AIT community to

browse around the database and to find availability of their

desired meal and its details such as restaurant name, ingredi-

ents, price, and location.

A. Problem Statement

There are more than five 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

finding 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 efficient and never quarantined

them to reach an eatery to find his/her desired meal.

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 finding foods at AIT.

The rest of this paper has been organized into The Design,

Discussion, Conclusion, and Reference.

Fig. 1. The overall system architecture.

I I . THE DESIGN

This section describes software design with the help ofblock diagrams (BD), flowcharts, and screen shots when it is

relevant. The system design of the E@A2 is fundamentally a

Client-Sever based architecture as described by figure 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, filters 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


2/7

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 flowcharts.

Figure 3 shows the main functional flow of the both-

Eatery 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 data-

interchange format.Once the JSON data correctly extracted the

relevant database contents is gathered and grouped by using

.getJSONObject()..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.

Figure 5 shows the operational flow as a continuation from

the flow which is common to Eatery and Customer sides

shown in figure 3. As the user presses menu of the android

mobile the action starts. Whereby, there are five actions can

Fig. 3. Software design flowchart of E@A2.

Fig. 4. Flowchart of the eatery side application in E@A2.

be taken place depends on the chosen menu option (get a list

view, get a map of the eateries, perform search operation,


3/7

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 flow starting at the menu

actions similar to the customer side flow described earlier.

However, here the menu options and the relevant operations

differ from the customer side application. Whereby, there five

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.

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 figure. 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 baseddatabase (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, find

paths, refresh data whereby, the search operation provide

customers to search by type of cuisines, meal name, and price.

Fig. 6. The main UI of eatery side application.

The user interfaces (UI) of eatery side are given in sequence

of figures 6 - 9. Figure 6 is first 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 byinvoking 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 figure 13 and the edit operation

widow is shown in figure 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 figures

10 - 16. Figure 10 shows the first 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


4/7

Fig. 7. The add new record UI of eatery side application.

Fig. 8. The search record UI of eatery side application.

it with the dialog window titled by the name of the meal

(refer figure 11). This dialog box provides an option for the

user to find 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. 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 filter 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 figure 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 (referfigure 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 fields - id, name, type, detail, price. The fields

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 importantfeatures available at the free web hosting site and the file

manager which contains necessary files and folders of this

project respectively. Figure 18 shows the sample data recoded

in the IDB.

III. DISCUSSION

Although the concept of this E@A2 is very clear and

simple implementation has complexity as it has to deal


5/7

Fig. 10. Welcome Screen of the customer side android application.

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

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 configured) connectivity was created

Fig. 12. Full list view.

Fig. 13. List of main searchable categories.

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


6/7

Fig. 14. Search result for the chosen category-Type.

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

Fig. 16. The alert dialog during refreshing data.

Fig. 17. The database fields.

Fig. 18. The sample data at the IDB.

has been implemented successfully. However, there are still

few more implementations to be done such as direct data

modification 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 finding path, location of the eateries with

the help of Google mapping and GPS functions.


7/7

Fig. 19. The file manager window at the server.

Fig. 20. The important features at the free hosting website.

IV. CONCLUSION

E@A2 is a must needed android application for finding

a desired meal at AIT in a easy-pecy way. However, there

are few corners identified 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.

REFERENCES

[1] Mongkol E.Android Systems Lecture Notes, availa ble athttp://esl.ait.ac.th/. (accessed 15.02-20.05.2012).

[2] Android Developers, available at http://developer.android.com. (accessed15.05-21.05.2012).

[3] W. F. Ableson, R. Sen, C. King, C. E. Ortiz, Android in Action, ManningPublications Co., 3rd edition, 2011

eateries @ ait an android application for ait community

Documents