Welcome to the documentation pages of the Let's Cook App!
You can find here details about the the Let's Cook App, from a high-level vision to low-level implementation decisions, a kind of Software Development Report, organized by type of activities:
Contributions are expected to be made exclusively by the initial team, but we may open them to the community, after the course, in all areas and topics: requirements, technologies, development, experimentation, testing, etc.
Please contact us!
Thank you!
- Allan Santos (up202109243)
- Filipe Gaio (up202204985)
- Henrique Fernandes (up202204988)
- José Sousa (up202208817)
- Leandro Martins (up202208001)
Final Grade: 18.8/20
Let's Cook is a revolutionary mobile application designed to connect students within FEUP to buy and sell homemade meals, reducing food waste while fostering a sense of community and culinary exploration. Targeted specifically towards students, Let's Cook addresses the common issue of excess food and tight budgets by providing a platform for convenient and sustainable food sharing.
- Sign In Page and Sign Up Page
- Home Page
- Menu for navigation
- User profile
- Search bar
- Scrolldown list of offers with an appealing photo, price, rating, chef
- Chef Page photo, description, rating
- About Page
Have you ever been told that you cook well? Would you like to earn extra money doing what you love? Or are you simply tired of eating in the canteen and want affordable prices and homemade food? That's Let's Cook. Let's Cook connects students who have a passion for cooking with other students who are looking for cheap home-cooked meals. It's a simple and sustainable solution to excess food and tight budgets. Our target audience are FEUP students who want to buy or sell homemade meals. Whether you're a culinary enthusiast or just looking for an affordable meal, Let's Cook has something for everyone. While there are other food delivery apps, they don't focus on homemade food, and Let's Cook fills that unique niche. What sets us apart is our community-focused approach. It's not just a food delivery service, it's a platform for students to meet each other and enjoy delicious home-cooked meals. Let's revolutionize the future of campus dining together!
A user is a student who's either buying or selling food. Each user has a profile with attributes like their name, ID, if they're active or not, and where they are on campus. Plus, they can share a bit about themselves, their food tastes, and what they're selling or looking to buy.
A seller is typically a university student eager to share their culinary skills and earn some extra money. Each seller has in addition to the User fields, a sellerId, a deliverRadius (where they deliver food), their average rating, their specialties, and their sales record. After getting accepted he can post a variety of dishes for sale,
A buyer is essentially a university student seeking convenient and tasty food options within their campus community. Each buyer has in addition to the User fields, a BuyerId and its BuyingHistory. He can also follow his favorite sellers.
An admin plays a crucial role in ensuring smooth operations and maintaining a safe and enjoyable experience for all users. Admins are responsible for managing the platform, monitoring user activity, and addressing any issues or concerns that may arise. They have a GodToken which gives them special privileges like being able to ban any user and allowing users to sell products.
A dish is the main component of the app. It is described by its name, ingredients, calories and if it is available at the moment. Each dish may belong to different diets.
Each diet is represented by its name and by a description which may contain specific information about such diet like the foods that are allowed, where it originates from and potential benefits it has.
For us to have a good organization of our code for easier maintenance, we divided our project into the following sections:
-
Let’s Cook: This package is the global package for our mobile application, it has the other packages of our system.
-
Let’s Cook UI: This package is focused on the frontend of our application, it includes the components of the user interface.
-
Let’s Cook Business Logic: This is the package that includes the user business logic, it also includes API calls to the backend of the application.
-
Let’s Cook Database Schema: This package contains the local database logic and API.
-
External Services: This package is the global package for external services our application depends on. It includes the other logical packages of our system.
Our app's physical architecture comprises the user device housing the frontend application and local storage, along with external services provided by Firebase. These services include hosting a NoSQL database, authentication, and storage functionalities.
We developed the following features for the prototype:
We developed a navigation bar that allows the user to navigate between different pages.
We styled different widgets using material design and in some cases we used custom seeds for the color scheme
 |
 |
|---|---|
 |
 |
We developed Login/Register functionality using Firebase Auth. The user is able to register using a Google account or an email/password.
 |
 |
|---|
We built a custom database with Firebase Firestore that allows us to save data about users, dishes, and others and automatically sync the data with each client.
The goal of this sprint is to implement a basic working app with backend integration and some base documentation.
End of the sprint:
- Everyone contributed to the project with different parts, like UML diagrams, design or code.
- We managed to get a basic prototype working.
- Sometimes the communication wasn't the best, for example there were some unclear requirements that led to misunderstandings in the implementation.
- Every change will require a new branch, even if it is a small change.
- Each pull request will require a good description of what changed and why and at least 2 reviews will be required before merging.
- Each pull request review must be detailed, and if there are any issues, they must be resolved before approving the changes.
- Everyone needs to have an idea of what others are working on, in order to facilitate the communication.
The goal of this sprint is to implement the core functionalities of the app.
Start of the sprint:
End of the sprint:
- Everyone contributed to the project, so we managed to implement some of the core functionalities of the app.
- There was a difference in the amount of work each person did.
- The issues with higher complexity will be assigned to small teams of 2-3 members instead of a single person.
- Only implement new features when the already implemented ones are finalized, because currently there are features whose design or functionality is not final.
- Whoever implements a new feature is also responsible for writing tests for that feature.
The goal of this sprint is to improve what we already have and implement the remaining of the key features.
Start of the sprint:
End of the sprint:
- We implemented the most important features.
- Some issues took more time than expected to get done. Our communication could be better
- We are going to start testing more before merging and for harder tasks we will start developing them in smaller groups rather than individually
The goal of this sprint is to improve the user experience and the UI.
Start of the sprint:
End of the sprint:
- We implemented all the features required to have a fully functional app.
- There were some features we wanted to implement that, were not implemented due to the lack of time.
This marks the end of our project, but we are committed to continuing our work on this app. Our goal is to eventually bring this app to the market, where we believe can make a significant impact. The lessons we've learned and the progress we've made during this project will serve as a strong foundation for our future efforts.