1 of 38

Final Presentation.

Group 4

2 of 38

Garçon.

Sarah Azody, James Gliwa, Steve Lin, Kevin Rowland, Edward Schembor

Group 4

3 of 38

Garçon

Sarah Azody, James Gliwa, Steve Lin, Kevin Rowland, Edward Schembor

Group 4

4 of 38

Motivation

5 of 38

6 of 38

Garçon GUI

7 of 38

splash screen

8 of 38

Login

9 of 38

Sign Up

10 of 38

Task List

Search Filter

11 of 38

View A Task

Price

Name

Description

Deadline

Creator’’s Rating

Run the Task

12 of 38

Add a Task

13 of 38

Profile

14 of 38

Finish a Task

15 of 38

General Architecture Overview

16 of 38

Activity 1

Activity 2

Activity 3

Model

(singleton class)

Server Controller

Database Service

Client Side

Server Side

Server Controller

Request Handler

17 of 38

Activity 1

Activity 2

Activity 3

Model

(singleton class)

To server

18 of 38

Activity 1

Activity 2

Activity 3

Model

(singleton class)

To server

Request

Response

19 of 38

Activity 1

Activity 2

Activity 3

Model

(singleton class)

Server Controller

Database Service

Client Side

Server Side

Server Controller

Request Handler

20 of 38

Server Controller

Database Service

Server Controller

Request Handler

To client

To database

21 of 38

Unique and core aspects

22 of 38

Using a Common Project...

Shared between the client and server projects
Holds all of the requests and responses
Interfaces for user and profile

23 of 38

TaskList Adapter

24 of 38

TaskList Adapter

Could’ve used a trie here but wouldn’t really affect performance much so we chose the simple way.

25 of 38

Using the Singleton Design Pattern

GarçonModel�

The central point of communication between the Android app and the Server�
Needed to hold a TCP connection that persisted throughout the lifetime of the app�
We added a listener to the Kryonet Client object that updates the model based on whatever Response object was received from the Server

26 of 38

Using the Singleton Design Pattern

When instantiating the model for the first time, a new Kryonet Client object must be created and stored in the model. The Client object can then be used by subsequent Android Activities to send Requests to the Server.

27 of 38

Using the Singleton Design Pattern

Cast the Response, unwrap it, and store its data in the model.

Set a response flag high so the app knows it can grab updated data from the model

28 of 38

Activity 1

Activity 2

Activity 3

Model

(singleton class)

Server Controller

Database Service

Client Side

Server Side

Server Controller

Request Handler

29 of 38

30 of 38

31 of 38

To go into further details.

Server controller is essentially just a static main method to hold the port open and listening for new connections. Kryonet is responsible for delegating new threads and handling incoming connections.

Request handler is the hub, it decides if an object is a Request, and then decide which request. It basically consists of a large if else if block that will take a request and apply the proper logic to it.

DAO Service is a facade for all the DAO objects. The DAO objects are made to interact with the tables that holds our data, and DAO service abstracts out some of the dependencies between them.

As an example, say we get the RegisterUserRequest. The server controller catches it from the client, and pass it to request handler. Request handler then calls the DAOService’s corresponding add user method, which then creates a transaction using the UserDAO and ProfileDAO to add a user and add a profile. To a large extent, the DAO object methods create a corresponding query to interact with the database, so DAOService’s job is to deal with transactions.

Or for another example, FinishTaskRequest. Again the controller catches it, pass it to the handler, checks that the corresponding user is actually running the task using RunningDAO. If so, removes from the running, copies the task from the Task table into Finished Task table, and deletes it from the Task. The idea is that if any of this secquence that forms the transaction fails, we roll back the changes.

32 of 38

Technical Challenges

General Kryonet Issues

Issue: Setting it up, TCP Ping class, lack of documentation, lack of experience with server programming
Fix: Example code, StackOverflow, Professor Palmer

33 of 38

Technical Challenges

Viewing other profiles:

Issue: Viewing other users’ profiles resulted in the myProfile field in our model being overwritten with someone else’s profile. The next time we went to see our Profile, it was showing the name of some other user! Should we create a new field for a currentlyViewingProfile?
Fix: We realized that you could only view one Profile at a time due to the structure of the app, so it would be fine for the Model to only hold one Profile field. If you view someone else’s Profile, that Profile gets saved in the Model. Then, the next time you try to view your own profile, the Model simply has to send a GetProfileRequest to the Server so that the Model can be loaded with all of your information again!

34 of 38

Technical Challenges

Intent Retrieval from onItemClickListener:

Issue: getIntent() retrieved a different intent than the one we called in startActivity()
Fix: We added a currently selected task field to the model that gets overwritten with the item that is selected in the listener. Then we just access the field from the model in the next activity instead of passing it. Not ideal but it works.

35 of 38

Defensive programming

Check connection on splash screen and do not allow users to continue until they are connected to the server
Check to see the user has a task before sending a finish task request
Regular Expression to make sure e-mail is of proper format when registering
Check if the deadline when setting a task is in the past
Check if the price on a task is unreasonably high (> $999)
The server only recognizes specific requests and will send an error response to the client if any other type of message is received

36 of 38

Demonstration.

37 of 38

Extended Features

38 of 38

Venmo Integration
Maps Integration
Filterable Tasks
Messaging
Server security
Profile pictures