App Framework
Application Overview¶
Our MyCanteed@SUTD app is supposed to be able to:
P0 Features:¶
- Set up the information regarding the stalls in the canteen in a database.
- Be able to show this information to our users. This way, users can plan when to visit the canteen (lets say a stall is closed/they don't have an item on the menu that they want etc.)
- Users can indicate when they plan to visit a particular stall. Stall owners can prepare food accordingly (to help reduce waste)
P1 Features:¶
- Allow users to leave comments on a stall's page
- Allow users to request certain food items
The Different Components for The App¶
The app will consist of 3 main components:
The User Interface¶
This will define certain activities. Some activities that we definitely will need to have are:
- Log-In: Self explanatory, we should start the users out here. Move to Main Activity on login.
- Main Activity: This is the activity that lets you see a list of all stalls and their status (open, closes at .../closed, opens at .../etc.)
- Stall Info Activity: Once you click a stall's name in the main activity, it passes the info about which stall's information to display to this activity. This is the activity which will display all the information related to the stall. In this activity, an option should be given to the user to indicate if they will be eating at the stall at some point later (for the stall owners to be able to see)
This is not an exhaustive list, there may be more activities that we can add as per needed
The UI should define:
- All of the actvities that the app needs to have
- The layouts of each activity (the buttons, text views, image views, etc.) in the XML format (so all the different attributes like alignment and position on screen etc.)
- The default values for all views etc.
- A brief description of what each component in all the views does.
- For a text view, describe what text it will show.
- For an image view, describe the image that it needs to show.
- For a button, describe what it does when clicked.
The Database¶
Using Firebase, we want to store the relevant information related to our users. A general outline of what will need to be done:
- The specifics of how to set up and use a firebase instance needs to be looked into. Refer to the Application Database Model section for details on what information our app will need to store. Do note that this is just tentative, and if we decide to add/remove certain features then relevant data can be added/removed as well. This ultimately depends on the UI design, and what info our app wishes to display to the users.
- A class with relevant functions to get/post data need to be created (an API of sorts). These functions should be able to take in a parameter for the stall ID (and potentially other relevant parameters) whoes data needs to be retrieved/modified.
- Data related to a stall can be retrieved by anyone, but some form of authorisation will be required to modfiy it (eg. anyone can view the menu, but only the actual stall owner should be able to edit!)
The Backend¶
The backend is what will connect the user interface and the database of the app together and make it function in general. The outline of what needs to be done for this:
- Use the specification from the UI design (in terms of the interaction behaviours of each component in all the activities) and implement that behaviour using action listeners and proper java code.
- Using the functions given by the database API, retrieve and set the data in the relevant views to be displayed to the user.
Documentation¶
The above process of coming up with the user interface, setting up firebase and creating the backend should be documented, showing why certain design choices were made. This is mainly useful for our report and maybe final presentation
The Plan of Action¶
The UI design step must be done before anything else, so that the people working on the database are able to set up the database in a manner that can cater to the specific requirements set by the UI (in terms of what needs to be displayed on a given screen). Similarly, the backend implementation relies on the UI specification for what the app should be able to do/functions of each thing in the app.
Do note that the specific colours/placement/alignment of UI elements may change even after work has begun on the database/backend. This is not an issue, and hence the UI designer does not need to be very particular about these things to start with. Just an overall this thing exists on this page and displays xxx/does yyy will allow the backend/database people to start their work. Specifics of colour/alignment is unrelated to that!
Additionally, it is okay if additional elements are added to the UI at a later time. Our app should be built in a modular fashion such that adding/removing individual components is easy (and doesn't cascade-break a thousand other things. If this is the case, then the app design is bad!)
Once the basic UI specification is done, the database and backend people can get to work creating the functionalities for all the mentioned components. The backend does require access to some functions from the database to be able to fully function, but most of it should be implementable without that finished. The main requirement is for the backend/database designers to coordinate such that the data being shared between them follows a format that has been agreed upon by both.
This will help with consistency and save us the trouble of having to rewrite one or the other component in order to make sure that the data format is the same
Current Task Delegations¶
Based on our previous discussions about the project, the following is the tentative task assignment
- User Inferface: Eliana
- Database: Ryan, Erick, Andre
- Backend: Divy
- Video: Zach, Ryan, Andre
- Report: Divy, Zach, Wanglin
- Poster: Eliana
Application Database Model¶
This is a tentative data model for our app. (This is mostly the same as what we discussed last time in person)
Enums¶
1. StaffType¶
1 2 3 4 5 6 |
|
2. CustomerType¶
1 2 3 4 |
|
2. Day¶
1 2 3 4 5 6 7 8 9 |
|
Classes¶
1. User¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
2. Customer¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
3. Staff¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
4. Menu¶
1 2 3 4 5 6 7 8 9 10 11 |
|
5. Stall¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|