Well, it's official, I made my first app!

I'm really starting to feel like a software engineer now (at least if I ignore the fact that there is still a whole bunch of stuff I don't know how to do)

But in all seriousness, I'm pretty proud of myself. I wrote this app as part of my Phase 1 final project at the Flatiron School, and, honestly, I think I've gotten pretty far in 6 weeks. Once I planned it out and applied the concepts we learned, actually writing the app turned out to be pretty fun. One more sign that I'm moving into the right career, huh?

Pantry Pal

So, let's talk about my app: Pantry Pal.

The idea behind it was that I wanted to make something that would be useful to me outside just a course project. So I thought of what I needed, that would also fulfill the requirements. that's how I arrived at my user story...

"I love to cook, but I hate planning and managing my pantry/fridge."

So, what I wanted was something that could:

A) Keep track of the ingredients in my pantry
B) Help find cool new recipes for me to try
3) Add ingredients I need to buy for a recipe to a shopping list (without adding the stuff I already have)
4) Keep me from mixing letters and numbers when making lists

So, that's what the app does (is supposed to do). Now, Let's take a look at how it's built.

Pantry Pal: Classes

So there are 3 main object classes:

1. Pantry - This class represents the "virtual pantry" of the user. It stores ingredients (as simple strings) and also functions as a sort of user account for the app.
2. Recipe - This is the bread and butter of the app (pun intended, though not very good). The Recipe class is the most flexible, but also the one that brings the functionality of the app together.
3. ShoppingList - Like the pantry, The ShoppingList class holds a list of ingredients. But this class is designed to receive information from the recipes and list the ingredients needed to buy.

There is an importer class:
RecipeImporter uses the Edamam Food API to search for recipes, and then creates a Recipe object for the one that the user wants to save. The user can input keywords to search, or they can "search by pantry" which takes three random items they have in their pantry and uses them as search terms. The idea is that it'll give them a fun new recipe to try, with their leftover or staple ingredients.

*note: the reason I chose to just use strings as the ingredients instead of making an Ingredient class, is that the API coded the ingredients in way that includes the quantity and unit as part of the name i.e. "1 cup of broccoli florets". Since, it would be incredibly difficult for me to get a useable simple ingredient name (and thus complete the true functionality of the app), I decided to just use strings for now.

Finally there is a Controller class that runs the CLI. This class is the largest and is how the user is able to interact with the app. The Controller class keeps an instance of the other classes (exept Recipe) as attributes. This way, the controller can access every part of the app, and the other classes can interact with each other through their shared Controller.

There is also a module "Listable" for the three object classes.
This module contains methods that all three classes need, which are related to saving, removing, and listing the different instances that have been created, and also in listing attributes such as ingredients contained in each instance.

Now, you might be asking...

Why doesn't the controller keep track of Recipe instances?

Well, Because recipes don't do anything. the only thing they actually do themselves is create themselves, save themselves or list themselves. Anytime a Recipe is needed, we can just go to the Recipe class and grab whatever one we want to work with.

While recipes are extremely important objects in the application, they don't "belong to" any other class. This relationship was the trickiest, for me, as a many-to-many relationship like this, without going through an intermediary class wasn't really taught in our lessons. I kind of stumbled upon it when doing this build.

Phew!

Making the app was a lot of fun, and I think that I really pounded the fundamentals into myself while coding it. Honestly, it went a lot smoother than I thought it would, and I would never have dreamed of going from blank slate to working app a few months ago.

But hey, why don't you clone it and look at it yourself (if you want, no pressure)