CyberPlatter Android Recipe Manager

A recipe application with local data and remote identity

CyberPlatter was my CMP309 Android Development project. I built it as a personal recipe manager: users could create an account, sign in, add recipes, search the collection, open a recipe, change its contents, and remove it.

The application kept recipe data in a local SQLite database and used Firebase Authentication for account registration and login. That split is important. Firebase handled user identity, while the recipe records remained on the Android device rather than being synchronised through a cloud database.

The surviving project material includes the final presentation and architecture diagrams. It documents the working screens, data model, database operations, and the improvements I identified after the implementation.

Separating the interface from data handling

I organised the application into presentation and data-handling responsibilities.

The presentation side contained the Android activities and views for:

• login
• registration
• the main navigation page
• adding a recipe
• searching and listing recipes
• viewing recipe details
• updating or deleting an existing recipe

The data side centred on a recipe model and a database helper.

RecipeModal represented one recipe with five fields:

• name
• description
• ingredients
• method
• database identifier

The model exposed getters and setters so activities could pass structured recipe data rather than a collection of unrelated strings.

The database helper contained the SQLite schema and query operations. Its creation method established the recipes table, while the upgrade method replaced the table when the database version changed. The implemented operations covered create, read, update, and delete:

• insert a new recipe
• return recipe details for a selected name
• update the fields belonging to an existing recipe
• delete a selected recipe
• return rows for the list and search views

This gave the UI a single interface for database work rather than embedding SQL independently in every activity.

Login and registration

The login activity collected an email address and password, submitted them to Firebase Authentication, and moved an authenticated user into the main application.

The registration activity created a Firebase account from the same identity fields. Links between the two screens allowed a new user to register or an existing user to return to login without navigating through the recipe interface.

Using Firebase reduced the amount of authentication infrastructure required for the coursework, but it did not remove the need for application-side state handling. The Android app still had to deal with success, failure, navigation, and whether a user session was available before showing recipe functions.

Recipe workflow

The main page acted as the route into adding or finding recipes.

Adding a recipe collected its name, description, ingredients, and method before passing the record to the SQLite helper. The search page loaded stored entries into a scrollable list and allowed the user to narrow the result by name. Selecting an entry opened the full recipe view.

The detail screen provided the complete text and links to update or delete the record. Updates wrote changed values back through the database helper, while deletion removed the associated row.

The application therefore exercised a complete local-data lifecycle rather than only displaying static content:

authenticate
    -> open recipe library
    -> create or search
    -> select a stored record
    -> view, update, or delete
    -> return to the updated list

Design review

The implemented database layer provided reliable local storage and kept the core recipe operations together. The model class also made activity-to-database interactions easier to reason about than passing individual values everywhere.

The review identified several limitations:

• database upgrades dropped and recreated the table rather than migrating existing data
• duplicate recipes needed clearer validation
• the application did not include backup or restore
• recipe data was not encrypted locally
• some input screens needed better scrolling and responsive behaviour
• recipe data did not synchronise between devices

The planned next stage separated ingredients into their own table so quantities, prices, and shopping-list functions could be represented properly. Other ideas included shared recipes, meal planning, database synchronisation, backup and restore, and splitting preparation from serving instructions.

Those were proposed extensions rather than implemented features. The completed project was a local CRUD application with Firebase-backed identity, an object-oriented SQLite layer, search, and a multi-screen Android interface.