Building BiteBook - an Android food diary app

An Android app that helps you answer: "Where should we eat?"

Friend: What do you wanna eat?
You: I don't know. You decide.
Friend: Idk either. You got any cravings?
You: ¯\_(ツ)_/¯ idk bro

Man, this is hard, you think to yourself. Why is it so hard to decide?

I've lived here my whole life. I've eaten at hundreds, maybe even thousands of places here.

I should be able to think of something.

“Where do you want to eat?” is a question everyone has undoubtedly been asked countless times. Sometimes, the answer is trivial — in school, options are limited and its easy enough to arrive at an answer. But start planning for dates, special occasions, and this question quickly becomes not so simple.

Current solutions are clunky and unintuitive.

Searching “Food near me” on Google

• Have to trust opinions of others
• Usually suggest the same few things
• Not built with food in mind

Food blogs

• Lack of organisability
• Too much information
• Can contain a lot of ads and false advertising

Saving favourite places in lists or sending via telegram

• Lack of organisability
• Unaesthetic

Our solution

Now imagine this. What if you had a list of all the places you've ever eaten at before and enjoyed?

Organised by cuisine, area, price and rating — BiteBook makes it easy for you to remember where and what you've eaten, so you can make a more informed choice and enjoy every meal.

BiteBook is a project that I worked on with my group members as part of the module 50.001 : Introduction To Information Systems & Programming as offered by SUTD.

Technical Details

Language: Java

Frontend: Android UI

Auth & DB: Firebase (Auth, Realtime DB, Storage)

Services: Google Play (Location/ Internal storage)

APIs: Google maps, Places (locations, restaurant metadata)

Java

Java is a preferred language for Android app development due to its OOP principles, allowing for reusable and scalable code. It's also platform-independent and has a vast developer community, making it a reliable choice for creating Android apps.

Firebase

We have been exposed to Firebase before in prior modules, and Firebase integration with Java and Android made the developer experience quite seamless. It was the obvious choice for a backend as it allows us to quickly get up and running, with tools and solutions for every backend aspect for our app.

Firebase Authentication

• Email/ Password authentication was the default option and allows users to create an account specifically for BiteBook.
• We also implemented Google One-Click Sign In for ease of onboarding, as most people nowadays prefer to use one account for everything and not have to remember new passwords and accounts.

Firebase Realtime Database

• The ideal choice due to its flexibility, ease of use, and it was also introduced to us during lecture.
• Able to store and sync data in real-time, with event listeners that keeps data up to date on the client — ideal for mobile apps.
• NoSQL database makes it simpler for beginner developers like us to get started as we don’t have to concern ourselves with database schemas and can update entries as we go without updating all tables, simplifying the development process especially when working in a group.

Firebase Storage

• We also store images from users, and therefore we need some form of cloud storage. Firebase storage was the obvious choice, keeping inline with our extensive use as Firebase as our backend solution.
• Modular and easy to setup, it ties in very nicely with the realtime database to keep pointers to where we store the bitmaps that users upload.

Services & APIs

BiteBook makes use of Google Maps and Places API to improve the user experience.

Firstly, by using the Google Maps API, the app can access location services, which would allow users to view the restaurants around them on the map.

The Autocomplete API also makes inputting information much easier as users don’t have to type out the whole address.

Moreover, the integration of the Places API would provide metadata such as restaurant names, addresses, and contact information, which is essential for a restaurant-focused food diary application.

Screenshots & Walkthrough

Login & Signup

On launching, a user is greeted with a login screen that accepts username/password or Google one-click sign in.

Home Page

On login, the user is greeted with a homepage of all their entries, arranged chronologically to show recent entries. They can click the expand card option to view more details about each entry including price, location and cuisine type.

Add Page

The Add page is where users can input new entries. The location is autofilled using the Places API to make the experience more seamless and convenient. Users are allowed to input the restaurant name, what they ate, price, area & cuisine type. They can also optionally choose to include a photo or review.

Decide Page

The decide page has 3 major functions:

• Filtering (by location and/or cuisine)
• Show all “Favourite” foods — foods that you’ve rated 5 stars
• “Decide” — from a list of filtered foods, BiteBook will randomly pick one for you

Map page

We’ve also included a Map page that showcases all entries a user has saved. This gives a better perspective of the places that they’ve been to on a map and they can see nearby locations. They can click on markers to see where they’ve eaten and what they’ve eaten there. The directions button at the bottom also makes it easy for them to decide and navigate to the location.

Design Patterns

Singleton Design Principle

Our team decided to use Singletons in our Firebase Android app because we wanted to ensure that there is only a single instance of a class and that it's globally accessible. Specifically, we chose to use Singleton for database objects such as FirebaseDatabase or FirebaseAuth.

In Firebase, every time our app communicates with the server, it uses a lot of I/O operations, and creating multiple instances of these objects could lead to memory issues and lag in database response. Therefore, creating a Singleton allows access to these objects while maintaining their singular instance.

By only creating one instance of these objects throughout the lifetime of our app, we are optimizing for network latency, database performance, and app efficiency. This approach also makes our code a lot cleaner and more maintainable.

Separation of Concerns

We split our code up into bundles that serve specific purposes whenever we were able to. For instance, we created an Entry class with appropriate constructors and getters. This makes use of the principle of Encapsulation which we were taught in class.

By creating private variables and exposing them via public getters, we are able to limit access to class members and achieve data integrity — ensuring that only intended classes and objects are able to access and mutate data. This also helps in the context of working together as a group as it makes it easier for us to know what we should and should not do.

A FirebaseHelper class was also created to call the Auth and DB singletons. This allowed us to separate the data fetching from the data viewing, creating a barebones implementation of the MVC framework and making our codebase more maintainable.

VCS - GitHub

When collaborating on this project, our group also made use of git to track changes. This allows us to rollback in case of errors and to facilitate changes. Being able to see what each of our group members change in pull requests also makes it easier to cross check each others’ code and catch possible errors before they occur.

Dependencies

Our project uses few dependencies, mostly Google services and things related to the Map API. This ensures longevity as these dependencies are unlikely to be deprecated. The only dependency we used was the Picasso library to make working with bitmaps easier.

Possible Improvements

Social Element

• Add a Friends feature so that you can follow and see lists and places your friends have created.
• A way to discover new food places.
• Can be implemented as our database schema already creates separate lists for each user and each user has an ID tagged to them.

Lists + Create own tags

• Allow users to create lists according to their own preference that they are then able to filter by.

More media options

• Users should be allowed to add more than one picture, and videos as well to capture the experience more completely.

Recommendations

• After enough data has been saved by the user, we can create an algorithm that suggests new places to eat according to their preferences, allowing them to find and discover new places.

Conclusion

I found this project to be immensely rewarding as it allowed us to apply our knowledge of Android programming to produce a tangible product. The end-to-end integration of our work, from ideation to prototyping and final product, was truly an iterative process that taught us invaluable skills and valuable lessons along the way. Through this project, we gained a deeper understanding of not only the technical aspects involved in Android app development but also the importance of effective communication and teamwork in achieving a common goal.

We were also able to showcase this to Singtel engineers, which served as a way of preparation for future code reviews and forces us to make decisions that we know we have to be able to justify and explain, leading to greater code quality.