ScienceSquad / Health

The next generation health assistant.
http://sciencesquad.github.io/Health
4 stars 1 forks source link

Suggest Diet #10

Open Brahmancer opened 8 years ago

Brahmancer commented 8 years ago

Implement a feature where the app will recommend a diet to the user based on user info.

Sprint 3:

Improve upon NutrientQuery class Link NutrientQuery class to other modules Improve upon ConditionModule


colinrford commented 8 years ago

This should be included in the scope of #43

avaidyam commented 8 years ago

//@colinrford @Brahmancer @brandonschabell @Wall-Dough @MrJohnson I see a lot of "this and that should work together" and I think we should implement some kind of centralized access to the data. I know we have Realm and all, but how do you all suppose we integrate the data for every module?

Brahmancer commented 8 years ago

So here are a couple of ideas (Spoilers, I'll be thinking in mind of using Realm but this can change if we do not use it):

  1. We generate a kind of all-encompassing class that has all the data there. However, this could result in a very cluttered database with a lot of tables that results in spending quality time with a database.
  2. Create a class that will store the data for each respected module. Here is where I think Realm can come in handy. We have one RealmObject per Module. We then have an all encompassing class that stores an instance of each RealmObject and we can use the individual data generated from each module. Problem's that come to mind with this approach is we need to clear about the schema of each module's data storage.

I know this is lengthy so I can clarify on certain points if something doesn't make sense.

avaidyam commented 8 years ago

I think we can have the model layers in their own package and go with option 2, like so:

package com.sciencesquad.models;

@AutoParcel
public class StepModel extends RealmObject {
    @Required
    public Date entryDate;
    @Required
    public int steps;
}

Then we'll have a module like so:

package com.sciencesquad.modules;

public class StepModule extends Module {
    /* code here */
    // uses StepModel to manage data.
}

This way we can have a true decoupling between all three layers in MVC. Now, for the diet module:

package com.sciencesquad.modules;

public class DietModule extends Module {
    /* code here */
    // uses DietModel to manage data.

    // Get all steps walked today as an integer.
    private int _stepsWalked() {
        return this.context.realmThing().getData(Date.Today, StepModel.class); // pseudocode
    }
}

@Brahmancer How does that sound?

colinrford commented 8 years ago

If I understand 2 properly, @Brahmancer, I think this could be the ideal option, as long as we can quickly compile/gather data from each Module together when we present the daily ( #31 ) and weekly/monthly/yearly ( #40 ) health progression. When the amount of data from each Module becomes quite large, we'll also want to be sure that the accessibility to this data remains quick so that the user sees their health overview quickly

Brahmancer commented 8 years ago

Just clarifications on the _stepsWalked() method @avaidyam , this would query a database associated with the StepModel for the amount of steps gathered?

Wall-Dough commented 8 years ago

I kinda have an idea: We have objects for exercise/run/etc. with variables for things like calorie consumption, each is an item such as a set of bicep curls or a 10 minute jog. An array of pointers to the objects, keyed by day. Another array of pointers to the objects, keyed by specific exercise. Another array of pointers to the objects, keyed by source module (run, step, exercise, etc.). In each object, pointers to each array of objects (allows for easy navigation from day/category/exercise to item, and back again)

In a main class that keeps track of overall health information, there would be total calories expended/consumed, among other data points, and an array of objects that contributed to the overall data.

We'd probably want to use things like tries, which we learned in 251(?), for quick and responsive searches.

avaidyam commented 8 years ago

@colinrford Yeah, the separation of the model layer (i.e. StepModel) would do this, as every module has the same Realm database underlying it. We can also maintain aggregate data that is lazy-computed only once and then stored in the database as well.

@Brahmancer Yes! This is assuming that the abstract Module class provides the hook to the underlying Realm database that every module accesses and stores information in.

avaidyam commented 8 years ago

@Wall-Dough Pointers don't happen in Java. :cry: I'm supposing Realm provides the keying of data, like SQL query syntax. @Brahmancer, do you know?

Tries make me cries. We have a database layer, let's see if it does this stuff for us, for free. Free lunches are great! :laughing:

Wall-Dough commented 8 years ago

@avaidyam Java doesn't allow for pointers explicitly, but at least implicitly, right? Like you can set one variable equal to another variable that's an object, and they're the same object?

I guess I'm still thinking in terms of local data. How much of the data would be local, and how much would remain in Realm?

avaidyam commented 8 years ago

Everything in Java is references except primitive types (int, float, char, etc.) Our goal is to move all our data into Realm and not think about it too hard. It should go there and be there, and come back when we need it. :100:

Wall-Dough commented 8 years ago

@avaidyam Got it. I assume some form of caching will be involved though, yes?

Brahmancer commented 8 years ago

So Realm does follow a SQL-like query syntax but in the from of Java Method calls. It may sound a bit confusing but much like SQL queries, it's very intuitive. You can provide a primary key for each module which is stored.

There's also an option of creating multiple Realm "tables" under different names where each module can read, write, and query to.

My thinking is whatever is essentially to the module that isn't easily computed should be stored in Realm.

avaidyam commented 8 years ago

@Wall-Dough Caching is nice. Caching is good. Caching is love.

@Brahmancer Native Java is the bee's knees and totally rocks my socks. Sounds like a plan.

Wall-Dough commented 8 years ago

Idea: For diet/recipe recommendations, include several options for a given diet based on how much time/funds someone has available for food preparation.

E.g.: Make it for me - recommend a restaurant I've got some free time - recommend a quick and easy recipe - include slow cooker recipes, since they're relatively hands-off I've got all the time in the world - no necessary time limit

avaidyam commented 8 years ago

@Wall-Dough we could abstract it into categories "Make it for me, I'm no cook, and Master Chef". This would absolutely awesome for me since I could then tell our app "pls gimme some pizzer and mcdoobies" without feeling bad....

Wall-Dough commented 8 years ago

@avaidyam

mcdoobies

:hamburger: :ok_hand: :dash:

avaidyam commented 8 years ago

:rocket: