Grocery Listr

Publicover & Co., Winter 2020–present

Description

A client needed a simple app that could broadcast with a pub-sub model for the items on a grocery list. After I delivered that, I tinkered with it a bit more to make it the app it is today.

There's a fair amount of setup that needs to happen for the app to work properly. Firstly, users are grouped by family units, so anyone acting in the app acts for the household. Users add individual foods along with caloric values. Users can then add recipes and combine those recipes to create meals. There’s a lot of math happening on the backend to get accurate calorie and nutritional information, but the short version is that users can pick meals or have the system pick randomly for you from the meals belonging to the family. A grocery list is generated that can handle multiple simultaneous grocery shoppers at the same location or different ones.

The calculations are pretty precise, making sure that if you need, say, one bell pepper each for two different meals, the grocery list just says 'Bell Peppers: 2 whole.' This is what allows calorie counts to be accurate, giving each entree (and most meals) a measurement of calorie per gram.

The biggest challenge

There's no (free) external API that gives calorie counts to the degree of accuracy the app needs to do the math properly. Google, for instance, returns that green bell peppers have 0 calories per gram as the first result. That's just clearly not true. If a recipe calls for 74 grams of bell pepper, that's 15 calories added to the total. So the system does math with 0.185/gram, which means that it's up to users to enter that kind of information in the first place. Which means it has to then be associated with the recipe values. The math was straightforward, but i do not like pushing so much detailed work onto the user.